Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ats37@hotmail.com designates
 65.54.175.24 as permitted sender)
Message-ID: <BAY104-F149B1E31BB904B6321F43FADE10@phx.gbl>
From: "Andrew Stevens" <ats37@hotmail.com>
To: users@cocoon.apache.org
Subject: JSPEngineServletRequest and Websphere
Date: Tue, 28 Jun 2005 19:27:00 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

I've been having some problems with the JSP generator on Websphere, which 
I've tracked down to the JSPEngineServletRequest.  Does anyone know why it 
was implemented in the way it is?

I had no trouble at first, reading the output of relatively simple JSPs.  I 
had to adapt a few of them with an all-enclosing div element (to avoid 
complaints that "the content after the root element must be well formed"), 
but that's no big deal.  However, the problems started once I tried to use 
the output of some JSPs which contained <jsp:include> tags - these just 
threw ServletExceptions complaining that "Request wrapper is not of type 
HttpServletRequestWrapper".  Exactly where it's got the wrapper from I'm not 
sure, presumably somewhere buried deep in the request dispatcher's include 
method. but it appears that whenever the request object type is Cocoon's 
JSPEngineServletRequest rather than Websphere's SRTServletRequest it can't 
handle this and the result is this exception.

In fact, this problem isn't specific to Cocoon; any 
RequestDispatcher.include call passing in a custom request object to a JSP 
that contains a jsp:include (or JSTL <c:import> to a local path, since that 
also goes through the request dispatcher again) gives the same problem.  
However, since that's the way Cocoon's JSP generator/reader work, they 
suffer the same restriction.

Since removing all the includes from our JSPs isn't an option, it looks like 
I might have to write a Websphere-specific JSPEngine implementation to work 
around this.  At least it means the WLS one will have some company :-)  
However, as I started working on this it got me wondering why the 
JSPEngineServletRequest is written the way it is.  As far as I can see, for 
the most part it's doing exactly the same as the standard 
HttpServletRequestWrapper class does - it wraps the original request and 
passes most of the method calls through to it.  Why didn't it just extend 
HttpServletRequestWrapper?  Add a two-arg constructor which stores the 
jspFile and calls super(request), override getAttribute and a few other 
methods, and not only would it be half the size but things ought to start 
working in Websphere without any additional changes being needed...  Or is 
there some particular reason it does all that delegating itself?

Also, I'm curious about the choice of methods which don't just delegate to 
the wrapped request.  Why is getParameterMap overridden to return null when 
getParameter, getParameterNames and getParameterValues still return the 
original values?  Likewise, why override getRequestURL to return null (the 
cause, I believe, of the "org.apache.jasper.JasperException: No output 
directory: String index out of range: -1" error I started getting from 
Websphere) when getRequestURI, getServletPath, etc. still return their 
original values?  It all seems rather inconsistent to me.

Anyone know (or care to guess at) the reasons for doing this?  Or is it 
simply that it's always been that way?  Would I be better off asking on the 
dev mailing list?


Andrew.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org