DO NOT REPLY [Bug 29688] - HostConfig NullPointerException

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

HostConfig NullPointerException

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Critical
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 08:15 ---
The NPE is actually blocking the whole Tomcat, because of infinite number of 
exceptions (s. log). So could someone please commit the patch I provided 
earlier. It's just simple null value checking.

Thanks,
 Sascha

from LOG:

25.06.2004 10:06:58 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor 
processChildren
SCHWERWIEGEND: Exception invoking periodic operation:
java.lang.NullPointerException
at org.apache.catalina.startup.HostConfig.deployDescriptors
(HostConfig.java:445)
at org.apache.catalina.startup.HostConfig.deployApps
(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1064)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:327)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardHost.backgroundProcess
(StandardHost.java:800)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1619)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1628)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run
(ContainerBase.java:1608)
at java.lang.Thread.run(Thread.java:534)
25.06.2004 10:06:58 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor 
processChildren
SCHWERWIEGEND: Exception invoking periodic operation:
java.lang.NullPointerException
at org.apache.catalina.startup.HostConfig.deployDescriptors
(HostConfig.java:445)
at org.apache.catalina.startup.HostConfig.deployApps
(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1064)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:327)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardHost.backgroundProcess
(StandardHost.java:800)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1619)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1628)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run
(ContainerBase.java:1608)
at java.lang.Thread.run(Thread.java:534)
25.06.2004 10:06:58 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor 
processChildren
SCHWERWIEGEND: Exception invoking periodic operation:
java.lang.NullPointerException
at org.apache.catalina.startup.HostConfig.deployDescriptors
(HostConfig.java:445)
at org.apache.catalina.startup.HostConfig.deployApps
(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1064)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:327)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardHost.backgroundProcess
(StandardHost.java:800)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1619)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChild
ren(ContainerBase.java:1628)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run
(ContainerBase.java:1608)
at java.lang.Thread.run(Thread.java:534)
i

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

DO NOT REPLY [Bug 29799] New: - Do not satisfied servlet 2.4 SRV10.6 Listener Exceptions

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

Do not satisfied servlet 2.4 SRV10.6 Listener Exceptions

   Summary: Do not satisfied servlet 2.4 SRV10.6 Listener Exceptions
   Product: Tomcat 5
   Version: 5.0.19
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I throw an unhandled exception,which won't be handled by error page, form 
a session attribute listener,TC 5.0.19 response with a blank page with status 
200.
But according to Servlet 2.4 SRV.10.6, it should response with status 500.

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

DO NOT REPLY [Bug 29799] - Do not satisfied servlet 2.4 SRV10.6 Listener Exceptions

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

Do not satisfied servlet 2.4 SRV10.6 Listener Exceptions

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Normal



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 10:17 ---
Sometimes, the specification makes unreasonable requirements. Since we're in the
session context, we have no access to the servlet response object, and the only
way to implement this is to not catch exceptions which might occur when invoking
listeners.

I don't like this, so I'm voting -1 for fixing this bug right now, and I'm
asking specification related people to reexamine the behavior (which is likely
new in the 2.4 spec release) and suggest a way to implement this in a
satisfactory way.

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

cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat5w.exe tomcat5.exe

[mturk]

mturk   2004/06/25 03:28:15

  Modified:procrun/bin tomcat5w.exe tomcat5.exe
  Log:
  Latest binaries update.
  
  Revision  ChangesPath
  1.3   +250 -250  jakarta-tomcat-connectors/procrun/bin/tomcat5w.exe
  
<>
  
  
  1.3   +120 -126  jakarta-tomcat-connectors/procrun/bin/tomcat5.exe
  
<>
  
  

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

Wanting to be helpful, doc-wise

[Benson Margulies]

I did some rewriting on the JNDI doc at the instigation of Yoav; I
appended patches to the bugzilla, and then posted them here last night.
I'd be willing to write a JNI how-to, as well. Does someone in
particular coordinate doc changes and additions? I'd like to avoid
wasted effort by having some idea in advance of what's wanted.


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

DO NOT REPLY [Bug 29804] New: - JSP ClassLoader doesn't delegate to parent for permissions

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

JSP ClassLoader doesn't delegate to parent for permissions

   Summary: JSP ClassLoader doesn't delegate to parent for
