DO NOT REPLY [Bug 39090] - Memory Leak: Tomcat files keep references to classes loaded by WebappClassLoader

[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=39090


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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] Split soTimeout to soTimeout and keepAliveTimeout

[Mladen Turk]

Hi all,

I would like to propose a simple vote on the thing I consider
as very important. It's probably the first vote ever done for
the commited code, but the reasons are known for the folks reading
tomcat dev list.

The things we have right now for dealing with Keep-Alive is
dependent only on the soTimeout.

I propose that we split that to the real soTimeout which is the
timeout between two consecutive read() on http request and the
additional keepAliveTimeout that will be used for determining the
timeout between two requests.

Few reason why we should need those timeouts separately
configured is:

1. Why not, if its possible without breaking current config ?
2. If the timeout between two request is lower then soTimeout it
   will allow to have much higher number of slow clients
3. If the timeout between two requests is higher then soTimeout
   it will allow to deal with slow clients sending one byte at the
   the time with the unacceptable rate.

So, I'll just throw a vote here:

[ ] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care

Of course, there is always an option to have an veto.

As many of you already know, the code itself was already
in the SVN, but it was reverted.

Regards,
Mladen.


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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Yoav Shapira]

Hi,

On 10/2/06, Mladen Turk <[EMAIL PROTECTED]> wrote:

I propose that we split that to the real soTimeout which is the
timeout between two consecutive read() on http request and the
additional keepAliveTimeout that will be used for determining the
timeout between two requests.



[ X ] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care


I'm for it with one condition -- that it be documented clearly not
just in the code but in the configuration reference as well,
preferably with the documentation committed at the same time as patch.
I don't think this is generally very important, and I think only a
few users will need it, but for them it could indeed be valuable, and
it does no big harm.

Yoav

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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Remy Maucherat]

Mladen Turk wrote:

Hi all,

I would like to propose a simple vote on the thing I consider
as very important.


I see that.


The things we have right now for dealing with Keep-Alive is
dependent only on the soTimeout.

I propose that we split that to the real soTimeout which is the
timeout between two consecutive read() on http request and the
additional keepAliveTimeout that will be used for determining the
timeout between two requests.

Few reason why we should need those timeouts separately
configured is:

1. Why not, if its possible without breaking current config ?
2. If the timeout between two request is lower then soTimeout it
   will allow to have much higher number of slow clients
3. If the timeout between two requests is higher then soTimeout
   it will allow to deal with slow clients sending one byte at the
   the time with the unacceptable rate.


Only scenario 3 is not available currently, and it seems useless (in 
particular for the java.io connector, which can never afford having a 
long timeout while waiting for the next request). If you really want a 
property named "keealiveTimeout", then "disableUploadTimeout" can be 
refactored into it.



So, I'll just throw a vote here:

[ ] I'm for that proposal
[ ] I'm against that proposal
[X] I don't care

Of course, there is always an option to have an veto.


Hmmm.


As many of you already know, the code itself was already
in the SVN, but it was reverted.


No, I had made some adjustments to it, and then you reverted it, along 
with a couple of my other patches. I do not think the defaults you 
implemented were sensible either (especially for AJP). Apparently is not 
allowed.


Rémy

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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Filip Hanik - Dev Lists]

where is this proposed, 6.0 or 5.5.x dot release?

Filip


Mladen Turk wrote:

Hi all,

I would like to propose a simple vote on the thing I consider
as very important. It's probably the first vote ever done for
the commited code, but the reasons are known for the folks reading
tomcat dev list.

The things we have right now for dealing with Keep-Alive is
dependent only on the soTimeout.

I propose that we split that to the real soTimeout which is the
timeout between two consecutive read() on http request and the
additional keepAliveTimeout that will be used for determining the
timeout between two requests.

Few reason why we should need those timeouts separately
configured is:

1. Why not, if its possible without breaking current config ?
2. If the timeout between two request is lower then soTimeout it
   will allow to have much higher number of slow clients
3. If the timeout between two requests is higher then soTimeout
   it will allow to deal with slow clients sending one byte at the
   the time with the unacceptable rate.

