OK, let's try to describe the problem. First, here is the stack trace the application is throwing when running:

java.lang.NullPointerException
at org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca
de.java:271)
at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306)
at com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284)
at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204)
at com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236)
at com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178)
at org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205)
at org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138)
at org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97
)
at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)


I don't think this is an application bug.


Note that the problem doesn't occurs with 4.0.x or if you run it without the security manager. The first time the application runs (very simple test), no exception is produced. The second time you run, then the old facade object (the one used by the first request) is still available but since the clear method has been invoked, the request instance is set to null (so the NPE is thrown). It is clear that the facade object used when the NPE is thrown is the one used by the first invokation. It seems that facade object has not been recycled properly.


I can send you the war file if you want to see the behaviour. It is very easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with package protection/access and the security changes we made in 5).

I don't think the current solution open security issue, but I agree it is not an elegant solution. The other solution we have is to not invoke, in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to null the CoyoteRequest. That solution works also:

Index: CoyoteRequest.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.8
diff -u -r1.8 CoyoteRequest.java
--- CoyoteRequest.java 6 Jun 2003 03:03:33 -0000 1.8
+++ CoyoteRequest.java 6 Jun 2003 16:55:13 -0000
@@ -438,7 +438,6 @@
mappingData.recycle();


if ((Constants.SECURITY) && (facade != null)) {
- facade.clear();
facade = null;
}
.
This way the facade will be cleared and we will not create a facade for every request.



-- Jeanfrancois






Bill Barker wrote:
----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 11:49 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java



Bill Barker wrote:

I'm -1 on this patch unless you can explain what the bug exactly was,
and how the recycling couldn't properly reset the facade.

I'm not really happy with the patch either. I'll postpone adding my

(since

it's the second, binding) -1 until you provide a better explaination.

Well, I have no idea what the bug report mentioned looks like, so I can't provide a real evaluation. However, what I'm now pretty sure about is that the patch is possibly unsafe.

Note: AFAIK, one -1 is enough.


I've had plenty of solo -1s ignored :).  I understood the rule as "more -1
than +1 with the committer assumed to +1".  Then, again, I'm not big on
rules, and that's for the PMC to work out anyway ;-).

Reading Remy's comments, I'm giving my official -1 (so, even with my
interpretation, this must be reverted unless you can convince someone to
change their Vote).


Remy


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



Reply via email to