Re: [VOTE] Tomcat v5.5.14 Stability

[Filip Hanik - Dev Lists]

out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0

Filip

Peter Rossbach wrote:


Hey!

I have changed the cluster message header format long time ago 5.5.10. 
In some situations TCP Stack split the message, then the
receiver byte array  interpretation start to early. Arrggh, after 
first exception the receiver socket is hanging and replication 
transfer stops.

Wait a little bit and tomcat crash with OutOfMemory or hanging.

Peter

Remy Maucherat schrieb:


Yoav Shapira wrote:


Hi,
Tomcat v5.5.14-beta has been out for about a week now. If you have
tested it, please vote on its stability below using our usual
guidelines.  (And if you haven't tested it yet, please give it a whack
;))

Tomcat 5.5.14 is:
[ ] Stable
[ ] Beta - At least one significant issue preventing stability (please
elaborate)
[ ] Alpha - Multiple significant issues (please elaborate)

As a reminder, only committer votes are binding.  Everyone's opinion
is welcome, of course.




There's that clustering bug that Peter said was critical :( So how 
critical is it ?



Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside 
XByteBuffer.java.

Very production critical bug, arrgh!


Rémy

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









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




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

Re: [VOTE] Tomcat v5.5.14 Stability

[Peter Rossbach]

Hey Filip,

it was a new one and is only inside >5.5.10 source. After I have change 
the message header

format the bug is comes in. Now it is fixed. Every help is welcome.

Peter

Filip Hanik - Dev Lists schrieb:


out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0

Filip

Peter Rossbach wrote:


Hey!

I have changed the cluster message header format long time ago 
5.5.10. In some situations TCP Stack split the message, then the
receiver byte array  interpretation start to early. Arrggh, after 
first exception the receiver socket is hanging and replication 
transfer stops.

Wait a little bit and tomcat crash with OutOfMemory or hanging.

Peter

Remy Maucherat schrieb:


Yoav Shapira wrote:


Hi,
Tomcat v5.5.14-beta has been out for about a week now. If you have
tested it, please vote on its stability below using our usual
guidelines.  (And if you haven't tested it yet, please give it a whack
;))

Tomcat 5.5.14 is:
[ ] Stable
[ ] Beta - At least one significant issue preventing stability (please
elaborate)
[ ] Alpha - Multiple significant issues (please elaborate)

As a reminder, only committer votes are binding.  Everyone's opinion
is welcome, of course.





There's that clustering bug that Peter said was critical :( So how 
critical is it ?



Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside 
XByteBuffer.java.

Very production critical bug, arrgh!


Rémy

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









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




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

DO NOT REPLY [Bug 37918] New: - EL cannot find valid getter from object when using some inheritance

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

   Summary: EL cannot find valid getter from object when using some
inheritance
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Is just have found an strange error. I don't know how is the EL built inside
Tomcat, but here it is...

This is the stacktrace:
javax.servlet.jsp.el.ELException: Unable to find a value for "porOrden" in
object of class "net.sargue.escuder.webapp.persistencia.CategoriasServiciosDB"
using operator "."
at org.apache.commons.el.Logger.logError(Logger.java:481)
at org.apache.commons.el.Logger.logError(Logger.java:498)
at org.apache.commons.el.Logger.logError(Logger.java:611)
at org.apache.commons.el.ArraySuffix.evaluate(ArraySuffix.java:340)
at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
at
org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263)
at
org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:922)
at
org.apache.jsp.ges.stats.resumenServicios_jsp._jspx_meth_c_forEach_3(org.apache.jsp.ges.stats.resumenServicios_jsp:565)
at
org.apache.jsp.ges.stats.resumenServicios_jsp._jspService(org.apache.jsp.ges.stats.resumenServicios_jsp:170)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at 
net.sargue.escuder.webapp.controladores.BaseServlet.forward(BaseServlet.java:61)
at 
net.sargue.escuder.webapp.controladores.KStats.doGetAction(KStats.java:78)
at 
net.sargue.escuder.webapp.controladores.BaseServlet.doGet(BaseServlet.java:22)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
net.sargue.escuder.webapp.controladores.KLogin.doFilter(KLogin.java:38)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.a

Re: [VOTE] Tomcat v5.5.14 Stability

