cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JSP integration
Date Fri, 20 Jul 2007 08:21:07 GMT
Andrew Stevens skrev:
>> Date: Wed, 18 Jul 2007 23:42:34 -0400
>> From:
>>>> 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]
>> [2]
> 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 (
 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.


View raw message