permissions
   Product: Tomcat 4
   Version: 4.1.29
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm subclassing the WebappClassLoader to add permissions at runtime.  Because
the JSP class loader does not delegate to its parent for permissions before
adding its own, these permissions are not assigned to JSP-derived servlets.  The
problem comes from org.apache.jasper.compiler.JspRuntimeContext, which gets a
permissions collection from the Policy directly, instead of delegating to the
ParentClassLoader#getPermissions() method when assigning its
permissionCollection member's values in JspRuntimeContext#initSecurity().  This
problem also exists in the TC5.0.25 codebase.

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

DO NOT REPLY [Bug 29804] - JSP ClassLoader doesn't delegate to parent for permissions

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

JSP ClassLoader doesn't delegate to parent for permissions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 13:55 ---
I am not in favor of supporting this use case, sorry.
You should use the standard policy file and precompilation.

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

DO NOT REPLY [Bug 29804] - JSP ClassLoader doesn't delegate to parent for permissions

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

JSP ClassLoader doesn't delegate to parent for permissions





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 14:04 ---
I understand your hesitancy, but neither of these options will really work.  I'm
hosting many other developers' apps, and I cannot require precompilation.  The
policy file syntax is pretty restrictive, and using a custom classloader gives
me  a significantly better way to give context-based permissions in an
environment where the applications that are being developed and the context
paths they are being deployed to change frequently.

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

DO NOT REPLY [Bug 29804] - JSP ClassLoader doesn't delegate to parent for permissions

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

JSP ClassLoader doesn't delegate to parent for permissions





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 14:12 ---
I'm happy that you found a solution which fits your needs. I hate your solution
however, which takes a very heavy handed approach. So everyone's happy, but your
way of doing things will not be included in the official Tomcat.
The syntax of the policy file is very adequate and flexible enough.

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

DO NOT REPLY [Bug 29804] - JSP ClassLoader doesn't delegate to parent for permissions

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

JSP ClassLoader doesn't delegate to parent for permissions





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 14:29 ---
Well, thanks for hearing me out.  I'd like to think that it's my situation that
deserves the hate, and not my solution per se, but that's another issue.  I have
an academic interest in discussing this further, but this is obviously not the
forum for that.

regards-

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

DO NOT REPLY [Bug 29688] - HostConfig NullPointerException

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

HostConfig NullPointerException





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 16:47 ---
Hey,

I have made a patch to fix some NPE risks.

also this patch include the xml.mkdir fix.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29038

regards
peter

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

DO NOT REPLY [Bug 29688] - HostConfig NullPointerException

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

HostConfig NullPointerException





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 16:47 ---
Created an attachment (id=11947)
HostConfig

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

DO NOT REPLY [Bug 18778] - popBody not always called as expected resulting in unexpected output

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

popBody not always called as expected resulting in unexpected output

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
Product|Tomcat 5|Tomcat 4
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 16:55 ---
This bug is present in the latest Tomcat 4 release: Tomcat 4.1.30. I verified that it 
has been fixed in 
Tomcat 5.0.25. Can the Tomcat 5 bug fix be ported to the Tomcat 4.x workspace?

I'm reopening the bug and changing it to be a Tomcat 4 issue.

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

DO NOT REPLY [Bug 18778] - popBody not always called as expected resulting in unexpected output

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

popBody not always called as expected resulting in unexpected output





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 18:59 ---
Yes, we could backport the fix to Tomcat 4, but I'm not aware of any Tomcat 4
releases being planned, so what good would it do to you?

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[luehe]

luehe   2004/06/25 12:04:23

  Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  Reverted fix for Bugzilla 29763 ("The encoding of jsp document").
  
  We're supposed to throw an error only if there is an encoding declaration in the XML 
prolog that does not match the page encoding from the page directive or jsp-config. We 
must not throw any error if there is no XML prolog or encoding declaration in the 
prolog.
  
  The motivation for this is to make sure that JSP 1.2 pages with a page directive 
specifying a page encoding other than the default will continue to work in JSP 2.0 in 
most cases.
  
  The code is currently going through lots of pains to determine whether the encoding 
was specified in the XML prolog, or autodetected, to decide whether an error should be 
thrown.
  
  Revision  ChangesPath
  1.148 +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.147
  retrieving revision 1.148
  diff -u -r1.147 -r1.148
  --- messages.properties   24 Jun 2004 19:05:12 -  1.147
  +++ messages.properties   25 Jun 2004 19:04:23 -  1.148
  @@ -327,7 +327,7 @@
   jsp.error.tagdirective.badbodycontent=Invalid body-content ({0}) in tag directive
   jsp.error.simpletag.badbodycontent=The TLD for the class {0} specifies an invalid 
