> 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.
Andrew.
--
http://pseudoq.sourceforge.net/
_________________________________________________________________
Try Live.com - your fast, personalised homepage with all the things you care
about in one place.
http://www.live.com/?mkt=en-gb
