Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39EC8CF8.7A76AEA9@eng.sun.com>
Date: Tue, 17 Oct 2000 10:31:36 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: Stefano Mazzocchi <stefano@apache.org>
CC: cocoon-dev@xml.apache.org
Subject: Re: [C2] RequestDispatchers && XSP
References: 
 <Pine.LNX.4.21.0010171505150.10356-200000@fztig938.bank.dresdner.net>
 <39EC7583.1565D19@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> Marcus Crafter wrote:
> >
> > Hi All,
> >
> >         I've noticed some interesting behaviour in C2 with the use of
> >         RequestDispatcher objects in T4M2. The following code is taken from
> >         T4M2 (ApplicationRequest.java && ApplicationHttpRequest.java):
> >
> > line 215 && 387 resp.:
> >
> >         while (request != null) {
> >             if (request instanceof Request)
> >                 break;
> > *           if (!(request instanceof ServletRequestWrapper)) {
> >                 throw new IllegalArgumentException
> >                     (sm.getString("applicationRequest.badRequest"));
> >             }
> >             request = ((ServletRequestWrapper) request).getRequest();
> >         }
> >
> >         The code was found during a trace of what happens when one does a
> >
> >           request.getRequestDispatcher("xyz").forward(request, response);
> >
> >         in some XSP code.
> >
> >         The T4M2 code unfortunately throws an IllegalArgumentException (at the
> >         *) as it expects a ServletRequestWrapper instance - and we pass it a
> >         Cocoon 2 internal HttpRequest object which doesn't inherit from
> >         ServletRequestWrapper (implements HttpServletRequest).
> >
> >         Question is, what can we do about it ? ServletRequestWrapper is a
> >         Servlet 2.3 thing so we would wipe out all the T3 users if we changed
> >         HttpResponse to extend from it (then again.. C2 seems to be really a
> >         T4 app anyway.. :-) ).
> >
> >         To fix the problem I changed HttpEnvironment.java to store the
> >         original servlet parameters as well as the C2 custom ones, and changed
> >         ServletGenerator.java to use these values for the XSP request/response
> >         variables. Patch is attached.
> >
> >         This was a bit of a hack though. Any other ideas about to tackle this
> >         one ?
>
> Uh, big issue here.
>
> So the real question is: should we support T3 at all?
>
> What do you think?
>

You're going to have a problem with T3 (or any other 2.2-based container) no matter
what.  In servlet 2.2, the specification requires you to pass on the *original*
request and response objects that your servlet received on to a RD.include() or
RD.forward() call.  T3 relies on this restriction, and is going to throw a
ClassCastException back at you, because it tries to cast the request back to it's
internal implementation object.  See class
org.apache.tomcat.facade.RequestDispatcherImpl in the 3.2 branch.

For T4 (i.e. servlet 2.3), the whole idea of the wrapper classes is so that you can
do this kind of thing portably.  Would it be possible to have your custom objects
extend the wrapper classes instead?  The bad news -- that limits you to T4 and Orion
until the other container providers get off their behinds and start coding.  The
good news -- you'd be portable across 2.3 containers (not that I'm encouraging you
to use something *besides* Tomcat, but your users might want to :-).

One other consideration if you decide to go for 2.3-minimum -- this enables you to
see if the new Filter abstraction fits into the strategy for C2 in any useful way.
Filters let an application define Valve-type things (in Catalina-speak) at the
application level, and supports the same capability to wrap request and response
objects that are passed on as RD does now.  (NOTE:  there will be some tweaks to the
Filter API before 2.3 final is released, but they won't be huge.)

>
> >         BTW - should mails like this really go to cocoon-dev or is
> >         cocoon-users more appropriate ?
>
> No, this is perfect.
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat