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 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.
It could be a bug with the tag and tag pooling. Disable tag pooling to see if it fixes the problem.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