[Filip Hanik - Dev Lists]

interesting, why did the protocol header need to change? that is so old 
proven code. didn't know there was anything wrong with it.

Filip


Peter Rossbach wrote:


Hey Filip,

it was a new one and is only inside >5.5.10 source. After I have 
change the message header

format the bug is comes in. Now it is fixed. Every help is welcome.

Peter

Filip Hanik - Dev Lists schrieb:


out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0

Filip

Peter Rossbach wrote:


Hey!

I have changed the cluster message header format long time ago 
5.5.10. In some situations TCP Stack split the message, then the
receiver byte array  interpretation start to early. Arrggh, after 
first exception the receiver socket is hanging and replication 
transfer stops.

Wait a little bit and tomcat crash with OutOfMemory or hanging.

Peter

Remy Maucherat schrieb:


Yoav Shapira wrote:


Hi,
Tomcat v5.5.14-beta has been out for about a week now. If you have
tested it, please vote on its stability below using our usual
guidelines.  (And if you haven't tested it yet, please give it a 
whack

;))

Tomcat 5.5.14 is:
[ ] Stable
[ ] Beta - At least one significant issue preventing stability 
(please

elaborate)
[ ] Alpha - Multiple significant issues (please elaborate)

As a reminder, only committer votes are binding.  Everyone's opinion
is welcome, of course.






There's that clustering bug that Peter said was critical :( So how 
critical is it ?



Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside 
XByteBuffer.java.

Very production critical bug, arrgh!


Rémy

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









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




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




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

Re: [VOTE] Tomcat v5.5.14 Stability

[Peter Rossbach]

Compression is optional for cluster messages. Very big message can be 
set a flag that need compression.

This flag is the header extension.
Peter

Filip Hanik - Dev Lists schrieb:

interesting, why did the protocol header need to change? that is so 
old proven code. didn't know there was anything wrong with it.

Filip


Peter Rossbach wrote:


Hey Filip,

it was a new one and is only inside >5.5.10 source. After I have 
change the message header

format the bug is comes in. Now it is fixed. Every help is welcome.

Peter

Filip Hanik - Dev Lists schrieb:


out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0

Filip

Peter Rossbach wrote:


Hey!

I have changed the cluster message header format long time ago 
5.5.10. In some situations TCP Stack split the message, then the
receiver byte array  interpretation start to early. Arrggh, after 
first exception the receiver socket is hanging and replication 
transfer stops.

Wait a little bit and tomcat crash with OutOfMemory or hanging.

Peter

Remy Maucherat schrieb:


Yoav Shapira wrote:


Hi,
Tomcat v5.5.14-beta has been out for about a week now. If you have
tested it, please vote on its stability below using our usual
guidelines.  (And if you haven't tested it yet, please give it a 
whack

;))

Tomcat 5.5.14 is:
[ ] Stable
[ ] Beta - At least one significant issue preventing stability 
(please

elaborate)
[ ] Alpha - Multiple significant issues (please elaborate)

As a reminder, only committer votes are binding.  Everyone's opinion
is welcome, of course.







There's that clustering bug that Peter said was critical :( So how 
critical is it ?



Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside 
XByteBuffer.java.

Very production critical bug, arrgh!


Rémy

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









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




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




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

Improving memory efficiency

[Tino Schwarze]

Hi there,

while hunting down a memory leak (it turned out that some servlets
didn't release PageContexts after use) I came across some places in
tomcat which are a bit memory inefficent.

(I'm talking about Tomcat 5.5 SVN as of tuesday or yesterday.)

The root cause (but not the problem) is that PageContexts are pooled in
JspFactoryImpl. The first interesting spot is the BodyContentImpl[] outs
member of PageContextImpl. It will only grow over time and it will never
release the BodyContentImpls stored in there. As PageContexts are
pooled, a single PageContext instance gets used by a lot of different
JSPs (possibly all JSPs present in the app).

The next interesting spot is the char[] cb member of BodyContentImpl it
will also only grow over time and never release the space occupied by
the buffer.

Let's consider a JSP with a single BodyTag which will buffer a
significant amount of data (say 1 MB). Over time, all
PageContextImpls.out[0].cb-s will grow to this size. The
JspFactoryImpl's PageContext pool contains up to 100 PageContexts, so I
may end up with 100 MB of memory which is basically unused.

I patched Tomcat to re-initialize PageContextImpl.outs on release().
This should increase memory efficiency significantly.

Second, I re-initialized BodyContentImpl.cb[] on clear() - this seems
superfluous but I found tags in the pools which still held
BodyContentImpls as bodyContent therefore possibly locking lots of
memory. Third, I let JspWriterImpl null it's cb on recycle() since I
also found some of these lingering around and still holding parts of the
output. The last two steps might be unneccessary if we could prevent
that tags in the pools still hold BodyContents (as far as
BodyTagSupport.bodyContent is involved).

What do you think about this issue?

Bye, Tino.

PS: Proposed patch attached.

Index: src/share/org/apache/jasper/runtime/PageContextImpl.java
===
--- src/share/org/apache/jasper/runtime/PageContextImpl.java(revision 
356603)
+++ src/share/org/apache/jasper/runtime/PageContextImpl.java(working copy)
@@ -203,7 +203,8 @@
autoFlush = true;
request = null;
response = null;
-depth = -1;
+outs = new BodyContentImpl[0];
+depth = -1;
baseOut.recycle();
session = null;
 
@@ -706,9 +707,7 @@
 depth++;
 if (depth >= outs.length) {
 BodyContentImpl[] newOuts = new BodyContentImpl[depth + 1];
-for (int i=0; i-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tomcat v5.5.14 Stability

[Filip Hanik - Dev Lists]

got it, I would have placed that in the body, with the payload info 
instead of altering the protocol.

but I am glad you got it fixed.
I have been too busy to work on the tomcat project this year, and it 
sounds like it will be a little while before 5.5 reaches the stability 
for us to move to it. I hope to have more time next year.


Filip


Peter Rossbach wrote:

Compression is optional for cluster messages. Very big message can be 
set a flag that need compression.

This flag is the header extension.
Peter

Filip Hanik - Dev Lists schrieb:

interesting, why did the protocol header need to change? that is so 
old proven code. didn't know there was anything wrong with it.

Filip


Peter Rossbach wrote:


Hey Filip,

it was a new one and is only inside >5.5.10 source. After I have 
change the message header

format the bug is comes in. Now it is fixed. Every help is welcome.

Peter

Filip Hanik - Dev Lists schrieb:


out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0

Filip

Peter Rossbach wrote:


Hey!

I have changed the cluster message header format long time ago 
5.5.10. In some situations TCP Stack split the message, then the
receiver byte array  interpretation start to early. Arrggh, after 
first exception the receiver socket is hanging and replication 
transfer stops.

Wait a little bit and tomcat crash with OutOfMemory or hanging.

Peter

Remy Maucherat schrieb:


Yoav Shapira wrote:


Hi,
Tomcat v5.5.14-beta has been out for about a week now. If you have
tested it, please vote on its stability below using our usual
guidelines.  (And if you haven't tested it yet, please give it a 
whack

;))

Tomcat 5.5.14 is:
[ ] Stable
[ ] Beta - At least one significant issue preventing stability 
(please

elaborate)
[ ] Alpha - Multiple significant issues (please elaborate)

As a reminder, only committer votes are binding.  Everyone's 
opinion

is welcome, of course.








There's that clustering bug that Peter said was critical :( So 
how critical is it ?



Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside 
XByteBuffer.java.

Very production critical bug, arrgh!


Rémy

- 


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









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




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




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




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

DO NOT REPLY [Bug 37929] New: - invalidated session causes pageContext methods to fail

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

   Summary: invalidated session causes pageContext methods to fail
   Product: Tomcat 5
   Version: 5.0.25
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


javax.servlet.http.HttpSession methods such as getAttribute(),
getValue(), getAttributeNames(), getValueNames(), etc, throw an
IllegalStateException if called on a session that has been
invalidated.

So, with the following code in a JSP page:

<% 
   session.invalidate(); 
   Object obj = pageContext.findAttribute("foo");
%>

An IllegalStateException is thrown because pageContext.findAttribute()
eventually calls session.getAttribute() on a session that has been
invalidated.

The session that has been invalidated should simply be ignored when a
method needs to process the various scopes (page, request, session,
application).

This impacts the following methods in PageContextImpl:

   public int getAttributesScope(final String name)
  which calls -> private int doGetAttributeScope(String name);
   public Object findAttribute(final String name)
  which calls -> private Object doFindAttribute(String name);
   public void removeAttribute(final String name)
  which calls -> private void doRemoveAttribute(String name);

The fix is to catch IllegalStateException and ignore it when processing
the attribute in session scope. The code then simply follows through to 
process application scope.

No need to worry about setAttribute() because it is always invoked
on a specific scope, and the spec already states
that java.lang.IllegalStateException must be thrown when called 
on an invalidated session.

  pageContext.setAttribute("foo", "value of foo", PageContext.SESSION_SCOPE);

  java.lang.IllegalStateException - if the scope is PageContext.SESSION_SCOPE 
  but the page that was requested does not participate in a session or 
  the session has been invalidated.

---

At the same time, a fix should be done to method "doRemoveAttribute(String
name)" where a try/catch block for Exception appears unnecessary.

private void doRemoveAttribute(String name){
try {
removeAttribute(name, PAGE_SCOPE);
removeAttribute(name, REQUEST_SCOPE);
if( session != null ) {
try {
removeAttribute(name, SESSION_SCOPE);
} catch (IllegalStateException ex) {
// Session has been invalidated.
// Ignore and fall through to application scope.
}
}
removeAttribute(name, APPLICATION_SCOPE);
} catch (Exception ex) {
// we remove as much as we can, and
// simply ignore possible exceptions
}
}

Here is a full analysis:

Starting with 'removeAttribute(final String name)'
  - we check for null and throw NPE if necessary

  - we call doRemoveAttribute(name)
  
doRemoveAttribute(name)
  - we call removeAttribute(name, scope) for each scope

removeAttribute(final String name, final int scope)
  - this calls doRemoveAttribute(name, scope)

doRemoveAttribute(name, scope)
  - page scope: attributes.remove -> won't throw an Exception
  - request scope: request.removeAttribute -> no documented Exception thrown
  - session scope: throws IllegalStateException if session is null
  - app scope: context.removeAttribute -> no documented Exception thrown

A null value for name is already checked in removeAttribute(final String name)
and we throw NPE. So this situation (removing an attr from page or request
scope throwing an NPE) won't happen.

In doRemoveAttribute(name), we already check on session != null
before calling removeAttribute(name, SESSION_SCOPE). So there
normally is no IllegalStateException thrown (except for the invalidated
case).

When removing an attribute from application (i.e., ServletContext)
scope, any registered listeners will be notified, but the code that
does that (see
appserv-webtier/src/java/org/apache/catalina/core/ApplicationContext.
removeAttribute()) already catches any Throwable that a listener
may throw.

The try/catch block is therefore unnecessary.
Moreover, if any of the removal actions from the different scopes could
have thrown an exception, each of them would have needed to be wrapped
inside their own try/catch, so as to ensure that an exception in one
scope does not cause any of the subsequent removals to be bypassed.

doRemoveAttribute(Stri

DO NOT REPLY [Bug 37929] - invalidated session causes pageContext methods to fail

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 02:00 ---
*** Bug 37699 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 30489] - removeAttribute: Session already invalidated

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 02:03 ---
Here is a trace from the jboss deployer which shows why this occurs. This is the
equivalent of the tomcat manager undeploying a web app. From within the session
writeObject, the non-Serializable attributes are being removed. This in turn
causes an invalidation the session as when the removeAttribute calls isValid(),
which in turn calls expire:

expire():650, org.apache.catalina.session.StandardSession, StandardSession.java
isValid():569, org.apache.catalina.session.StandardSession, StandardSession.java
removeAttribute():1146, org.apache.catalina.session.StandardSession,
StandardSession.java
removeAttribute():1122, org.apache.catalina.session.StandardSession,
StandardSession.java
writeObject():1405, org.apache.catalina.session.StandardSession,
StandardSession.java
writeObjectData():902, org.apache.catalina.session.StandardSession,
StandardSession.java
doUnload():539, org.apache.catalina.session.StandardManager, 
StandardManager.java
unload():485, org.apache.catalina.session.StandardManager, StandardManager.java
stop():687, org.apache.catalina.session.StandardManager, StandardManager.java
stop():4511, org.apache.catalina.core.StandardContext, StandardContext.java
destroy():1213, org.apache.catalina.core.ContainerBase, ContainerBase.java
destroy():4617, org.apache.catalina.core.StandardContext, StandardContext.java
invoke0():-1, sun.reflect.NativeMethodAccessorImpl, 
NativeMethodAccessorImpl.java
invoke():39, sun.reflect.NativeMethodAccessorImpl, NativeMethodAccessorImpl.java
invoke():25, sun.reflect.DelegatingMethodAccessorImpl,
DelegatingMethodAccessorImpl.java
invoke():324, java.lang.reflect.Method, Method.java
invoke():503, org.apache.commons.modeler.BaseModelMBean, BaseModelMBean.java
invoke():109, org.jboss.mx.server.RawDynamicInvoker, RawDynamicInvoker.java
invoke():473, org.jboss.mx.server.MBeanServerImpl, MBeanServerImpl.java
performUndeployInternal():436, org.jboss.web.tomcat.tc5.TomcatDeployer,
TomcatDeployer.java

The isValid() call returns false and the remove of the non-Serializable
attribute fails:


Caused by: java.lang.IllegalStateException: removeAttribute: Session already
invalidated
at
org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1147)
at
org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1122)
at
org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1405)
at
org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:902)
at
org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:539)
at
org.apache.catalina.session.StandardManager.unload(StandardManager.java:485)
at
org.apache.catalina.session.StandardManager.stop(StandardManager.java:687)
at 
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4511)
at 
org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1213)
at
org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)