So, I'll just throw a vote here:

[ ] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care

Of course, there is always an option to have an veto.

As many of you already know, the code itself was already
in the SVN, but it was reverted.

Regards,
Mladen.


-
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]

svn commit: r452091 - in /tomcat/tc6.0.x/trunk: ./ webapps/docs/

[remm]

Author: remm
Date: Mon Oct  2 08:52:29 2006
New Revision: 452091

URL: http://svn.apache.org/viewvc?view=rev&rev=452091
Log:
- Doc updates.

Added:
tomcat/tc6.0.x/trunk/webapps/docs/aio.xml   (with props)
Modified:
tomcat/tc6.0.x/trunk/RELEASE-NOTES
tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml
tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml
tomcat/tc6.0.x/trunk/webapps/docs/logging.xml
tomcat/tc6.0.x/trunk/webapps/docs/manager-howto.xml
tomcat/tc6.0.x/trunk/webapps/docs/mbeans-descriptor-howto.xml
tomcat/tc6.0.x/trunk/webapps/docs/realm-howto.xml

Modified: tomcat/tc6.0.x/trunk/RELEASE-NOTES
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/RELEASE-NOTES?view=diff&rev=452091&r1=452090&r2=452091
==
--- tomcat/tc6.0.x/trunk/RELEASE-NOTES (original)
+++ tomcat/tc6.0.x/trunk/RELEASE-NOTES Mon Oct  2 08:52:29 2006
@@ -71,7 +71,7 @@
 * catalina-ha.jar (High availability package)
 * catalina-tribes.jar (Group communication)
 * commons-logging-api.jar (Commons Logging API 1.0.x)
-* el-api.jar (EL 1.0 API)
+* el-api.jar (EL 2.1 API)
 * jasper.jar (Jasper 2 Compiler and Runtime)
 * jasper-el.jar (Jasper 2 EL implementation)
 * jasper-jdt.jar (Eclipse JDT 3.2 Java compiler)

Added: 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=auto&rev=452091
==
--- tomcat/tc6.0.x/trunk/webapps/docs/aio.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/aio.xml Mon Oct  2 08:52:29 2006
@@ -0,0 +1,24 @@
+
+
+]>
+
+
+&project;
+
+  
+Advanced IO and Tomcat
+Remy Maucherat
+  
+
+
+
+  
+
+  
+  
+
+  
+
+
+

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/aio.xml
--
svn:eol-style = native

Modified: tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml?view=diff&rev=452091&r1=452090&r2=452091
==
--- tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml Mon Oct  2 
08:52:29 2006
@@ -15,30 +15,9 @@
 
 
 
-
-
-The following rules cover about 95% of the decisions that application
-developers and deployers must make about where to place class and resource
-files to make them available to web applications:
-
-For classes and resources specific to a particular web application,
-place unpacked classes and resources under /WEB-INF/classes
-of your web application archive, or place JAR files containing those
-classes and resources under /WEB-INF/lib of your web
-application archive.
-For classes and resources that must be shared across all web applications,
-place unpacked classes and resources under
-$CATALINA_BASE/shared/classes, or place JAR files
-containing those classes and resources under
-$CATALINA_BASE/shared/lib.
-
-
-
-
-
 
 
-Like many server applications, Tomcat 5 installs a variety of class loaders
+Like many server applications, Tomcat 6 installs a variety of class loaders
 (that is, classes that implement java.lang.ClassLoader) to allow
 different portions of the container, and the web applications running on the
 container, to have access to different repositories of available classes and
@@ -53,7 +32,7 @@
 web application class loaders differs slightly from this, as discussed below,
 but the main principles are the same.
 
-When Tomcat 5 is started, it creates a set of class loaders that are
+When Tomcat 6 is started, it creates a set of class loaders that are
 organized into the following parent-child relationships, where the parent
 class loader is above the child class loader:
 
@@ -63,10 +42,8 @@
System
   |
Common
-  /  \
- Catalina   Shared
- /   \
-Webapp1  Webapp2 ... 
+   / \
+  Webapp1   Webapp2 ... 
 
 
 The characteristics of each of these class loaders, including the source
