svn commit: r487772 - /tomcat/tc6.0.x/trunk/res/side_left.bmp

2006-12-16 Thread mturk
Author: mturk
Date: Sat Dec 16 00:38:05 2006
New Revision: 487772

URL: http://svn.apache.org/viewvc?view=rev&rev=487772
Log:
Forgot to rotate by 90 degrees CCW.

Modified:
tomcat/tc6.0.x/trunk/res/side_left.bmp

Modified: tomcat/tc6.0.x/trunk/res/side_left.bmp
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/side_left.bmp?view=diff&rev=487772&r1=487771&r2=487772
==
Binary files - no diff available.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: svn commit: r487168 - /tomcat/tc6.0.x/trunk/res/side_left.bmp

2006-12-16 Thread Mladen Turk

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Thu Dec 14 02:42:33 2006
New Revision: 487168

URL: http://svn.apache.org/viewvc?view=rev&rev=487168
Log:
More artwork

Modified:
tomcat/tc6.0.x/trunk/res/side_left.bmp


Your new bitmap does not look good to me: it's stretched.


Oops. Forgot to rotate the image.

It should also 
not read "The Apache Tomcat 6", but "Apache Tomcat 6".




Done.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 41188] New: - replace shutdown mechanism

2006-12-16 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41188

   Summary: replace shutdown mechanism
   Product: Tomcat 6
   Version: 6.0.0
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The current shutdown mechanism, sending a string to a port is insecure.
A new mechanism should be created so that only the process owner or the
administrator can shut the process down.

Created this enhancement request as requested in the discussion in this bug i
filed a while ago:
http://issues.apache.org/bugzilla/show_bug.cgi?id=40947

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 40947] - Stopping the server should not rely on passing a string to a port on localhost.

2006-12-16 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40947





--- Additional Comments From [EMAIL PROTECTED]  2006-12-16 01:39 ---
The enhancement request is in bug #41188

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 41188] - replace shutdown mechanism

2006-12-16 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41188


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-12-16 02:24 ---


*** This bug has been marked as a duplicate of 40947 ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 40947] - Stopping the server should not rely on passing a string to a port on localhost.

2006-12-16 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40947





--- Additional Comments From [EMAIL PROTECTED]  2006-12-16 02:24 ---
*** Bug 41188 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



svn commit: r487786 - /tomcat/tc6.0.x/trunk/native/connector/src/network.c

2006-12-16 Thread mturk
Author: mturk
Date: Sat Dec 16 03:05:57 2006
New Revision: 487786

URL: http://svn.apache.org/viewvc?view=rev&rev=487786
Log:
Backport the current connectors trunk.

Modified:
tomcat/tc6.0.x/trunk/native/connector/src/network.c

Modified: tomcat/tc6.0.x/trunk/native/connector/src/network.c
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/native/connector/src/network.c?view=diff&rev=487786&r1=487785&r2=487786
==
--- tomcat/tc6.0.x/trunk/native/connector/src/network.c (original)
+++ tomcat/tc6.0.x/trunk/native/connector/src/network.c Sat Dec 16 03:05:57 2006
@@ -226,7 +226,7 @@
 s->sock = NULL;
 apr_socket_close(as);
 }
-
+
 apr_pool_destroy(s->pool);
 }
 
@@ -439,14 +439,14 @@
 if (tosend <= TCN_BUFFER_SZ) {
 jbyte sb[TCN_BUFFER_SZ];
 (*e)->GetByteArrayRegion(e, buf, offset, tosend, &sb[0]);
-ss = (*s->net->send)(s->opaque, sb, &nbytes);
+ss = (*s->net->send)(s->opaque, (const char *)&sb[0], &nbytes);
 }
 else {
 jbyte *sb = (jbyte *)malloc(nbytes);
 if (sb == NULL)
 return -APR_ENOMEM;
 (*e)->GetByteArrayRegion(e, buf, offset, tosend, sb);
-ss = (*s->net->send)(s->opaque, sb, &nbytes);
+ss = (*s->net->send)(s->opaque, (const char *)sb, &nbytes);
 free(sb);
 }
 if (ss == APR_SUCCESS)
