Re: Proposed new CometEvent.notify method

2007-05-04 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Ok, I'll try something in the meantime in CoyoteAdapter, since it's 
trivial (and I think does all that is needed at this point).
The available() has a side effect, if there is a partial or non valid 
chunked header (ie the client also sends some garbage), available() 
returns >0, and the read() goes into a forever blocking read as no 
more data is coming in.
this was not the case before, as a READ event, you did one read, and 
then available returned 0, and you'd be fine until next READ event.
since it's a client data error, I'm ok with it, question is, how 
common are these client errors.


It doesn't really make a difference. Even if you do only one read 
during the read event, it is possible to only send a portion of the 
chunk header, causing the ChunkedInputBuffer to block if its previous 
chunk was fully read (or if it is the first chunk). The only realistic 
solution is to add a system property forbidding reads during parsing 
of the chunk header, as I don't think it's a very reasonable situation.


I would be ok to tag 6.0.13 before doing any further functional 
changes, as it contains numerous bugfixes since 6.0.10.
Let us wait a few days for these available() changes to get some 
feedback, then we can tag and go through our stability tests.


Ok. I was ready to tag tomorrow evening before starting on the timeout 
feature for APR, but I can wait more if you have changes to do 
(otherwise, I don't think anyone is going to really test since it's 
the WE). I can tag again if there's a horrible bug.

ok, tag away, I don't have more to commit at this time
Filip


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: Proposed new CometEvent.notify method

2007-05-04 Thread Remy Maucherat

Remy Maucherat wrote:
No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a likely 
problem that it would require additional structures to hold that data, 
and which are present in the adapter.


Speaking of swallowing problems due to reading, you wrote this on the 
user list:


On 5/4/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> This is because when an event happens, CoyoteAdapter will now check the
> channel by doing a read(in order for available to work). This will close
> the underlying connection, and you'll get this error.

CoyoteAdapter reads and generates the appropriate event according to the 
read result (previously, it generated a read event without doing a 
read). There's no close being done in CoyoteAdapter (except if there's 
an exception, in which case everything is recycled, but it doesn't seem 
to be the siutation you describe).


Rémy

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



Re: Proposed new CometEvent.notify method

2007-05-04 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Remy Maucherat wrote:
No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a likely 
problem that it would require additional structures to hold that 
data, and which are present in the adapter.


Speaking of swallowing problems due to reading, you wrote this on the 
user list:


On 5/4/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> This is because when an event happens, CoyoteAdapter will now check the
> channel by doing a read(in order for available to work). This will 
close

> the underlying connection, and you'll get this error.

CoyoteAdapter reads and generates the appropriate event according to 
the read result (previously, it generated a read event without doing a 
read). There's no close being done in CoyoteAdapter (except if there's 
an exception, in which case everything is recycled, but it doesn't 
seem to be the siutation you describe).
turns out the user found a problem, what I was describing is a possible, 
but very hard scenario to actual run into. the CoyoteAdapter->read(on a 
client disconnect) would have to happen at the same time as 
otherThread->Servlet->write
but as you said, he didn't run into this scenario, he was able to 
synchronize to avoid it, since the adapter calls close/end if there is 
an exception upon the read.

so we are good, "tag along"
Filip


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: Proposed new CometEvent.notify method

2007-05-04 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:
turns out the user found a problem, what I was describing is a possible, 
but very hard scenario to actual run into. the CoyoteAdapter->read(on a 
client disconnect) would have to happen at the same time as 
otherThread->Servlet->write
but as you said, he didn't run into this scenario, he was able to 
synchronize to avoid it, since the adapter calls close/end if there is 
an exception upon the read.


Yes. Since the read is made outside of the user control, there is a 
major problem if it has side effects (either by the IO layer putting 
itself in error mode automagically, or more directly if the request was 
closed without telling the servlet). I briefly looked at the NIO code 
which was involved in the stack trace in JDK 6, and it doesn't seem to 
be doing funny things; the only way to run into it is if the user did 
close the channel explicitly. So I think it should work too.


Rémy


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



DO NOT REPLY [Bug 42335] New: - wrong location of manager webapp

2007-05-04 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=42335

   Summary: wrong location of manager webapp
   Product: Tomcat 6
   Version: 6.0.10
  Platform: All
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The manager webapp is located in the webapps subdirectory
($CATALINA_HOME/webapps). The web.xml deployment descriptor contains a different
location/docBase: 