These stack traces are from the current jakarta-tomcat-5.0.30 beta source
release. Any attempt to serialize an expired session that has non-Serializable
attributes will show this problem.

One solution would be to not write out invalid sessions from within the
StandardManager doUnload() method.


-- 
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 26372] - java.lang.ThreadDeath when trying to reload an application

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 06:51 ---
(In reply to comment #38)
Hi, 

We are getting this issue, any pointers to fix this would greatly help us. I 
don' see any practical solution being offered in any of the responses below. 
Any help would be greatly appreciated. There is no LOG4J in the stack trace!!!

utility.UpdateHelper is our application code.


thanks in advance
boni
Tomcat Version: 5.0.28 (using AXIS 1.1), windows platform

The stack trace is :
java.lang.ThreadDeath
at org.apache.catalina.loader.WebappClassLoader.loadClass
(WebappClassLoader.java:1229)
at org.apache.catalina.loader.WebappClassLoader.loadClass
(WebappClassLoader.java:1189)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:88)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:195)
at javax.xml.parsers.DocumentBuilderFactory.newInstance
(DocumentBuilderFactory.java:98)
at utility.UpdateHelper.TextValueOfElement(UpdateHelper.java:200)
at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.yasutech.qrules.network.k.if(ExpressionEvaluator.java:1018)
at com.yasutech.qrules.network.k.a(ExpressionEvaluator.java:446)
at com.yasutech.qrules.network.k.if(ExpressionEvaluator.java:88)
at com.yasutech.qrules.network.Activation.evaluateExpression
(Activation.java:964)
at com.yasutech.qrules.network.Activation.changeVariable
(Activation.java:640)
at com.yasutech.qrules.network.Activation.performAssignAction
(Activation.java:626)
at com.yasutech.qrules.network.Activation.decideCourseOfAction
(Activation.java:204)
at com.yasutech.qrules.network.Activation.fire(Activation.java:160)
at com.yasutech.qrules.network.r.try(Agenda.java:94)
at com.yasutech.qrules.network.Rete.run(Rete.java:1330)
at com.yasutech.qrules.rete.ReteAdapter.fireRules(ReteAdapter.java:112)
at com.yasutech.qrules.rete.ReteRuleEngineAPIHelper.evaluateFacts
(ReteRuleEngineAPIHelper.java:620)
at com.yasutech.qrules.rete.ReteRuleEngineAPIHelper.executeRuleset
(ReteRuleEngineAPIHelper.java:333)
at com.yasutech.qrules.rete.ReteEngine.invokeRuleset
(ReteEngine.java:964)
at webservice.example1.server.MyRuleEngineService.invokeRuleset
(MyRuleEngineService.java:366)
at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.axis.providers.java.RPCProvider.invokeMethod
(RPCProvider.java:402)
at org.apache.axis.providers.java.RPCProvider.processMessage
(RPCProvider.java:309)
at org.apache.axis.providers.java.JavaProvider.invoke
(JavaProvider.java:333)
at org.apache.axis.strategies.InvocationStrategy.visit
(InvocationStrategy.java:71)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
at org.apache.axis.handlers.soap.SOAPService.invoke
(SOAPService.java:481)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:323)
at org.apache.axis.transport.http.AxisServlet.doPost
(AxisServlet.java:854)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at org.apache.axis.transport.http.AxisServletBase.service
(AxisServletBase.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal
(StandardContextValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext
(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invo

DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trying to reload an application

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 06:56 ---
(In reply to comment #39)
Some additional information:

This ThreadDeath is just killing the tomcat (java.exe process itself disappears 
from the process list). We have to restart tomcat. Java version being used is 
jdk 1.5.0_04. 

thanks
boni
> (In reply to comment #38)
> Hi, 
> We are getting this issue, any pointers to fix this would greatly help us. I 
> don' see any practical solution being offered in any of the responses below. 
> Any help would be greatly appreciated. There is no LOG4J in the stack trace!!!
> utility.UpdateHelper is our application code.
> thanks in advance
> boni
> Tomcat Version: 5.0.28 (using AXIS 1.1), windows platform
> The stack trace is :
> java.lang.ThreadDeath
>   at org.apache.catalina.loader.WebappClassLoader.loadClass
> (WebappClassLoader.java:1229)
>   at org.apache.catalina.loader.WebappClassLoader.loadClass
> (WebappClassLoader.java:1189)
>   at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:88)
>   at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:195)
>   at javax.xml.parsers.DocumentBuilderFactory.newInstance
> (DocumentBuilderFactory.java:98)
>   at utility.UpdateHelper.TextValueOfElement(UpdateHelper.java:200)
>   at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at com.yasutech.qrules.network.k.if(ExpressionEvaluator.java:1018)
>   at com.yasutech.qrules.network.k.a(ExpressionEvaluator.java:446)
>   at com.yasutech.qrules.network.k.if(ExpressionEvaluator.java:88)
>   at com.yasutech.qrules.network.Activation.evaluateExpression
> (Activation.java:964)
>   at com.yasutech.qrules.network.Activation.changeVariable
> (Activation.java:640)
>   at com.yasutech.qrules.network.Activation.performAssignAction
> (Activation.java:626)
>   at com.yasutech.qrules.network.Activation.decideCourseOfAction
> (Activation.java:204)
>   at com.yasutech.qrules.network.Activation.fire(Activation.java:160)
>   at com.yasutech.qrules.network.r.try(Agenda.java:94)
>   at com.yasutech.qrules.network.Rete.run(Rete.java:1330)
>   at com.yasutech.qrules.rete.ReteAdapter.fireRules(ReteAdapter.java:112)
>   at com.yasutech.qrules.rete.ReteRuleEngineAPIHelper.evaluateFacts
> (ReteRuleEngineAPIHelper.java:620)
>   at com.yasutech.qrules.rete.ReteRuleEngineAPIHelper.executeRuleset
> (ReteRuleEngineAPIHelper.java:333)
>   at com.yasutech.qrules.rete.ReteEngine.invokeRuleset
> (ReteEngine.java:964)
>   at webservice.example1.server.MyRuleEngineService.invokeRuleset
> (MyRuleEngineService.java:366)
>   at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at org.apache.axis.providers.java.RPCProvider.invokeMethod
> (RPCProvider.java:402)
>   at org.apache.axis.providers.java.RPCProvider.processMessage
> (RPCProvider.java:309)
>   at org.apache.axis.providers.java.JavaProvider.invoke
> (JavaProvider.java:333)
>   at org.apache.axis.strategies.InvocationStrategy.visit
> (InvocationStrategy.java:71)
>   at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
>   at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
>   at org.apache.axis.handlers.soap.SOAPService.invoke
> (SOAPService.java:481)
>   at org.apache.axis.server.AxisServer.invoke(AxisServer.java:323)
>   at org.apache.axis.transport.http.AxisServlet.doPost
> (AxisServlet.java:854)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
>   at org.apache.axis.transport.http.AxisServletBase.service
> (AxisServletBase.java:339)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:237)
>   at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:157)
>   at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:214)
>   at org.apache.catalina.core.StandardValveContext.invokeNext
> (StandardValveContext.java:104)
>   at org.apache.catalina.core.StandardPipeline.invoke
> (StandardPipeline.java:520)
>   at org.apache.catalina.core.StandardContextValve.invokeInternal
> (StandardContextValve.java:198)
>   at org.apache.catalin