@@ -701,27 +701,40 @@
 tcn_socket_t *s = J2P(sock, tcn_socket_t *);
 apr_size_t nbytes = (apr_size_t)toread;
 apr_status_t ss;
+apr_interval_time_t pt;
+apr_interval_time_t nt = J2T(timeout);
 
 UNREFERENCED(o);
 TCN_ASSERT(sock != 0);
 TCN_ASSERT(s->opaque != NULL);
 TCN_ASSERT(buf != NULL);
 
-if ((ss = (*s->net->timeout_set)(s->opaque, J2T(timeout))) != APR_SUCCESS)
-goto cleanup;
+if ((ss = (*s->net->timeout_get)(s->opaque, &pt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+if (pt != nt) {
+if ((ss = (*s->net->timeout_set)(s->opaque, nt)) != APR_SUCCESS)
+goto cleanup;
+}
 if (toread <= TCN_BUFFER_SZ) {
 jbyte sb[TCN_BUFFER_SZ];
-if ((ss = (*s->net->recv)(s->opaque, sb, &nbytes)) == APR_SUCCESS)
+if ((ss = (*s->net->recv)(s->opaque, (char *)&sb[0], &nbytes)) == 
APR_SUCCESS)
 (*e)->SetByteArrayRegion(e, buf, offset, (jsize)nbytes, &sb[0]);
 }
 else {
 jbyte *sb = (jbyte *)malloc(nbytes);
 if (sb == NULL)
 return -APR_ENOMEM;
-if ((ss = (*s->net->recv)(s->opaque, sb, &nbytes)) == APR_SUCCESS)
+if ((ss = (*s->net->recv)(s->opaque, (char *)sb, &nbytes)) == 
APR_SUCCESS)
 (*e)->SetByteArrayRegion(e, buf, offset, (jsize)nbytes, &sb[0]);
 free(sb);
 }
+if (pt != nt) {
+if ((ss = (*s->net->timeout_set)(s->opaque, pt)) != APR_SUCCESS)
+goto cleanup;
+}
+
 #ifdef TCN_DO_STATISTICS
 if (ss == APR_SUCCESS) {
 sp_max_recv = TCN_MAX(sp_max_recv, nbytes);
@@ -854,6 +867,8 @@
 apr_status_t ss;
 apr_size_t nbytes = (apr_size_t)len;
 char *bytes;
+apr_interval_time_t pt;
+apr_interval_time_t nt = J2T(timeout);
 
 UNREFERENCED(o);
 if (!sock) {
@@ -866,9 +881,24 @@
 bytes  = (char *)(*e)->GetDirectBufferAddress(e, buf);
 TCN_ASSERT(bytes != NULL);
 
-if ((ss = (*s->net->timeout_set)(s->opaque, J2T(timeout))) != APR_SUCCESS)
- return -(jint)ss;
+if ((ss = (*s->net->timeout_get)(s->opaque, &pt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+if (pt != nt) {
+if ((ss = (*s->net->timeout_set)(s->opaque, nt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+}
 ss = (*s->net->recv)(s->opaque, bytes + offset, &nbytes);
+if (pt != nt) {
+if ((ss = (*s->net->timeout_set)(s->opaque, pt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+}
+
 #ifdef TCN_DO_STATISTICS
 if (ss == APR_SUCCESS) {
 sp_max_recv = TCN_MAX(sp_max_recv, nbytes);
@@ -905,6 +935,8 @@
 tcn_socket_t *s = J2P(sock, tcn_socket_t *);
 apr_status_t ss;
 apr_size_t nbytes = (apr_size_t)len;
+apr_interval_time_t pt;
+apr_interval_time_t nt = J2T(timeout);
 
 UNREFERENCED_STDARGS;
 UNREFERENCED(o);
@@ -916,9 +948,24 @@
 TCN_ASSERT(s->opaque != NULL);
 
 
-if ((ss = (*s->net->timeout_set)(s->opaque, J2T(timeout))) != APR_SUCCESS)
- return -(jint)ss;
+if ((ss = (*s->net->timeout_get)(s->opaque, &pt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+if (pt != nt) {
+if ((ss = (*s->net->timeout_set)(s->opaque, nt)) != APR_SUCCESS) {
+TCN_ERROR_WRAP(ss);
+return -(jint)ss;
+}
+}
 ss = (*s->net->recv)(s->opaque, s->jrbbuff + offset, &nbytes);
+if (pt

Re: mod_jk release preparation: ready for test

2006-12-16 Thread Rainer Jung
Hi David,

this message means, that no forwarding rules (=map) have been found for
that worker. So no JkMount, mount attribute in workers.properties or
uriworkermap.properties applies to that worker.

Important: maps are associated to virtual hosts in apache. The status
worker can only see those maps, that belong to the same virtual host, it
has been called in. So if you add all your maps to a vhost for
production use, and add a status worker on a separate vhost for admin
use, this status worker will not be able to see the maps from the
production vhost. If you want to inhertif maps from the global server to
vhosts, you need to set JkMountCopy for the vhost. More about that in
the updated Apache docs page (reference guide) and the new
uriworkermap.properties page.

Could that be the reason for the message?

We might improve the situation concerning the status worker in the
future, but making available all the maps to it will be a major
refactoring in the jk code (for apache, IIS can already see all the maps).

Regards,

Rainer

David Rees schrieb:
> On 12/6/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
>> - reworked status worker (see new docs page)
> 
> On my status worker page, I get the message:
> 
> Warning: No URI Mappings defined for  !
> 
> Otherwise, everything seems to work OK so far in my limited testing.
> 
> -Dave
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk release preparation: ready for test

2006-12-16 Thread Henri Gomez

Good explanation since I wondering why the jkstatus didn't see my
JKMount directive.

In my case the jkstatus is defined in the httpd.conf (common) and the
JKMounts in all VHost.

It's a very common configuration since Web admins don't want to
redifine a jkstatus for each vhost.



2006/12/16, Rainer Jung <[EMAIL PROTECTED]>:
Hi David,

this message means, that no forwarding rules (=map) have been found for
that worker. So no JkMount, mount attribute in workers.properties or
uriworkermap.properties applies to that worker.

Important: maps are associated to virtual hosts in apache. The status
worker can only see those maps, that belong to the same virtual host, it
has been called in. So if you add all your maps to a vhost for
production use, and add a status worker on a separate vhost for admin
use, this status worker will not be able to see the maps from the
production vhost. If you want to inhertif maps from the global server to
vhosts, you need to set JkMountCopy for the vhost. More about that in
the updated Apache docs page (reference guide) and the new
uriworkermap.properties page.

Could that be the reason for the message?

We might improve the situation concerning the status worker in the
future, but making available all the maps to it will be a major
refactoring in the jk code (for apache, IIS can already see all the maps).

Regards,

Rainer

David Rees schrieb:
> On 12/6/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
>> - reworked status worker (see new docs page)
>
> On my status worker page, I get the message:
>
> Warning: No URI Mappings defined for  !
>
> Otherwise, everything seems to work OK so far in my limited testing.
>
> -Dave
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 41188] - replace shutdown mechanism

2006-12-16 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41188





--- Additional Comments From [EMAIL PROTECTED]  2006-12-16 05:07 ---
Why has this been marked as a duplicate?  Does the "resolved" status of this
request indicate this enhancement will not be considered?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[VOTE] Releasing Tomcat Connectors 1.2.20

2006-12-16 Thread Rainer Jung
Hello to all Tomcat project members,

mod_jk 1.2.20 has been available for testing during the last week. No
new bugs have been reported so far, so I would like to proceed with the
release vote.

If you want to take a look, the source distribution can be downloaded from:

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/

The updated documentation can be found at

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.20/docs/

So here's the vote, which will be open until Tuesday December 19, 24:00 GMT.

Apache Tomcat Connectors 1.2.20 is:
[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are

Thank you,

Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Henri Gomez

people.apache.org seems to be down ;(

2006/12/16, Remy Maucherat <[EMAIL PROTECTED]>:

Hi,

The vote is to release Apache Tomcat 6.0.6 as alpha.
The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/

Votes ?

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Releasing Tomcat Connectors 1.2.20

2006-12-16 Thread Henri Gomez

[X] Stable - no major issues, no regressions


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Smooth applications migration in a J2EE cluster [mod_jk]

2006-12-16 Thread Rainer Jung
Hi,

yes I looked at the animation. Although I must confess, that I don't get
much out of it technically. What's the reason for the need to test
session validity? Is it needed to find out, if a node already got
upgraded to a new app version, so the session needs to get routed to a
node, still running the old app version? That's what I expect, since you
introduced worker "versions" (one could also name it "generation").

OK, we are only talking about cluster (in the sense of session
replication) and I assume, that we are interested in the case of an
application update, which is non-compatible concerning sessions and/or
URL structure.

At the moment, sessions will be routed according to the routing suffix
in their id. Sessions which failed over can be rewritten (get another
routing suffix) by a Valve and thus be bound to another (surviving)
node. But sessions which have been idle will still be called with the
old suffix by the browser the next time they are used. If the node got
an update in the meantime, they will get routed to an incompatible node
and throw an error.

As a first simple workaround one could use two sets of workers and of
target (tomcat) nodes. One set would be stopped, on active at a time.
The two sets use different jvmRoutes. Replication is not done across set
boundaries.

You upgrade the stopped set, test it via an internal connector/vhost and
then change its activation to active. Also you change the activation of
the formerly active set to disabled. New sessions will go to the updated
set, old sessions will still go to the unchanged set. Invalid sessions
will need to redirect to a start page without session information. After
some (depending on session use time) you stop the disabled set, to
prevent people with URL encoded bookmarks (or long running browsers with
cookies cached) to still reach the old version.

Now this scenario does not really help, if you want to do *many*
updates. It granularity is somehow to coarse. To make it work more
smoothly, we would need an automatic way of managing jvmRoute,
worker.route and worker.domain consistently during application upgrade
(increasing generation counter which gets appended to the route). It
looks like you did something like that?

Somehow I don't really see the need of checking the validity of a
session by mod_jk. We only need to know, which version of the app the
session belongs to, and which version of the app the various workers
talk to. This could be done by a generation counter in jvmRoute and all
routing related strings in mod_jk.

In your original mail, you talked about additional hooks you would need
inside mod_jk. What would that be?

Regards,

Rainer

Anthony Vromant schrieb:
> Hi all,
> 
> I would like to know if you had time to look at the demonstration of our
> prototype.
> 
> We are very interested to get your feelings about that.
> 
> Do you have ideas about our problem of testing the validity of a user
> session within mod_jk ?
> We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat
> that mod_jk can
> invoke through the AJP interface. What's your opinion ?
> 
> Thanks.
> Regards
> 
> Anthony Vromant
> 
> Anthony Vromant wrote:
>> Hi Rainer,
>>
>> First of all, thank you for these informations.
>>
>> Here is the HTTP link for the Flash demonstration of our prototype :
>> https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster
>>
>>
>> I am looking at the new features provided by mod_jk 1.2.20, the
>> dynamic configuration reloading is quite interesting.
>> We are going to bring our prototype to this new version.
>>
>> In our prototype, when a new request is coming with a JSESSIONID
>> cookie, a request is sent to the worker (tomcat) for checking the
>> validity (we need to know whether the session is still alive).
>> Currently, the HTTP protocol is used for invoking tomcat rather than
>> AJP. The control at the tomcat side is done through an internal
>> servlet which accesses the MBean manager for getting the current
>> sessions list.
>>
>> Do you have any suggestion for improving that ?
>>
>> Regards,
>> Anthony
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Rainer Jung
Henri Gomez schrieb:
> people.apache.org seems to be down ;(

and up again. Hopefully stable (p.a.o).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Releasing Tomcat Connectors 1.2.20

2006-12-16 Thread Yoav Shapira

Hi,

On 12/16/06, Rainer Jung <[EMAIL PROTECTED]> wrote:

Apache Tomcat Connectors 1.2.20 is:
[ X ] Stable - no major issues, no regressions


I didn't test this as exhaustively as some other people might, but it
worked perfectly well as a drop-in replacement to an earlier mod_jk
setup for an in-home application that handles a decent traffic volume.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Yoav Shapira

Hi,
+1 for Tomcat 6.0.6 as alpha.

Yoav

On 12/15/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Hi,

The vote is to release Apache Tomcat 6.0.6 as alpha.
The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/

Votes ?

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Releasing Tomcat Connectors 1.2.20

2006-12-16 Thread Mladen Turk

Rainer Jung wrote:


Apache Tomcat Connectors 1.2.20 is:
[X] Stable - no major issues, no regressions


Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Mladen Turk

Remy Maucherat wrote:

Hi,

The vote is to release Apache Tomcat 6.0.6 as alpha.
The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/

Votes ?



The .exe installer looks really weired due to my fault
because I forget to rotate the left side image :(
Can you just rebuild the exe without retaging?

Other the that...

+1

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Mark Thomas
Remy Maucherat wrote:
> Hi,
> 
> The vote is to release Apache Tomcat 6.0.6 as alpha.
> The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/

+1

I keep meaning to say great job on the new build. Much faster than 5.5.x

Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Releasing Tomcat Connectors 1.2.20

2006-12-16 Thread Jean-frederic Clere

[X] Stable - no major issues, no regressions

Cheers

Jean-Frederic



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Remy Maucherat

Mark Thomas wrote:

Remy Maucherat wrote:

Hi,

The vote is to release Apache Tomcat 6.0.6 as alpha.
The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/


+1

I keep meaning to say great job on the new build. Much faster than 5.5.x


I don't see how it's faster (it should use less memory, however). Which 
tests did you do exactly ?


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Remy Maucherat

Mladen Turk wrote:

Remy Maucherat wrote:

Hi,

The vote is to release Apache Tomcat 6.0.6 as alpha.
The build is located here: 
http://people.apache.org/~remm/tomcat-6/v6.0.6/


Votes ?



The .exe installer looks really weired due to my fault
because I forget to rotate the left side image :(
Can you just rebuild the exe without retaging?


The build is supposed to correspond to the tag, so it's not possible to 
fix it without a new tag.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Mark Thomas
Remy Maucherat wrote:
> Mark Thomas wrote:
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> The vote is to release Apache Tomcat 6.0.6 as alpha.
>>> The build is located here:
>>> http://people.apache.org/~remm/tomcat-6/v6.0.6/
>>
>> +1
>>
>> I keep meaning to say great job on the new build. Much faster than 5.5.x
> 
> I don't see how it's faster (it should use less memory, however). Which
> tests did you do exactly ?

Sorry, should have been clearer. I meant the build process rather than
the result ;)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread Mladen Turk

Remy Maucherat wrote:


The .exe installer looks really weired due to my fault
because I forget to rotate the left side image :(
Can you just rebuild the exe without retaging?


The build is supposed to correspond to the tag, so it's not possible to 
fix it without a new tag.




I supposed it would end up with something like that.
Sorry again for messing the bitmap :(

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] Release build 6.0.6 as alpha

2006-12-16 Thread William A. Rowe, Jr.
Don't tell me the .exe is in SVN :)

PROVIDED that the tagged sources are identical it should not be an issue.

I actually split httpd/win32-msi/ from the httpd/trunk for this very reason,
easier that the installer is a post-release vote artifact.

As Roy's pointed out recently elsewhere, we trust binary packagers to build
the real sources we tagged and tarred.  There's technically no real way to
verify this, so 'artifacts' of packaging shouldn't become a showstopper.

Q - is the source identical, and if so, retar and move on.  If not, then
reroll.

Remy Maucherat wrote:
> Mladen Turk wrote:
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> The vote is to release Apache Tomcat 6.0.6 as alpha.
>>> The build is located here:
>>> http://people.apache.org/~remm/tomcat-6/v6.0.6/
>>>
>>> Votes ?
>>>
>>
>> The .exe installer looks really weired due to my fault
>> because I forget to rotate the left side image :(
>> Can you just rebuild the exe without retaging?
> 
> The build is supposed to correspond to the tag, so it's not possible to
> fix it without a new tag.
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> .
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]