body-content (JSP) for a SimpleTag.
   jsp.error.config_pagedir_encoding_mismatch=Page-encoding specified in 
jsp-property-group ({0}) is different from that specified in page directive ({1})
  -jsp.error.prolog_pagedir_encoding_mismatch=Page-encoding derived from XML prolog 
({0}) is different from that specified in page directive ({1})
  +jsp.error.prolog_pagedir_encoding_mismatch=Page-encoding specified in XML prolog 
({0}) is different from that specified in page directive ({1})
   jsp.error.prolog_config_encoding_mismatch=Page-encoding specified in XML prolog 
({0}) is different from that specified in jsp-property-group ({1})
   jsp.error.attribute.custom.non_rt_with_expr=According to TLD or attribute directive 
in tag file, attribute {0} does not accept any expressions
   jsp.error.attribute.standard.non_rt_with_expr=The {0} attribute of the {1} standard 
action does not accept any expressions
  
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Validator.java

[luehe]

luehe   2004/06/25 12:05:05

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
  Log:
  Reverted fix for Bugzilla 29763 ("The encoding of jsp document").
  
  We're supposed to throw an error only if there is an encoding declaration in the XML 
prolog that does not match the page encoding from the page directive or jsp-config. We 
must not throw any error if there is no XML prolog or encoding declaration in the 
prolog.
  
  The motivation for this is to make sure that JSP 1.2 pages with a page directive 
specifying a page encoding other than the default will continue to work in JSP 2.0 in 
most cases.
  
  The code is currently going through lots of pains to determine whether the encoding 