Work-around: moving $CATALINA_HOME/webapps to $CATALINA_HOME/server/webapps.

-- 
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 41059] - WebAppClassLoader clearReferences code break running threads

2007-05-04 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=41059





--- Additional Comments From [EMAIL PROTECTED]  2007-05-04 09:20 ---
This is causing a problem for me also and I think requires a fix other than the 
patch given here. I get the following stack trace which shows that the error 
occurs on  Tomcat's clean up thread and therefore should be addressed with a 
more permanent fix.

The problem arises because Tomcat tries to null a static/final field of a type 
that has not yet been loaded, which causes the class initializer to run. In my 
case, that initializer fetched a log from Commons Logging, which had 
(presumably) already been "cleaned up" by Tomcat, and threw an NPE.


[FATAL] LoggingInit - Failed to obtain logger returning simple logger for 
CONFIG.com.commons.monitoring.util.Instrument 
org.apache.commons.logging.LogConfigurationException: 
java.lang.NullPointerException (Caused by java.lang.NullPointerException)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:538)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:235)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:370)
at com.commons.logging.LoggingInit.getLog(LoggingInit.java:334)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.commons.catalog.CatalogUtils.getLog(CatalogUtils.java:75)
at com.commons.catalog.GenericTrace.(GenericTrace.java:279)
at com.commons.catalog.SimpleTrace.(SimpleTrace.java:34)
at com.commons.monitoring.util.Instrument.
(AbstractRuntimeInstrument.java:44)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(Unknown 
Source)
at sun.reflect.ReflectionFactory.newFieldAccessor(Unknown Source)
at java.lang.reflect.Field.acquireFieldAccessor(Unknown Source)
at java.lang.reflect.Field.getFieldAccessor(Unknown Source)
at java.lang.reflect.Field.get(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.clearReferences
(WebappClassLoader.java:1612)
at org.apache.catalina.loader.WebappClassLoader.stop
(WebappClassLoader.java:1496)
at org.apache.catalina.loader.WebappLoader.stop(WebappLoader.java:734)
at org.apache.catalina.core.StandardContext.stop
(StandardContext.java:4398)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1067)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1067)
at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448)
at org.apache.catalina.core.StandardService.stop
(StandardService.java:510)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:734)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:602)
at org.apache.catalina.startup.Catalina.start(Catalina.java:577)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Caused by: java.lang.NullPointerException


Upgrading Commons Logging to v1.1 on Tomcat's server classpath removes the NPE 
but the problem isn't really fixed.

Possible solution is to use two phases: first collect all the non-null Fields 
(Field.get will cause the declared type to be loaded) then null them.

-- 
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: r535324 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java

2007-05-04 Thread remm
Author: remm
Date: Fri May  4 09:46:47 2007
New Revision: 535324

URL: http://svn.apache.org/viewvc?view=rev&rev=535324
Log:
- Small javadoc update.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java?view=diff&rev=535324&r1=535323&r2=535324
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/CometEvent.java Fri May  4 
09:46:47 2007
@@ -47,10 +47,10 @@
  * READ - This indicates that input data is available, and that one read 
can be made
  *  without blocking. The available and ready methods of the InputStream or
  *  Reader may be used to determine if there is a risk of blocking: the 
servlet
- *  should read while data is reported available, and can make one 
additional read
- *  without blocking. When encountering a read error, the servlet should
- *  report it by propagating the exception properly. Throwing an exception 
will 
- *  cause the error event to be invoked, and the connection will be 
closed. 
+ *  should read while data is reported available. When encountering a read 
error, 
+ *  the servlet should report it by propagating the exception properly. 
Throwing 
+ *  an exception will cause the error event to be invoked, and the 
connection 
+ *  will be closed. 
  *  Alternately, it is also possible to catch any exception, perform clean 
up
  *  on any data structure the servlet may be using, and using the close 
method
  *  of the event. It is not allowed to attempt reading data from the 
request 
@@ -58,7 +58,9 @@
  * END - End may be called to end the processing of the request. Fields 
that have
  *  been initialized in the begin method should be reset. After this event 
has
  *  been processed, the request and response objects, as well as all their 
dependent
- *  objects will be recycled and used to process other requests.
+ *  objects will be recycled and used to process other requests. End will 
also be 
+ *  called when data is available and the end of file is reached on the 
request input
+ *  (this usually indicates the client has pipelined a request).
  * ERROR - Error will be called by the container in the case where an IO 
