DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31523>. 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=31523 Request parameters are not always passed to HttpServlet.service ------- Additional Comments From [EMAIL PROTECTED] 2004-10-04 15:56 ------- I've tried running Tomcat with the security manager enabled (with a grant all in the policy file). This brought up some worrying facts. I will first give a little info on the way our application is working. As I've said before, we are using Cocoon Forms with the underlying flow to chain the forms. However the default flow (using javascript) was not powerful enough. The concept of a continuation framework, is that it simulates a thread, which is suspended when a page is shown to the user, and continued when the user submits the form. To be able to build more robust applications, we decided to use a real thread as the flow, which is locked (with wait) and notified. It is impossible for this thread to run simultaneously with the servlet thread. When the first is running, the second is locked and vice versa. However I've discovered, that even though these threads don't run at the same time, either Cocoon or Tomcat is affected. They seem to rely on the thread currently executing. When Tomcat is running with the security manager enabled, the creation of the form hierarchy triggers a NullPointerException at org.apache.coyote.tomcat5.CoyoteRequestFacade. getQueryString(CoyoteRequestFacade.java:481). I've managed to get around this, by creating an Expression that executes the malicious method. This Expression is then passed to the servlet thread, which executes it from its own context and passes the result back to the flow thread. Still no two threads will ever be running at the same time, but this time the method succeeds. Is this expected behaviour? I've looked at the postparam application. If the bug is in Tomcat, this should trigger it, however it might be very hard to hit it, because you might have to resubmit over 100 times. What makes it even more complicated is that we discovered that we can avoid the problem, by printing lots of debug to stdout. This shows how sensitive the timing is. At this moment we are considering to drop the flow thread and emulate it with a bytecode interpreter. If it is correct that Tomcat cannot handle multiple threads inside a servlet, even when they cannot run concurrently, then this might very well be what triggers the problem. In that case, I apologise for the trouble and I will definitely switch to a bytecode interpreter that runs in the servlet thread. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