was specified in the XML prolog, or autodetected, to decide whether an error should be 
thrown.
  
  Revision  ChangesPath
  1.119 +4 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.118
  retrieving revision 1.119
  diff -u -r1.118 -r1.119
  --- Validator.java24 Jun 2004 19:04:41 -  1.118
  +++ Validator.java25 Jun 2004 19:05:05 -  1.119
  @@ -285,10 +285,12 @@
   
   /*
* Compare the 'pageEncoding' attribute of the page directive with
  - * the encoding specified in the XML prolog (only for XML syntax!).
  + * the encoding specified in the XML prolog (only for XML syntax,
  + * and only if JSP document contains XML prolog with encoding
  + * declaration).
* Treat "UTF-16", "UTF-16BE", and "UTF-16LE" as identical.
*/
  - if (root.isXmlSyntax()) {
  + if (root.isXmlSyntax() && root.isEncodingSpecifiedInProlog()) {
String pageEnc = root.getPageEncoding();
   if (!pageDirEnc.equals(pageEnc) 
   && (!pageDirEnc.startsWith("UTF-16")
  
  
  

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

DO NOT REPLY [Bug 29763] - The encoding of jsp document

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

The encoding of jsp document

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 19:08 ---
Reverted patch.

We're supposed to throw an error only if there is an encoding declaration in the
XML prolog that does not match the page encoding from the page directive or
jsp-config. We must not throw any error if there is no XML prolog or encoding
declaration in the prolog.

The motivation for this is to make sure that JSP 1.2 pages with a page directive
specifying a page encoding other than the default will continue to work in JSP
2.0 in most cases.

The code is currently going through lots of pains to determine whether the
encoding was specified in the XML prolog, or autodetected, to decide whether an
error should be thrown.

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

DO NOT REPLY [Bug 28839] - The Coyote connector publishes empty URIs to catalina

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

The Coyote connector publishes empty URIs to catalina





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 19:26 ---
Thanks, disabling useURIValidationHack works, I wish I knew why...

What does this option do?  I don't see it documented anywhere, does this mean
that a documentation bugzilla should be opened?

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

DO NOT REPLY [Bug 28839] - The Coyote connector publishes empty URIs to catalina

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

The Coyote connector publishes empty URIs to catalina

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 19:33 ---
So it appears that this option has security ramifications.  I'm posting my
web.xml file (from an arbitrary service, they all fail so one is as good as
another) and reopening this bugz.  I want to avoid tramping on security fixes if
possible.

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

DO NOT REPLY [Bug 28839] - The Coyote connector publishes empty URIs to catalina

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

The Coyote connector publishes empty URIs to catalina

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID

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

DO NOT REPLY [Bug 28839] - The Coyote connector publishes empty URIs to catalina

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

The Coyote connector publishes empty URIs to catalina





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 19:35 ---
Created an attachment (id=11952)
Servlet web.xml file

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

DO NOT REPLY [Bug 29813] New: - POST requests get redirected

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

POST requests get redirected

   Summary: POST requests get redirected
   Product: Tomcat 5
   Version: 5.0.25
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat is redirecting POST requests to the default context if the requested URI
does not end in a slash.
I have a jsp that creates a form. It uses the POST method to submit the form. I
specify the context path in the action attribute of the form. If the context
path ends in a slash (mytest/) or a question mark followed by arguments
(mytest?user=test) then things work fine. If I have no slash at the end of the
context (mytest), then tomcat redirects to the default context. 
This failure does not occur in Tomcat 4.1.24

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

DO NOT REPLY [Bug 29813] - POST requests get redirected

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

POST requests get redirected

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 20:02 ---
GET and POST should be handled with redirects. This is normal, and the client
should automatically reproduce the request to the new URL. If you don't like
that, you can hack the code to your liking, but this is a 100% valid behavior.

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

DO NOT REPLY [Bug 29813] - POST requests get redirected

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

POST requests get redirected





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 20:19 ---
It is also possible that you may have better luck with 5.0.27, which is 
slightly friendlier to broken clients.

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

DO NOT REPLY [Bug 25238] - codebase in catalina.policy doesn't work

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

codebase in catalina.policy doesn't work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows 9x  |Windows XP



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 22:09 ---
I can reproduce this under WinXP on TC4 and TC5.

I have a simple test application that is deployed in exploded form. A JSP 
contains a single call to <%=test.Bug25238.getUserHome() %>

The class is located at ${catalina.home}/webapps/Bugfix/WEB-
INF/classes/test/Bug25238.class
(as expected)

This enables the JSP to work:
grant codeBase "file:${catalina.home}/webapps/Bugfix/-" {
permission java.util.PropertyPermission "user.home", "read";
};

This one doesn't:
grant codeBase "file:${catalina.home}/webapps/Bugfix/WEB-INF/classes/-" {
permission java.util.PropertyPermission "user.home", "read";
};

I have tried various combinations and it seems that any codeBase below 
the /webapps/Bugfix/ gets ignored.

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

DO NOT REPLY [Bug 18383] - context path is set to "/" instead of ""

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

context path is set to "/" instead of ""

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 22:30 ---
*** Bug 25244 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 25244] - Context with path="" works, path="/" doesn't

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

Context with path="" works, path="/" doesn't

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 22:30 ---


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

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

JavaOne fun at the XYZ Bar Monday June 28 at 8:30 PM

[Amy Roh]

Hi Tomcat-Dev folks,

As most of you probably know, the JavaOne conference will be held in San
Francisco at the Moscone Center next week.

The Servlet spec expert group is getting together to talk about the good old
days and the good days to come.  I am not sure who on this list will be
attending the conference but you are all welcome.  If you are at the
conference or in the area please stop by at 8:30 PM - 10:00 PM Monday June
28th.

http://www.worldsbestbars.com/city/SanFrancisco/XYZBar.asp

Hope to see you there.

Cheers!
Amy


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

DO NOT REPLY [Bug 25526] - tomcat parses the query string parameters as iso-8859-1

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

tomcat parses the query string parameters as iso-8859-1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 22:55 ---
The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults to 
ISO-8859-1.
The parameters class (o.a.t.u.http.Parameters) has a QueryStringEncoding field 
which defaults to the URIEncoding. It must be set before the parameters are 
parsed to have an effect.

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

DO NOT REPLY [Bug 25238] - codebase in catalina.policy doesn't work

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

codebase in catalina.policy doesn't work





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 23:12 ---
I think you need to check the codeSource URLs that are used in the classloader.

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

DO NOT REPLY [Bug 25537] - BodyContentImpl reAllocBuff method inefficient

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

BodyContentImpl reAllocBuff method inefficient

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 23:17 ---
The 4.1.27 implementation (Jasper 2, not Jasper) does not automatically grow 
the buffer by DEFAULT_TAG_BUFFER_SIZE.

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

DO NOT REPLY [Bug 18778] - popBody not always called as expected resulting in unexpected output

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

popBody not always called as expected resulting in unexpected output





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 23:38 ---
If there is a Tomcat 4 bug fix release post 4.1.30 then I would like to see this bug 
ported. A tag 
handlers ability to process exceptions in a page is severly limited without this fix.

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

DO NOT REPLY [Bug 25238] - codebase in catalina.policy doesn't work

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

codebase in catalina.policy doesn't work





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 23:45 ---
Have you precompiled test.jsp?  Otherwise it's the one without permission to 
read user.home.

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

DO NOT REPLY [Bug 18778] - popBody not always called as expected resulting in unexpected output

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

popBody not always called as expected resulting in unexpected output





--- Additional Comments From [EMAIL PROTECTED]  2004-06-25 23:52 ---
Urm, last I checked, you were still a Tomcat committer, so.

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

Re: JavaOne fun at the XYZ Bar Monday June 28 at 8:30 PM

[Remy Maucherat]

Amy Roh wrote:
Hi Tomcat-Dev folks,
about the good old days
Oh, you mean Sun is picking up the tab ? ;)
I am not sure who on this list will be attending the conference
but you are all welcome.
Still no JavaOne for me this year.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Tool.java ClassLoaderFactory.java

[remm]

remm2004/06/25 16:56:25

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
   catalina/src/share/org/apache/catalina/mbeans
GlobalResourcesLifecycleListener.java
ServerLifecycleListener.java
   catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
   catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
   catalina/src/share/org/apache/catalina/connector
OutputBuffer.java CoyoteAdapter.java
   catalina/src/share/org/apache/catalina/startup Tool.java
ClassLoaderFactory.java
  Log:
  - Remove more log methods.
  
  Revision  ChangesPath
  1.29  +1 -24 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- ManagerBase.java  23 Jun 2004 16:59:42 -  1.28
  +++ ManagerBase.java  25 Jun 2004 23:56:25 -  1.29
  @@ -849,29 +849,6 @@
   //  Package Methods
   
   
  -/**
  - * Log a message on the Logger associated with our Container (if any).
  - *
  - * @param message Message to be logged
  - * @deprecated
  - */
  -protected void log(String message) {
  -log.info( message );
  -}
  -
  -
  -/**
  - * Log a message on the Logger associated with our Container (if any).
  - *
  - * @param message Message to be logged
  - * @param throwable Associated exception
  - * @deprecated
  - */
  -protected void log(String message, Throwable throwable) {
  -log.info(message,throwable);
  -}
  -
  -
   public void setSessionCounter(int sessionCounter) {
   this.sessionCounter = sessionCounter;
   }
  
  
  
  1.7   +1 -22 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java
  
  Index: GlobalResourcesLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- GlobalResourcesLifecycleListener.java 23 Jun 2004 16:59:42 -  1.6
  +++ GlobalResourcesLifecycleListener.java 25 Jun 2004 23:56:25 -  1.7
  @@ -233,25 +233,4 @@
   
   }
   
  -/**
  - * Log a message.
  - *
  - * @param message The message to be logged
  - */
  -protected void log(String message) {
  -log.info(message);
  -}
  -
  -
  -/**
  - * Log a message and associated exception.
  - *
  - * @param message The message to be logged
  - * @param throwable The exception to be logged
  - */
  -protected void log(String message, Throwable throwable) {
  -log.info(message, throwable);
  -}
  -
  -
   }
  
  
  
  1.17  +1 -29 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
  
  Index: ServerLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- ServerLifecycleListener.java  23 Jun 2004 16:59:42 -  1.16
  +++ ServerLifecycleListener.java  25 Jun 2004 23:56:25 -  1.17
  @@ -69,7 +69,6 @@
   private static Log log = LogFactory.getLog(ServerLifecycleListener.class);
   
   
  -
   // - Properties
   
   
  @@ -1099,33 +1098,6 @@
   if (service instanceof StandardService) {
   ((StandardService) service).removePropertyChangeListener(this);
   }
  -
  -}
  -
  -
  -/**
  - * Log a message.
  - *
  - * @param message The message to be logged
  - */
  -protected void log(String message) {
  -
  -System.out.print("ServerLifecycleListener: ");
  -System.out.println(message);
  -
  -}
  -
  -
  -/**
  - * Log a message and associated exception.
  - *
  - * @param message The message to be logged
  - * @param throwable The exception to be logged
  - */
  -protected void log(String message, Throwable throwable) {
  -
  -log(message);
  -throwable.printStackTrace(System.ou

Re: Any synchronization issues with SMP?

[Martin Schulz]

it appears that the JVM slows everything down to a crawl,
including the code path which should lead to another accept being
called., for up to 8 minutes!!!
Furthermore, the mpstat has the nice porperty that CPU usage adds
up to exactly 100%, i.e. a single CPU is used... no more, no less.
This corresponds to 12% or 13% CPU utilization shown in prstat
based on 8 CPUs.  My interpretation is that the JVM is effectively
preventing parallel execution (which otherwise appears to work fine).
Nearly all threads either wait, read from a Socket, or zip/unzip data.
I'm not sure what all that means, but Tomcat appears to be a victim
of it.  I'll experiment some more.  Main difference with the systems
Rainer mentioned is the JVM (1.4.2_04) and the CPU (Sparc III 1.2GHz).
If any of this rings a bell, drop me a note.  I'll be happy to share data
as appropriate.
I'll repost to the list only if I learn anything which impacts Tomcat 
directly
(other than that the code path to hand of the socket accept responsibility
is not suitable for _very_ high hit rates, which does not worry me too
much at this point).

Cheers!
   Martin
Martin Schulz wrote:
Rainer,
Thanks for the tips.  I am about to take timing stats
internally in the ThreadPool and the Tcp workers.
Also, the described symptoms do not disappear, but seem to be of much
shorter duration when only 4 CPUs are used for the application.
I'll summarize what I find.
Martin
Rainer Jung wrote:
Hi,
we know one application running on 9 systems with 4 US II CPUs each
under Solaris 9. Peak request rates at 20 requests/second per system.
Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours!
You should send a signal "QUIT" to the jvm process during the
unresponsiveness time. This is a general JVM mechanism (at least for sun
JVMs). The signal writes a stack trace for each thread on STDOUT (so you
should also start tomcat with redirection of STDOUT the output to some
file). Beware: older JVM in rare cases stopped working after getting
this signal (not expected with 1.3.1_09).
In this stack dump you should be able to figure out, in which methods
most of your threads stay and what the status is.
Is there native code included (via JNI)? Any synchronization done in the
application itself? Are you using Tomcat clustering? Which JVM?
Sincerely
Rainer Jung


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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2004/06/25 19:22:27

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
  Log:
  Fixed 18778: popBody not always called as expected resulting in unexpected output
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.35.2.24 +11 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.35.2.23
  retrieving revision 1.35.2.24
  diff -u -r1.35.2.23 -r1.35.2.24
  --- Generator.java27 Mar 2004 01:04:39 -  1.35.2.23
  +++ Generator.java26 Jun 2004 02:22:27 -  1.35.2.24
  @@ -1157,7 +1157,7 @@
   //   out.println("javax.servlet.jsp.PageContext pageContext, JspxState 
_jspxState)");
out.print("javax.servlet.jsp.PageContext pageContext");
if (pushBodyCountVar != null) {
  - out.print(", int ");
  + out.print(", int[] ");
out.print(pushBodyCountVar);
}
out.println(")");
  @@ -1359,9 +1359,9 @@
generateSetters(n, tagHandlerVar, handlerInfo);

   if (n.implementsTryCatchFinally()) {
  - out.printin("int ");
  + out.printin("int[] ");
out.print(tagPushBodyCountVar);
  - out.println(" = 0;");
  + out.println(" = new int[] { 0 };");
   out.printil("try {");
   out.pushIndent();
   }
  @@ -1396,10 +1396,10 @@
out.printil("javax.servlet.jsp.tagext.BodyContent _bc = 
pageContext.pushBody();");
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
  - out.println("++;");
  + out.println("[0]++;");
} else if (pushBodyCountVar != null) {
out.printin(pushBodyCountVar);
  - out.println("++;");
  + out.println("[0]++;");
}
out.printil("out = _bc;");
   
  @@ -1464,10 +1464,10 @@
   out.printil("out = pageContext.popBody();");
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
  - out.println("--;");
  + out.println("[0]--;");
} else if (pushBodyCountVar != null) {
out.printin(pushBodyCountVar);
  - out.println("--;");
  + out.println("[0]--;");
}
out.popIndent();
}
  @@ -1494,7 +1494,7 @@
   