exception
  *  or a similar unrecoverable error occurs on the connection. Fields that 
have
  *  been initialized in the begin method should be reset. After this event 
has



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



svn commit: r535325 - in /tomcat/tc6.0.x/trunk/webapps/docs: aio.xml changelog.xml

2007-05-04 Thread remm
Author: remm
Date: Fri May  4 09:49:06 2007
New Revision: 535325

URL: http://svn.apache.org/viewvc?view=rev&rev=535325
Log:
- Changelog update.

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/aio.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/aio.xml?view=diff&rev=535325&r1=535324&r2=535325
==
--- tomcat/tc6.0.x/trunk/webapps/docs/aio.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/aio.xml Fri May  4 09:49:06 2007
@@ -66,9 +66,10 @@
without blocking. The available and ready methods of the InputStream or
Reader may be used to determine if there is a risk of blocking: the 
servlet
should read while data is reported available, and can make one 
additional read
-   without blocking. When encountering a read error, the servlet should
-   report it by propagating the exception properly. Throwing an exception 
will 
-   cause the error event to be invoked, and the connection will be closed. 
+   should read while data is reported available. When encountering a read 
error, 
+   the servlet should report it by propagating the exception properly. 
Throwing 
+   an exception will cause the error event to be invoked, and the 
connection 
+   will be closed. 
Alternately, it is also possible to catch any exception, perform clean 
up
on any data structure the servlet may be using, and using the close 
method
of the event. It is not allowed to attempt reading data from the 
request 
@@ -82,7 +83,9 @@
   EventType.END: End may be called to end the processing of the request. 
Fields that have
  been initialized in the begin method should be reset. After this event has
  been processed, the request and response objects, as well as all their 
dependent
- objects will be recycled and used to process other requests.
+ objects will be recycled and used to process other requests. End will 
also be 
+ called when data is available and the end of file is reached on the 
request input
+ (this usually indicates the client has pipelined a request).
   EventType.ERROR: Error will be called by the container in the case where 
an IO exception
  or a similar unrecoverable error occurs on the connection. Fields that 
have
  been initialized in the begin method should be reset. After this event has

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?view=diff&rev=535325&r1=535324&r2=535325
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Fri May  4 09:49:06 2007
@@ -15,11 +15,70 @@
 
 
 
+  
+
+  
+ More accurate available() method. (remm)
+  
+  
+ Add recycle check in the event object, since it is a facade like the 
others. (remm)
+  
+  
+ When processing a read event, enforce that the servlet consumes all 
available bytes. (remm)
+  
+  
+ Add a flag in ContainerBase which could be used in embedded scenarios 
to avoid a double start
+ of contexts (this problem generally occurs when adding contexts to a 
started host). (remm)
+  
+  
+ 42309: Ability to create a connector using a custom 
protocol specification for embedded.
+ (fhanik)
+  
+  
+ Add SSL engine flag to AprLifecycleListener. (fhanik)
+  
+  
+ Improve event processing, so that an END event is generated when 
encountering EOF, and an
+ ERROR is always generated on client disconnects. (remm)
+  
+  
+ Add declarations for the new XSD files. (remm)
+  
+
+  
+  
+
+  
+ Add heartbeatBackgroundEnabled flag to SimpleTcpCluster. 
+ Enable this flag don't forget to disable the channel heartbeat thread 
(pero)
+  
+  
+ Possible memory leak when using comet, caused by adding the socket to 
the poller before
+ cleaning up the connection tracking structure. (remm)
+  
+  
+ 42308: nextRequest recycles the request, which caused 
issues with statistics. (remm)
+  
+  
+ Fix non recycled comet flag in the APR connector. (remm)
+  
+
+  
   
 
   
  Add heartbeatBackgroundEnabled flag to SimpleTcpCluster. 
  Enable this flag don't forget to disable the channel heartbeat thread 
(pero)
+  
+  
+ Method name cleanup. (fhanik)
+  
+
+  
+  
+
+  
+ Some examples webapp fixes. Submitted by Frank McCown. (remm)
   
 
   