@@ -77,7 +54,7 @@
 
 
 
-As indicated in the diagram above, Tomcat 5 creates the following class
+As indicated in the diagram above, Tomcat 6 creates the following class
 loaders as it is initialized:
 
 Bootstrap - This class loader contains the basic runtime
@@ -96,97 +73,41 @@
 build the System class loader from the following repositories:
 
 $CATALINA_HOME/bin/bootstrap.jar - Contains the main() method
-that is used to initialize the Tomcat 5 server, and the class loader
+that is used to initialize the Tomcat 6 server, and the class loader
 implementation classes it depends on.
-$JAVA_HOME/lib/tools.jar - Contains the "javac" compiler used
-to convert JSP pages into servlet classes.
 $CATALINA_

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Mladen Turk]

Filip Hanik - Dev Lists wrote:

where is this proposed, 6.0 or 5.5.x dot release?



Sorry it's targeted for 6.0
(I thought it was clear from the patches)

Regards,
Mladen

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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Filip Hanik - Dev Lists]

[X] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care

Filip


Mladen Turk wrote:

Hi all,

I would like to propose a simple vote on the thing I consider
as very important. It's probably the first vote ever done for
the commited code, but the reasons are known for the folks reading
tomcat dev list.

The things we have right now for dealing with Keep-Alive is
dependent only on the soTimeout.

I propose that we split that to the real soTimeout which is the
timeout between two consecutive read() on http request and the
additional keepAliveTimeout that will be used for determining the
timeout between two requests.

Few reason why we should need those timeouts separately
configured is:

1. Why not, if its possible without breaking current config ?
2. If the timeout between two request is lower then soTimeout it
   will allow to have much higher number of slow clients
3. If the timeout between two requests is higher then soTimeout
   it will allow to deal with slow clients sending one byte at the
   the time with the unacceptable rate.

So, I'll just throw a vote here:

[ ] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care

Of course, there is always an option to have an veto.

As many of you already know, the code itself was already
in the SVN, but it was reverted.

Regards,
Mladen.


-
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] Split soTimeout to soTimeout and keepAliveTimeout

[Bill Barker]

 

> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 02, 2006 4:25 AM
> To: tomcat Developers List
> Subject: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout
> 
> Hi all,
> 
> I would like to propose a simple vote on the thing I consider
> as very important. It's probably the first vote ever done for
> the commited code, but the reasons are known for the folks reading
> tomcat dev list.
> 
> The things we have right now for dealing with Keep-Alive is
> dependent only on the soTimeout.
> 
> I propose that we split that to the real soTimeout which is the
> timeout between two consecutive read() on http request and the
> additional keepAliveTimeout that will be used for determining the
> timeout between two requests.
> 
> Few reason why we should need those timeouts separately
> configured is:
> 
> 1. Why not, if its possible without breaking current config ?
> 2. If the timeout between two request is lower then soTimeout it
> will allow to have much higher number of slow clients
> 3. If the timeout between two requests is higher then soTimeout
> it will allow to deal with slow clients sending one byte at the
> the time with the unacceptable rate.
> 

I pretty much agree with Remy:  Anything useful this would do has been in
place since the early days of Coyote.  Also, anybody that actually would
care about this option almost certainly wouldn't be using the JIO Connector
:).

> So, I'll just throw a vote here:
> 
> [ ] I'm for that proposal
> [ ] I'm against that proposal
> [X] I don't care
> 
> Of course, there is always an option to have an veto.
> 
> As many of you already know, the code itself was already
> in the SVN, but it was reverted.
> 
> Regards,
> Mladen.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Mladen Turk]

Bill Barker wrote:




I pretty much agree with Remy:  Anything useful this would do has been in
place since the early days of Coyote.  Also, anybody that actually would
care about this option almost certainly wouldn't be using the JIO Connector
:).



Fair enough.
Someone even said that there is no market for more then
five computers in the entire world :)

Regards,
Mladen.

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

DO NOT REPLY [Bug 38898] - Tomcat service fails without error message

