Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of ats37@hotmail.com designates
 65.54.246.87 as permitted sender)
Message-ID: <BAY121-W184ED90375070D05564682ADFB0@phx.gbl>
From: Andrew Stevens <ats37@hotmail.com>
To: <dev@cocoon.apache.org>
Subject: RE: JSP integration
Date: Fri, 20 Jul 2007 00:38:39 +0100
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> Date: Wed, 18 Jul 2007 23:42:34 -0400
> From: joerg.heinicke@gmx.de
>=20
> >> With the current servlet service framework I just don't know how to=20
> >> integrate JSPs - what this thread was actually about.
> >=20
> > Isn't the standard way of integrating JSP to just call it through a=20
> > RequestDispatcher that you get from=20
> > ServletContext.getRequestDispatcher(String path)?
>=20
> 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])?
>=20
> Joerg
>=20
> [1]
> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/=
java/org/apache/cocoon/components/jsp/JSPEngineImpl.java?revision=3D433543&=
view=3Dmarkup
> [2]
> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/=
java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.j=
ava?revision=3D433543&view=3Dmarkup

Not quite - the implementation in [2] accesses the JSP engine through getNa=
medDispatcher, 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 cal=
ling include (or forward, depending on configuration) sets the appropriate =
attributes in the request object, described in the servlet spec, to make th=
e engine think it's been called by a 'jsp:include page=3D"/cocoon/foobar.js=
p"' (or jsp:forward).

What Daniel described would be an implementation that just calls getRequest=
Dispatcher("/cocoon/foobar.jsp"), and calls include/forward on that.  There=
 isn't an existing implementation which does that, but it's what I was desc=
ribing in my earlier post (http://marc.info/?l=3Dxml-cocoon-dev&m=3D1184373=
54213375&w=3D2).  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 p=
asses the request to Cocoon for processing, which passes it to Cocoon for p=
rocessing, which passes it to ... well, you get the picture.  Eventually yo=
u get a java.lang.StackOverflowError and a 500 Server Error gets returned t=
o the browser :-(  Which is probably why the existing Cocoon implementation=
s all use some other way to call the container's JSP engine.


Andrew.
--=20
http://pseudoq.sourceforge.net/

_________________________________________________________________
Try Live.com - your fast, personalised homepage with all the things you car=
e about in one place.
http://www.live.com/?mkt=3Den-gb  =