Andrew Stevens skrev:
Date: Wed, 18 Jul 2007 23:42:34 -0400
From: [EMAIL PROTECTED]
With the current servlet service framework I just don't know how to
integrate JSPs - what this thread was actually about.
Isn't the standard way of integrating JSP to just call it through a
RequestDispatcher that you get from
ServletContext.getRequestDispatcher(String path)?
I have rarely worked with all that stuff and am not familiar with it.
When reading the corresponding section in the servlet spec it sounds
reasonable though. I only wonder what the downsides of this approach
are. Or: Why was the default implementation JSPEngineImpl [1]
implemented differently (though there is an implementation with the
approach you describe [2])?
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImpl.java?revision=433543&view=markup
[2]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.java?revision=433543&view=markup
Not quite - the implementation in [2] accesses the JSP engine through getNamedDispatcher, not
getRequestDispatcher; if you're wanting to call /cocoon/foobar.jsp it looks up the configured name
(getNamedDispatcher("*.jsp") by default, which is what Tomcat uses, but it's called "JSP 1.2
Processor" on Websphere 5 and probably something else on other containers) and before calling include
(or forward, depending on configuration) sets the appropriate attributes in the request object, described in
the servlet spec, to make the engine think it's been called by a 'jsp:include
page="/cocoon/foobar.jsp"' (or jsp:forward).
What Daniel described would be an implementation that just calls
getRequestDispatcher("/cocoon/foobar.jsp"), and calls include/forward on that. There
isn't an existing implementation which does that, but it's what I was describing in my earlier
post (http://marc.info/?l=xml-cocoon-dev&m=118437354213375&w=2). The biggest problem
with it is that if JSPs are mapped to go through the Cocoon servlet (like the default Cocoon
2.1.x web.xml does), then getRequestDispatcher will return a reference to Cocoon. So Cocoon
passes the request to Cocoon for processing, which passes it to Cocoon for processing, which
passes it to ... well, you get the picture. Eventually you get a java.lang.StackOverflowError
and a 500 Server Error gets returned to the browser :-( Which is probably why the existing
Cocoon implementations all use some other way to call the container's JSP engine.
You only get the infinite loop if you insist on mounting the Cocoon
servlet and the JSP at the same path if you use different paths the
problem disappear.
Also if you want to use a named dispatcher, we could make the named
dispatcher in the ServletServiceContext fall back to the original
servlet context, for names that the servlet service isn't connected to.
/Daniel
