DO NOT REPLY [Bug 22732] - Cocoon Servlet can't be included

[bu...@apache.org]

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=22732>.
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=22732


ats37@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




------- Additional Comments From ats37@hotmail.com  2005-06-30 15:23 -------
According to the Servlet spec (section 8.3.1 in the 2.2 spec)
"When a servlet is being used from within an include, it is sometimes necessary
for that servlet to know the path by which it was invoked and not the original
request paths.  The following request attributes are set:
javax.servlet.include.request_uri
..."

However, the Cocoon servlet doesn't check for these attributes and passes the
original request's values to the URI matchers.  This means that if you have a
pipeline which matches *.jsp (feeding them through the JSPGenerator or
JSPReader), and that processes a JSP which does a c:import (*) of any other URL
that's handled by the Cocoon servlet, then instead of the included page Cocoon
will execute the JSP again.  And again.  And again, until it hits an
OutOfMemoryError and crashes the app server...

It's not much better if you remove the *.jsp pipeline matchers (and servlet
mapping) and let the container's own JSPServlet handle them.  In this case, the
pipeline will give a 404, which the import tag (in line with the spec) throws as
a JSPException.

You can work around it in a couple of ways I've thought of -
1) by excluding the *.jsp servlet mapping (so the continer runs them itself),
but still have pipeline matchers for the original URLs, which return the
corresponding included pages instead.  This means the page specified in the
c:import tag is irrelevant as the pipeline actually determines what gets
included (which is a maintenance nightmare).
2) add an extra request parameter to all the c:import URLs containing the same
path, and use the request param matchers to process them instead of the URI
matchers.  It's an extra hassle to include them, however, and also means that
map:mount won't strip off the path prefixes like you might expect so you end up
matching on the full path even in the sub-sitemaps.

It would be much easier if the URIs being matched were the ones of the files
being included.  I'd be happy to take a stab at a patch myself, but where would
be the best place to fix it - CocoonServlet, HttpEnvironment, HttpResponse or
just in the matchers?


(*) jsp:include would also suffer the same problem, except that the Cocoon
servlet always uses getOutputStream and the JSP will already have done a
getWriter, so it throws an IllegalStateException instead.

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