-
To unsubscribe, e-mail: [EMAIL PROTECT

DO NOT REPLY [Bug 42337] New: - jasper-howto docs should use bin/catalina-tasks.xml

2007-05-04 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=42337

   Summary: jasper-howto docs should use bin/catalina-tasks.xml
   Product: Tomcat 6
   Version: unspecified
  Platform: All
   URL: http://tomcat.apache.org/tomcat-6.0-doc/jasper-
howto.html
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The instructions for using Ant to pre-compile jsp pages with the Jasper compiler
should demonstrate using bin/catalina-tasks.xml instead of including all of the
code to perform this manually.  This will reduce complexity that is exposed to
the users and adhere to the "once and only once" rule.

Example:

 
  

   

  

...
etc.

-- 
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 42337] - jasper-howto docs should use bin/catalina-tasks.xml

2007-05-04 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=42337





--- Additional Comments From [EMAIL PROTECTED]  2007-05-04 11:12 ---
Created an attachment (id=20132)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20132&action=view)
replaces ant task definition with catalina-tasks.xml include file


-- 
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: r535416 - /tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml

2007-05-04 Thread remm
Author: remm
Date: Fri May  4 16:57:58 2007
New Revision: 535416

URL: http://svn.apache.org/viewvc?view=rev&rev=535416
Log:
- Use the main xml file for tasks.
- Submitted by Daniel Santos.

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml?view=diff&rev=535416&r1=535415&r2=535416
==
--- tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml Fri May  4 16:57:58 2007
@@ -194,21 +194,11 @@
 
  
 
-   
+   
+  
+    
 
- 
-   
- 
- 
-   
- 
- 
-   
- 
-   
- 
-
-

svn commit: r535433 - in /tomcat/tc6.0.x/trunk: build.xml dist.xml extras.xml

2007-05-04 Thread remm
Author: remm
Date: Fri May  4 18:26:05 2007
New Revision: 535433

URL: http://svn.apache.org/viewvc?view=rev&rev=535433
Log:
- Extras build update.
- Year update.

Modified:
tomcat/tc6.0.x/trunk/build.xml
tomcat/tc6.0.x/trunk/dist.xml
tomcat/tc6.0.x/trunk/extras.xml

Modified: tomcat/tc6.0.x/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.xml?view=diff&rev=535433&r1=535432&r2=535433
==
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Fri May  4 18:26:05 2007
@@ -13,7 +13,7 @@
 
   
   
-  
+  
   
   
   

Modified: tomcat/tc6.0.x/trunk/dist.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/dist.xml?view=diff&rev=535433&r1=535432&r2=535433
==
--- tomcat/tc6.0.x/trunk/dist.xml (original)
+++ tomcat/tc6.0.x/trunk/dist.xml Fri May  4 18:26:05 2007
@@ -13,7 +13,7 @@
 
   
   
-  
+  
   
   
   
@@ -30,6 +30,7 @@
   
   
   
+  
   
   
   
@@ -344,7 +345,7 @@
   author="true" version="true"
   windowtitle="Tomcat API Documentation"
   doctitle="Tomcat API"
-  bottom="Copyright © 2000-2006 Apache Software Foundation.  All 
Rights Reserved."
+  bottom="Copyright © 2000-2007 Apache Software Foundation.  All 
Rights Reserved."
   additionalparam="-breakiterator"
   maxmemory="256m" >
 
@@ -465,6 +466,13 @@
 tofile="${tomcat.release}/v${version}/bin/README.html"
  filtering="true"/>
 
+
+
+  
+
+  
+
+   
   
 
   

Modified: tomcat/tc6.0.x/trunk/extras.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/extras.xml?view=diff&rev=535433&r1=535432&r2=535433
==
--- tomcat/tc6.0.x/trunk/extras.xml (original)
+++ tomcat/tc6.0.x/trunk/extras.xml Fri May  4 18:26:05 2007
@@ -13,7 +13,7 @@
 
   
   
-  
+  
   
   
   
@@ -136,6 +136,8 @@
 
   
 
+
 
 
   
@@ -149,6 +151,8 @@
 
   
 
+
 
   
 
@@ -196,6 +200,8 @@

  

+

   
 



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



svn commit: r535436 - /tomcat/tc6.0.x/tags/TOMCAT_6_0_13/

2007-05-04 Thread remm
Author: remm
Date: Fri May  4 18:36:07 2007
New Revision: 535436

URL: http://svn.apache.org/viewvc?view=rev&rev=535436
Log:
- Tomcat 6.0.13 tag.

Added:
tomcat/tc6.0.x/tags/TOMCAT_6_0_13/
  - copied from r535435, tomcat/tc6.0.x/trunk/


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



Candidate binaries for 6.0.13

2007-05-04 Thread Remy Maucherat

The new (and most likely cursed) candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.13/

Rémy

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