out.printin("while (");
out.print(tagPushBodyCountVar);
  - out.println("-- > 0)");
  + out.println("[0]-- > 0)");
out.pushIndent();
out.printil("out = pageContext.popBody();");
out.popIndent();
  
  
  

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

DO NOT REPLY [Bug 18778] - popBody not always called as expected resulting in unexpected output

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

popBody not always called as expected resulting in unexpected output

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 25526] - tomcat parses the query string parameters as iso-8859-1

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

tomcat parses the query string parameters as iso-8859-1





--- Additional Comments From [EMAIL PROTECTED]  2004-06-26 02:31 ---
So - if I do request.setCharacterEncoding() before I get the query parameters, then 
this will work?

This was closed as fixed.  Does this mean that this was a bug, and is now fixed?  From 
what you 
mention, the workaround is Tomcat specific, whereas this seems to be a bug with Tomcat 
not dealing 
with the spec properly?

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

RE: Any synchronization issues with SMP?

[Filip Hanik \(lists\)]

The only time I have seen something like this happen is when we had a memory
leak, an interesting one.
We were running on solaris, our CPU, sometimes one, sometimes both would go
up to 100% and stay there. sometimes for as much as 10 minutes and then go
back to normal again.

We ran thread analyzer (a neat util on solaris) to measure which thread was
using a lot of cpu, and found out it was a VM thread.

