DO NOT REPLY [Bug 44257] - User sessions become invalid Randomly

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 03:50 ---
This looks like it could be similar to bug 25792. This part of the code changed
quite a bit in TC5 so I'll have to do some digging.

-- 
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: DOS-Lineends in many files contained in distribution tar.gz

[Filip Hanik - Dev Lists]

Rainer Jung wrote:

Hi Filip,

Filip Hanik - Dev Lists schrieb:
what effect do the line endings actually have, from a functionality 
point?


It's more the human factor. I expect none of the mentioned files to 
fail fatally with DOS style on Unix. On the other hand some of those 
are also explicitely for humans and I find it very dirty to provide a 
tar.gz download with DOS text files in it.


Maybe more convincing: the way we do it provides Unix style LICENSE 
and NOTICE file inside the deployer ZIP. So our procedure really is 
broken.


Bill Wrowe's approach seems to be easy. Fix once the props in svn and 
then do two release builds, one based on a DOS style checkout, and 
another one based on a Unix style checkout. It would allow an easier 
dist.xml and still better release files.

that'd be a real pain, and I would stay away from it.
the beauty with java is that we can compile it once, and the same 
release for all platforms. I'd -1 building on separate platforms just 
cause human factor line endings.


only if it affects the distro in a negative way would I actually go 
through all this trouble. but I haven't had any problems so far, and 
we are on all kinds of platforms


It depends on your definition of problem: users say: "We downloaded 
the Unix tarball and there are mostly Windows files in there. What 
went wrong with your release?".

not sure I follow, is there something that doesn't work?



Regards,

Rainer


Filip

Rainer Jung wrote:

Hello,

no unfortunately I don't expect the patch to work. The fixcrlf is 
done before packaging and in the dist.xml the various packagings 
(dist, deployer, source, ...) are included in alternating platform 
order, so first dist Win, then dist Unix, then deployer Win, then 
deployer Unix and so on. If we change the line endings for some 
deliverable to unix, we can't use the files later in another Win 
deliverable.


Example: Look at the 6.0.14 deployer zip. The LICENSE file included 
has unix line ends, because it got "fixed" for inclusion in the unix 
core distro before the Win deployer zip was produced.


So we either:

- reorder the targets underneath "release" (Windows first and Unix 
afterwards (which then would make release builds on a windows system 
OK, but not on a unix system). Then the default target works, but 
calling the dist.xml with other targets alternating between target 
platforms without clean in between would produce buggy deliverables.


If we reorder, we need to check, if there are side effects between 
the tasks, s.t. reordering breaks the release build.


- cleanup and prepare for each of the targets underneath or "release".

Either way, since in the source tgz target there is already an 
exclude list, I would prefer to update that exclude list and use the 
same one whereever possible, so something like:


===
--- dist.xml(revision 608958)
+++ dist.xml(working copy)
@@ -560,8 +560,12 @@

   
   
-includes="*.txt,LICENSE,NOTICE" eol="lf"/>

+
+includes="*.txt,LICENSE,NOTICE,RELEASE-NOTES" eol="lf"/>

+
 
++ 
excludes="**/*.jar,**/*.classes,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico,**/*.pdf,**/*.war" 
eol="lf"/>

   
tarfile="${tomcat.release}/v${version}/bin/${final.name}.tar.gz">
   prefix="${final.name}">

@@ -711,7 +715,7 @@
   
   
- 
excludes="**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico,**/*.war" 
eol="lf"/>
+ 
excludes="**/*.jar,**/*.classes,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico,**/*.pdf,**/*.war" 
eol="lf"/>

 
   prefix="${final-src.name}" />


But I think we first have to correct the ordering issue.

However I'm not sure, if I should go into it, because I'm not the 
biggest ant guy :)


Remy: Since you are the RM of 6.0: are you going into this topic, or 
should we try to solve it?


Regards,

Rainer


Peter Rossbach wrote:

Hi Rainer,

+1..


Is it fix with followig patch?
===
Index: tomcat60/dist.xml
===
--- /tomcat60/dist.xml(Revision 613549)
+++ tomcat/tomcat60/dist.xml(Arbeitskopie)
@@ -561,6 +561,22 @@
   
 includes="*.txt,LICENSE,NOTICE" eol="lf"/>

 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
   
tarfile="${tomcat.release}/v${version}/bin/${final.name}.tar.gz">
   prefix="${final.name}">

==

Peter


Am 25.01.2008 um 01:47 schrieb Rainer Jung:


Hi,

I stumbled today over DOS line endings in the web.xml file of the 
manager contained in TC 6.0.14 tar.gz download.


A little check reveals, that the following files have DOS line 
endings, although the tar.gz is supposed to use Unix convention 
were appropriate:


- RELEASE-NOTES
- bin/catalina-tasks.xml

and in webapps all files with suffixes:

Count Suffix
 286 html
  46 java
  48 jsp
  12 txt
  11 xml
   5 properties
   4 tag
   3 tld
   2 jspf
   2

DO NOT REPLY [Bug 44298] New: - Consistent Bad level "DEBUG" error introduced to java.util.logging.Level.parse routine

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

   Summary: Consistent Bad level "DEBUG" error introduced to
java.util.logging.Level.parse routine
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: Windows 2000
Status: NEW
  Severity: minor
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Handler error
java.lang.IllegalArgumentException: Bad level "DEBUG"
at java.util.logging.Level.parse(Level.java:336)
at org.apache.juli.FileHandler.configure(FileHandler.java:205)
at org.apache.juli.FileHandler.(FileHandler.java:58)
at org.apache.juli.FileHandler.(FileHandler.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:398)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:342)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:238)
at java.util.logging.LogManager$2.run(LogManager.java:258)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.j
ava:256)
at java.util.logging.LogManager.getLogManager(LogManager.java:239)
at java.util.logging.Logger.(Logger.java:221)
at java.util.logging.LogManager$RootLogger.(LogManager.java:973)
at java.util.logging.LogManager$RootLogger.(LogManager.java:970)
at java.util.logging.LogManager$1.run(LogManager.java:179)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.(LogManager.java:156)
at java.util.logging.Logger.getLogger(Logger.java:274)
at sun.management.snmp.util.MibLogger.(MibLogger.java:57)
at sun.management.snmp.util.MibLogger.(MibLogger.java:42)
at sun.management.jmxremote.ConnectorBootstrap.(ConnectorBootstr
ap.java:710)
at sun.management.Agent.startAgent(Agent.java:135)
at sun.management.Agent.startAgent(Agent.java:239)
Handler error
java.lang.IllegalArgumentException: Bad level "DEBUG"
at java.util.logging.Level.parse(Level.java:336)
at org.apache.juli.FileHandler.configure(FileHandler.java:205)
at org.apache.juli.FileHandler.(FileHandler.java:58)
at org.apache.juli.FileHandler.(FileHandler.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:398)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:342)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLo
gManager.java:238)
at java.util.logging.LogManager$2.run(LogManager.java:258)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.j
ava:256)
at java.util.logging.LogManager.getLogManager(LogManager.java:239)
at java.util.logging.Logger.(Logger.java:221)
at java.util.logging.LogManager$RootLogger.(LogManager.java:973)
at java.util.logging.LogManager$RootLogger.(LogManager.java:970)
at java.util.logging.LogManager$1.run(LogManager.java:179)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.(LogManager.java:156)
at java.util.logging.Logger.getLogger(Logger.java:274)
at sun.management.snmp.util.MibLogger.(MibLogger.java:57)
at sun.management.snmp.util.MibLogger.(MibLogger.java:42)
at sun.management.jmxremote.ConnectorBootstrap.(Conn

DO NOT REPLY [Bug 44257] - User sessions become invalid Randomly

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 07:54 ---
Having looked at bug 25792 and tested it on the latest TC4 code, it appears to
have been caused by some early TC5 refactoring and so is not an issue for TC4.

The obvious thing for you to try is to upgrade to 4.1.36. I checked the release
notes and I don't see any obvious changes that might be a fix for this issue but
there are plenty of other fixes worth having.

Your deduction that the user's session ID is being set to null is not consistent
with the way sessions are managed by Tomcat. For whatever reason, the session
the user requests does not exist. It could be that the session has expired
(rightly or wrongly) or the client could be requesting an invalid session ID.

At the minute, this looks more like an application or configuration issue rather
than a Tomcat bug. My recommendation is that you implement a combination of
session listener, request logging and some application logging to confirm:
- when sessions are created and destroyed
- the session requested in each request
- the session being used in each request

This should help get to the root of this issue.

Bugzilla is not meant to be used as a support forum. Therefore, I suggest you
use the users list to seek help in tracking down the source of this issue. For
now, I am closing this as invalid. If the users list discussion concludes there
is a bug here then the issue can be re-opened and the steps to reproduce the
issue added.

-- 
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 44299] New: - Provider manager app with a log out button

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

   Summary: Provider manager app with a log out button
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P4
 Component: Manager application
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A log out button would enable users to log out of the manager application and
end the associated session without having to close the browser window.

-- 
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 44275] - isapi_redirect.dll denies access to URI's with META-INF / WEB-INF anywere in the URI

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 09:53 ---
Maybe someone should remove the check like mtruk suggests in
http://issues.apache.org/bugzilla/show_bug.cgi?id=39614#c1 and actually provide
a test case that proves the resulting system violates the servlet spec.

isapi_redirector is a "connector"
Apache Tomcat is a "servlet container"

Since it is the servlet container specification which is being cited as the
reason for the check and it is my believe that no matter what connector the
inbound HTTP requests come in via (Coyete, AJP/mod_jk/isapi_redirector) that
Apache Tomcat will police the situation and return a 404 as the servlet
specification requires.


-- 
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 44275] - isapi_redirect.dll denies access to URI's with META-INF / WEB-INF anywere in the URI

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 10:08 ---
To repeat what I said earlier in this bug;

If you have a patch for this issue that you believe would be safe, please feel
free to re-open this issue and attach your patch for review.

-- 
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: r615478 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/manager/LocalStrings.properties java/org/apache/catalina/manager/ManagerServlet.java webapps/docs/changelog.xml

[pero]

Author: pero
Date: Sat Jan 26 11:52:28 2008
New Revision: 615478

URL: http://svn.apache.org/viewvc?rev=615478&view=rev
Log:
Fix ManagerServlet.exipreSession throws Exceptions as iterate longer 
session lists at production servers.

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=615478&r1=615477&r2=615478&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Sat Jan 26 11:52:28 2008
@@ -38,17 +38,6 @@
   -1: remm: I believe it would need specific support for certain managers. 
Interested users
 could use their own extended manager instead.
 
-* Fix ManagerServlet.expireSessions throws Exceptions as iterate longer 
session lists 
-  at production servers.
-  http://svn.apache.org/viewvc?rev=612988&view=rev
-  +1: pero, rjung, remm
-  -1: 
-  rjung: as pero wrote: the patch contains
-  - r612944 fixed in HTMLManager but not in Manager
-  - a fix aiaginst an exception when listing session idle time
-histogram and at least one session timed out since last
-run of invalidation background task
-
 * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=44223
   Add support for remaining truststore system property
   Not essential for 6.0.16.

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties?rev=615478&r1=615477&r2=615478&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/LocalStrings.properties 
Sat Jan 26 11:52:28 2008
@@ -73,6 +73,7 @@
 managerServlet.noDirectory=FAIL - Non-directory document base for path {0}
 managerServlet.noDocBase=FAIL - Cannot undeploy document base for path {0}
 managerServlet.noGlobal=FAIL - No global JNDI resources are available
+managerServlet.noManager=FAIL - No manager exists for path {0}
 managerServlet.noReload=FAIL - Reload not supported on WAR deployed at path {0}
 managerServlet.noRename=FAIL - Cannot deploy uploaded WAR for path {0}
 managerServlet.noRole=FAIL - User does not possess role {0}

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java?rev=615478&r1=615477&r2=615478&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/ManagerServlet.java 
Sat Jan 26 11:52:28 2008
@@ -47,6 +47,7 @@
 import org.apache.catalina.Globals;
 import org.apache.catalina.Host;
 import org.apache.catalina.Lifecycle;
+import org.apache.catalina.Manager;
 import org.apache.catalina.Role;
 import org.apache.catalina.Server;
 import org.apache.catalina.ServerFactory;
@@ -1115,8 +1116,14 @@
 RequestUtil.filter(displayPath)));
 return;
 }
+Manager manager = context.getManager() ;
+if(manager == null) {
+   writer.println(sm.getString("managerServlet.noManager",
+   RequestUtil.filter(displayPath)));
+   return;   
+}
 int maxCount = 60;
-int maxInactiveInterval = 
context.getManager().getMaxInactiveInterval()/60;
+int maxInactiveInterval = manager.getMaxInactiveInterval()/60;
 int histoInterval = maxInactiveInterval / maxCount;
 if ( histoInterval * maxCount < maxInactiveInterval ) 
 histoInterval++;
@@ -1127,13 +1134,13 @@
 writer.println(sm.getString("managerServlet.sessions", 
displayPath));
 writer.println(sm.getString("managerServlet.sessiondefaultmax",
 "" + maxInactiveInterval));
-Session [] sessions = context.getManager().findSessions();
+Session [] sessions = manager.findSessions();
 int [] timeout = new int[maxCount];
 int notimeout = 0;
 int expired = 0;
 long now = System.currentTimeMillis();
 for (int i = 0; i < sessions.length; i++) {
-int time = (int)((now-sessions[i].getLastAccessedTime())/1000);
+int time = 
(int)((now-sessi

DO NOT REPLY [Bug 43878] - Tag-file classes get loaded for each JSP -> perm gen space problem

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 11:30 ---
Looking at it, my patch is clearly nonsense. I'm working on one that actually
works...

-- 
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 43878] - Tag-file classes get loaded for each JSP -> perm gen space problem

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-26 14:53 ---
Hi Mark,

thanks for the heads-up - I´ll forward it to my colleagues to let them know that
they don't need to start testing.

Philipp


-- 
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 44300] New: - Setting enablePooling to false has no effect

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

   Summary: Setting enablePooling to false has no effect
   Product: Tomcat 6
   Version: 6.0.14
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: blocker
  Priority: P2
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Configuring the JspServlet as below has no effect.
Tomcat 6.0.14 still pools the custom tags.

It has been proven that pooling custom tags does NOT yield the performance
expected but introduces bugs.
Please fix this bug, and further disable pooling by default.


jsp
org.apache.jasper.servlet.JspServlet

fork
false


xpoweredBy
false


enablePooling
false

3


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