DO NOT REPLY [Bug 37929] - invalidated session causes pageContext methods to fail

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 06:57 ---
In the future, please attach patches from GlassFish rather than inlining 
them.  As it is, I can't do anything about this since I've already seen the 
patch, so I'm tainted from an IP persective.

Before this patch can be accepted, we need to know that your submission is 
covered by a CCLA.  Otherwise, Sun owns the code, so it can't be incorporated 
into Tomcat.

-- 
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 37933] New: - Bugs in Tomcat

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

   Summary: Bugs in Tomcat
   Product: Tomcat 5
   Version: 5.0.0
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: major
  Priority: P1
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,
I am manokaran.I wrote a program in tomcat using eclipse IDE. 

The code is as follows:

1.>This is a Bean:
package MMM;

public class Bean {
private String name;
public void SetName(String s)
{this.name=s;
}
public String getName()
{
return name;
}

}

 2.>This is a Servlet class:
package MMM;

import java.io.IOException;

import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;



public class Serv  extends HttpServlet{

public void doGet(HttpServletRequest request,HttpServletResponse 
response)
throws ServletException,IOException
{
Bean bean=new Bean();
bean.SetName("manokaran");
request.setAttribute("mano",bean);
RequestDispatcher rd=request.getRequestDispatcher("india.jsp");
rd.forward(request,response);
}
}
3.This is web.xml file:

