DO NOT REPLY [Bug 49732] New: reply_timeout can't wait forever.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49732 Summary: reply_timeout can't wait forever. Product: Tomcat Connectors Version: 1.2.30 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2

DO NOT REPLY [Bug 49234] JMX Descriptor Modifications

https://issues.apache.org/bugzilla/show_bug.cgi?id=49234 --- Comment #74 from chamith buddhika 2010-08-10 00:22:51 EDT --- (In reply to comment #73) > Created an attachment (id=25862) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25862) [details] > o.a.Catalina.Core Operations Third

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #5 from Wang Guangzhe 2010-08-09 21:22:19 EDT --- Created an attachment (id=25868) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25868) the war file with only one jar file -- Configure bugmail: https://issues.apa

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #4 from Wang Guangzhe 2010-08-09 21:21:21 EDT --- Created an attachment (id=25867) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25867) the war file with more than one jar files -- Configure bugmail: https://issu

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 Wang Guangzhe changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALI

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #3 from Wang Guangzhe 2010-08-09 21:18:41 EDT --- (In reply to comment #2) > Hi Konstantin, > > During my work on the Tomcat support in Eclipse Web Tools, the only > requirement > I found in the Servlet 3.0 spec for static re

Re: [VOTE] Release Apache Tomcat 7.0.2

Hopefully better late than never: +1 On Aug 5, 2010, at 5:09 PM, Jason Brittain wrote: > Hi all! > > [X] Beta - go ahead and release as 7.0.2 Beta >> > > It seems very close to stable, to me. > > One thing I noticed while testing 7.0.2 is that the WebModule MBean > ObjectNames differ sligh

DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads

https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 sylvain.laur...@gmail.com changed: What|Removed |Added OS/Version||All --- Comment #3 from

DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads

https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 --- Comment #2 from sylvain.laur...@gmail.com 2010-08-09 16:38:47 EDT --- Created an attachment (id=25866) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25866) Patch for tomcat 7 -- Configure bugmail: https://issues.apache.org

DO NOT REPLY [Bug 49730] Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads

https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 --- Comment #1 from sylvain.laur...@gmail.com 2010-08-09 16:38:11 EDT --- Created an attachment (id=25865) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25865) Patch for Tomcat 6 -- Configure bugmail: https://issues.apache.org

DO NOT REPLY [Bug 49730] New: Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads

https://issues.apache.org/bugzilla/show_bug.cgi?id=49730 Summary: Race condition in StandardThreadExecutor : requests are sometimes enqueued instead of creating new threads Product: Tomcat 6 Version: 6.0.29 Platform: Macintosh

DO NOT REPLY [Bug 49728] New: catalina.sh PID file handling not working if started by initscript

https://issues.apache.org/bugzilla/show_bug.cgi?id=49728 Summary: catalina.sh PID file handling not working if started by initscript Product: Tomcat 6 Version: 6.0.29 Platform: PC OS/Version: Linux Status: NEW

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 --- Comment #2 from Larry Isaacs 2010-08-09 09:48:40 EDT --- Hi Konstantin, During my work on the Tomcat support in Eclipse Web Tools, the only requirement I found in the Servlet 3.0 spec for static resources in a jar was that they be fou

improvement for changed PID file handling in catalina.sh since 6.0.24

Hi, the PID file handling was changed in 6.0.24 in catalina.sh, which avoid the use of an initscript to start tomcat proper (e.g. on CentOS/RHEL5). catalina.sh is currently too strict regarding existing PID file and has imho a too lightweight check. Below is a patch which improves the PID fi

Re: Sharing Native Library from parent classloader?

On 08/09/2010 12:15 PM, Konstantin Kolinko wrote: 2010/8/7 Brock Noland: 1. This is a question for the users@ list, not dev@, because it is not about improving Tomcat, but about running your webapp. But it could be. 2. Tomcat Native library is loaded by org.apache.catalina.core.AprLifecycl

Re: Sharing Native Library from parent classloader?

2010/8/7 Brock Noland : > Hello, > > I have a legacy application written in C.  The library is wrapped in JAVA as > the supporting applications are all JAVA based. The problem we are running > into is that although the library is thread safe the java wrapper is not. >  Changing the wrapper would be

DO NOT REPLY [Bug 49721] Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=49721 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [g...@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed

On 2010-08-09, Bill Barker wrote: > From: "Stefan Bodewig" >> this is due to a configuration error in Gump that I caused - fixed now. > I can't find the fix on the Gump list, I've modified junit's projec