[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=38898





--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 13:21 ---
You could attach hs_err_pid.log's till you're blue in the face, but nothing
changes the fact that what's wrong here is a *Java Virtual Machine* bug, not a
*Tomcat source* bug.

JVM crashes can happen for as much of a variety of reasons as an OS "blue screen
of death" - Java Virtual Machine internal coding errors, driver bugs, OS bugs,
hardware quirks, ...

First order of business: use the latest Java VM version (1.5.0_08 as of today).
See if this still happens.

Then, take your application to a different machine (different OS, and preferably
different architecture, e.g. Solaris on Sparc), and try to make it crash the
same way using the *exact same inputs*.

-- 
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]

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Mark Thomas]

Mladen Turk wrote:
> [X] I'm for that proposal
> [ ] I'm against that proposal
> [ ] I don't care

If you believe there is a requirement for it, the implementation can
be done cleanly and you are prepared to support it then go for it.

I would like to echo Yoav's comments that the docs should be updated
at the same time.

Mark

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

svn commit: r452281 - /tomcat/tc6.0.x/trunk/webapps/docs/aio.xml

[remm]

Author: remm
Date: Mon Oct  2 17:17:20 2006
New Revision: 452281

URL: http://svn.apache.org/viewvc?view=rev&rev=452281
Log:
- First pass at docs.

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/aio.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=452281&r1=452280&r2=452281
==
--- tomcat/tc6.0.x/trunk/webapps/docs/aio.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/aio.xml Mon Oct  2 17:17:20 2006
@@ -16,7 +16,263 @@
   
 
   
+With usage of APR or NIO APIs as the basis of its connectors, Tomcat is 
+able to provide a number of extensions over the regular blocking IO 
+as provided with support for the Servlet API.
   