http://java.sun.com/dtd/web-app_2_3.dtd";>



mano
MMM.Serv


mano
/manokara.do



4.>This is Index.html file:





 
5.>This is a JSP file:



Report:

  The setAttribute, Jsp UseBean ID  and getProperty name must be same.
this is the correct procedure. this format was working well in tomcat and all
web,application servers.  
  But the values set by me were : setAttribute("mano",ss),getProperty
name="mano"  
useBean id="mano1". Observe that the useBean id is set different. 
 Hence logically, this must not work. But in my case it is working in
TOMCAT. The same code is not working in WEBLOGIC.

-- 
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 37934] New: - Tomcat does not follow SRV 12.8.3 regarding empty auth-constraint

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

   Summary: Tomcat does not follow SRV 12.8.3 regarding empty auth-
constraint
   Product: Tomcat 5
   Version: 5.5.14
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Point 2 in Section SRV 12.8.3 in servlet spec states the container shall reject 
a request (403) if access to such resource has been precluded by an empty auth-
constraint element.

However, Tomcat up to 5.5.14 returns 401 in the test.

How to reproduce:
- Deploy attached file
- Visit http://localhost:8080/httpmethod/HTTPMethod/POST

This should not ask for any credential at all.

-- 
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 37934] - Tomcat does not follow SRV 12.8.3 regarding empty auth-constraint

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 07:23 ---
Created an attachment (id=17230)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17230&action=view)
the test web archive


-- 
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 37929] - invalidated session causes pageContext methods to fail

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 07:32 ---
Hi William,

Thanks for looking into this so quickly.

The situation is the same as the one you encountered
with Kin-Man on bug 35351:

>> Just to be clear, is this patch is still covered by your CCLA?  In English, 
>> is 
>> this a grant from glassfish to that ASF?
>> 

> This is just a patch, and there is no license or copyright, so YES.

Let me know if you need anything else.



-- 
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 30489] - removeAttribute: Session already invalidated

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





--- Additional Comments From [EMAIL PROTECTED]  2005-12-16 07:37 ---
Created an attachment (id=17231)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17231&action=view)
A patch for tomcat-5.0.28 that works around this issue


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