In our scenario, we had a thread being an inner class of an object, and the
thread (inner class) referenced the parent and the parent referenced the
thread. Even though nothing referenced any of the two objects, it would not
be garbage collected, I suspect it had to do with the fact that the inner
class was a thread object.

Another guess we had was that the VM thread was freakin out cause it tried
to resolve garbage collection references and kept looking our weird
dependency.

Once we resolved the memory leak (removed any references from the parent
object to the thread and vice versa) our CPU usage never behaved weirdly
again.

hope this helps
Filip


-Original Message-
From: Martin Schulz [mailto:[EMAIL PROTECTED]
Sent: Friday, June 25, 2004 8:24 PM
To: Tomcat Developers List
Subject: Re: Any synchronization issues with SMP?


it appears that the JVM slows everything down to a crawl,
including the code path which should lead to another accept being
called., for up to 8 minutes!!!

Furthermore, the mpstat has the nice porperty that CPU usage adds
up to exactly 100%, i.e. a single CPU is used... no more, no less.
This corresponds to 12% or 13% CPU utilization shown in prstat
based on 8 CPUs.  My interpretation is that the JVM is effectively
preventing parallel execution (which otherwise appears to work fine).

Nearly all threads either wait, read from a Socket, or zip/unzip data.

I'm not sure what all that means, but Tomcat appears to be a victim
of it.  I'll experiment some more.  Main difference with the systems
Rainer mentioned is the JVM (1.4.2_04) and the CPU (Sparc III 1.2GHz).

If any of this rings a bell, drop me a note.  I'll be happy to share data
as appropriate.

I'll repost to the list only if I learn anything which impacts Tomcat
directly
(other than that the code path to hand of the socket accept responsibility
is not suitable for _very_ high hit rates, which does not worry me too
much at this point).

Cheers!
Martin

Martin Schulz wrote:

> Rainer,
>
> Thanks for the tips.  I am about to take timing stats
> internally in the ThreadPool and the Tcp workers.
> Also, the described symptoms do not disappear, but seem to be of much
> shorter duration when only 4 CPUs are used for the application.
> I'll summarize what I find.
>
> Martin
>
> Rainer Jung wrote:
>
>> Hi,
>>
>> we know one application running on 9 systems with 4 US II CPUs each
>> under Solaris 9. Peak request rates at 20 requests/second per system.
>> Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours!
>>
>> You should send a signal "QUIT" to the jvm process during the
>> unresponsiveness time. This is a general JVM mechanism (at least for sun
>> JVMs). The signal writes a stack trace for each thread on STDOUT (so you
>> should also start tomcat with redirection of STDOUT the output to some
>> file). Beware: older JVM in rare cases stopped working after getting
>> this signal (not expected with 1.3.1_09).
>>
>> In this stack dump you should be able to figure out, in which methods
>> most of your threads stay and what the status is.
>>
>> Is there native code included (via JNI)? Any synchronization done in the
>> application itself? Are you using Tomcat clustering? Which JVM?
>>
>> Sincerely
>>
>> Rainer Jung
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004


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