+
+  
+
+  
+
+  
+Comet support allows a servlet to process IO aynchronously, recieving
+events when data is available for reading on the connection (rather than
+always using a blocking read), and writing data back on connections
+asychnonously (most likely responding to some event raised from some
+other source).
+  
+
+  
+  
+  
+Servlets which implement the 
org.apache.catalina.CometProcessor
+interface will have their event method invoked rather than the usual 
service
+method, according to the event which occurred. The event object gives
+access to the usual request and response objects, which may be used in the
+usual way. The main difference is that those objects remain valid and fully
+functional at any time between processing of the BEGIN event until 
processing
+an END or ERROR event.
+The following event types exist:
+  
+  
+  
+  EventType.BEGIN: will be called at the beginning 
+ of the processing of the connection. It can be used to initialize any 
relevant 
+ fields using the request and response objects. Between the end of the 
processing 
+ of this event, and the beginning of the processing of the end or error 
events,
+ it is possible to use the response object to write data on the open 
connection.
+ Note that the response object and depedent OutputStream and Writer are 
still 
+ not synchronized, so when they are accessed by multiple threads, 
+ synchronization is mandatory. After processing the initial event, the 
request 
+ is considered to be committed.
+  EventType.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 or an EOF, the servlet 
MUST
+ report it by either returning false or throwing an exception such as an 
+ IOException. This will cause the error event to be invoked, and the 
connection
+ will be closed. It is not allowed to attempt reading data from the 
request object
+ outside of the execution of this method.
+  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.
+  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
+ been processed, the request and response objects, as well as all their 
dependent
+ objects will be recycled and used to process other requests.
+  
+
+  
+As described above, the typical lifecycle of a Comet request will consist 
in a series of
+events such as: BEGIN -> READ -> READ -> READ -> ERROR/TIMEOUT. At any 
time, the servlet 
+may end processing of the request by using the close method of the event 
object.
+  
+  
+  
+
+  
+  
+  
+Similar to regular filters, a filter chain is invoked when comet events 
are processed.
+These filters should implement the CometFilter interface (which works in 
the same way as 
+the regular Filter interface), and should be declared and mapped in the 
deployment
+descriptor in the same way as a regular filter. The filter chain when 
processing an event
+will only include filters which match all the usual mapping rules, and 
also implement
+the CometFiler interface.
+  
+  
+  
+
+  
+  
+  
+The following pseudo code servlet implments asynchronous chat 
functionality using the API
+described above:
+  
+  
+  
+public class ChatServlet
+extends HttpServlet implements CometProcessor {
+
+protected ArrayList connections = 
+new Ar

svn commit: r452284 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves: FastCommonAccessLogValve.java JDBCAccessLogValve.java PersistentValve.java

[markt]

Author: markt
Date: Mon Oct  2 17:29:57 2006
New Revision: 452284

URL: http://svn.apache.org/viewvc?view=rev&rev=452284
Log:
Remove unused code in o.a.c.valves

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/FastCommonAccessLogValve.java

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/FastCommonAccessLogValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/FastCommonAccessLogValve.java?view=diff&rev=452284&r1=452283&r2=452284
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/FastCommonAccessLogValve.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/FastCommonAccessLogValve.java
 Mon Oct  2 17:29:57 2006
@@ -115,14 +115,6 @@
 
 
 /**
- * If the current log pattern is the same as the common access log
- * format pattern, then we'll set this variable to true and log in
- * a more optimal and hard-coded way.
- */
-private boolean common = false;
-
-
-/**
  * For the combined format (common, plus useragent and referer), we do
  * the same
  */
@@ -249,12 +241,6 @@
  * Resolve hosts.
  */
 private boolean resolveHosts = false;
-
-
-/**
- * Instant when the log daily rotation was last checked.
- */
-private long rotationLastChecked = 0L;
 
 
 /**

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java?view=diff&rev=452284&r1=452283&r2=452284
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java
 Mon Oct  2 17:29:57 2006
@@ -453,20 +453,7 @@
 if(bytes < 0)
 bytes = 0;
 int status = response.getStatus();
-if (pattern.equals("combined")) {
-String virtualHost = "";
-if(request != null)
-virtualHost = request.getServerName();
-String method = "";
-if(request != null)
-method = request.getMethod();
-String referer = "";
-if(request != null)
-referer = request.getHeader("referer");
-String userAgent = "";
-if(request != null)
-userAgent = request.getHeader("user-agent");
-}
+
 synchronized (this) {
   int numberOfTries = 2;
   while (numberOfTries>0) {

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java?view=diff&rev=452284&r1=452283&r2=452284
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/PersistentValve.java
 Mon Oct  2 17:29:57 2006
@@ -29,7 +29,6 @@
 import org.apache.catalina.Store;
 import org.apache.catalina.connector.Request;
 import org.apache.catalina.connector.Response;
-import org.apache.catalina.core.StandardHost;
 import org.apache.catalina.session.PersistentManager;
 import org.apache.catalina.util.StringManager;
 
@@ -96,7 +95,6 @@
 throws IOException, ServletException {
 
 // Select the Context to be used for this Request
-StandardHost host = (StandardHost) getContainer();
 Context context = request.getContext();
 if (context == null) {
 response.sendError



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

DO NOT REPLY [Bug 35914] - Problem to create and delete Access Log Valve many times

[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=35914


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 18:02 ---
I don't see the NPE but the pipeline is not correctly reset on the remove so the
valve doesn't work when re-added. The root cuse is the same as the duplicate.

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

-- 
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 39724] - Bug on StandardPipeline.removeValve(Valve valve) for T5.5.16+

[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=39724


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 18:02 ---
*** Bug 35914 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]

DO NOT REPLY [Bug 39724] - Bug on StandardPipeline.removeValve(Valve valve) for T5.5.16+

[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=39724


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 18:06 ---
Patch applied to SVN and will be in 5.5.21 onwards.

Thanks for tracking this down and providing the patch.

-- 
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: r452287 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/StandardPipeline.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Oct  2 18:06:12 2006
New Revision: 452287

URL: http://svn.apache.org/viewvc?view=rev&rev=452287
Log:
Fix bug 39724. Removing the only valve from a pipeline did not return the 
pipeline to its original state. Patched provided by David Gagnon.

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardPipeline.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardPipeline.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardPipeline.java?view=diff&rev=452287&r1=452286&r2=452287
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardPipeline.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardPipeline.java
 Mon Oct  2 18:06:12 2006
@@ -530,6 +530,8 @@
 current = current.getNext();
 }
 
+if (first == basic) first = null;
+
 if (valve instanceof Contained)
 ((Contained) valve).setContainer(null);
 

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=452287&r1=452286&r2=452287
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Mon Oct  2 18:06:12 2006
@@ -29,6 +29,11 @@
 is required to enable this test. (markt)
   
   
+39724: Removing the last valve from a pipeline did not
+return the pipeline to the original state. Patch provided by
+David Gagon. (markt)
+  
+  
 40528: Add missing message localisations as provided by
 Ben Clifford. (markt)
   



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

svn commit: r452288 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardPipeline.java

[markt]

Author: markt
Date: Mon Oct  2 18:08:32 2006
New Revision: 452288

URL: http://svn.apache.org/viewvc?view=rev&rev=452288
Log:
Port fix for bug 39724. Removing the only valve from a pipeline did not return 
the pipeline to its original state. Patched provided by David Gagnon.

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

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardPipeline.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardPipeline.java?view=diff&rev=452288&r1=452287&r2=452288
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardPipeline.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardPipeline.java 
Mon Oct  2 18:08:32 2006
@@ -530,6 +530,8 @@
 current = current.getNext();
 }
 
+if (first == basic) first = null;
+
 if (valve instanceof Contained)
 ((Contained) valve).setContainer(null);
 



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

DO NOT REPLY [Bug 35943] - request.getRemoteUser() is not getting populated on first time frame requests

[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=35943


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 18:26 ---
This works for me using the latest 5.5.x from SVN.

I suggest you test with the latest 5.5.x release and if you still have problems
please follow up on the users mailing list. You should include the
security-constraint section of your web.xml in your post.

-- 
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: r452291 - in /tomcat/container/tc5.5.x/webapps: admin/resources/envEntry.jsp docs/changelog.xml

[markt]

Author: markt
Date: Mon Oct  2 18:37:46 2006
New Revision: 452291

URL: http://svn.apache.org/viewvc?view=rev&rev=452291
Log:
Fix bug 35968. Make env entry props input a text area. Patch provided by 
Tristan Marly.

Modified:
tomcat/container/tc5.5.x/webapps/admin/resources/envEntry.jsp
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/admin/resources/envEntry.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/admin/resources/envEntry.jsp?view=diff&rev=452291&r1=452290&r2=452291
==
--- tomcat/container/tc5.5.x/webapps/admin/resources/envEntry.jsp (original)
+++ tomcat/container/tc5.5.x/webapps/admin/resources/envEntry.jsp Mon Oct  2 
18:37:46 2006
@@ -131,7 +131,7 @@
   :
 
 
-  
+  
 
   
 

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=452291&r1=452290&r2=452291
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Mon Oct  2 18:37:46 2006
@@ -50,6 +50,10 @@
 a Windows service. (markt)
   
   
+35968: Make environment entry properties input a text area.
+Patch provided by Tristan Marly. (markt)
+  
+  
 40633: Remove references to the DefaultContext from the
 documentation. (markt)
   



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

DO NOT REPLY [Bug 35968] - Please make Environment Entry Properties Value input a textarea

[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=35968


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 18:38 ---
Patch applied. Will be included in 5.5.21 onwards.

Mnay thanks for the patch.

-- 
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 36153] - html:form action is blank

[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=36153


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-10-02 20:22 ---
There isn't anything here I can see that points to a Tomcat issue.

Comment 3 suggests you may wish to follow up on the struts users list.

-- 
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]

Re: [VOTE] Split soTimeout to soTimeout and keepAliveTimeout

[Henri Gomez]

+0

2006/10/3, Mark Thomas <[EMAIL PROTECTED]>:

Mladen Turk wrote:
> [X] I'm for that proposal
> [ ] I'm against that proposal
> [ ] I don't care

If you believe there is a requirement for it, the implementation can
be done cleanly and you are prepared to support it then go for it.

I would like to echo Yoav's comments that the docs should be updated
at the same time.

Mark

-
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]