Remy Maucherat wrote:
Jean-Francois Arcand wrote:
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.
If a webapp hags on to the facade, it can access the underlying request. That seems to me like a security problem. That also seems like a security bug to Bill, and that's why we both vetoed your commit.
I understand and I will revert the patch (but I/we need to fix the problem). What about not calling the clear() method? What I find strange is the following:
CoyoteRequest_instance invokes CoyoteRequestFacade_instance.clear() which set CoyoteRequest_instance = null. Same for the response.
So applying the above patch by not calling the clear method should be better that the current solution (hope to have less that 2 -1 ;-)
I will look at the bug. However, since the facade is only cleared at the end of the request processing (in the recycle), I don't see how you can produce a valid test case.
Very simple one actually.....I was under the same impression until they sent me the test case.
It could be a bug with the tag and tag pooling. Disable tag pooling to see if it fixes the problem.
No, it doesn't fix the problem on both 4.1.x/5.x
-- Jeanfrancois
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]
