Mixing with jsp and forwarding

30 views
Skip to first unread message

Kevin Glynn

unread,
Oct 2, 2007, 12:07:41 PM10/2/07
to webstack...@googlegroups.com

A change of subject :).

Apologies if these are dumb questions, just break it to me gently.

In the context of the JavaServlet adapter I want to use JSP pages for
the View part of my application (results, errors, etc.). I had
thought that I could use FileResources for this, but afaics appservers
(such as tomcat) rely on file extension not contenttype to detect jsp
page and FileResources are just copied straight onto the transaction's
response stream.

A possibly related question is that I would like to be able to
'forward' between webapp components, not just 'redirect'. For example,
I only want to have one of my components using jpython, the others
will use cpython and mod_python or one of the other frameworks. I want
to be able to invoke between them as easily as I can invoke resources
within them. So, I could 'forward' to a jsp page e.g. in the above case.

(In java, I can say

rd = getServletContext().getRequestDispatcher("/import.jsp");
rd.forward(request, response);
)

I hope that makes sense.

thanks
k

Paul Boddie

unread,
Oct 3, 2007, 5:14:49 AM10/3/07
to webstack-discuss
On 2 Okt, 18:07, Kevin Glynn <kevin.gl...@gmail.com> wrote:
> A change of subject :).
>
> Apologies if these are dumb questions, just break it to me gently.

I'm more worried that the questions are likely to be trickier than I
thought. ;-)

> In the context of the JavaServlet adapter I want to use JSP pages for
> the View part of my application (results, errors, etc.). I had
> thought that I could use FileResources for this, but afaics appservers
> (such as tomcat) rely on file extension not contenttype to detect jsp
> page and FileResources are just copied straight onto the transaction's
> response stream.

Yes, the FileResource is just a convenience class which knows how to
copy files to the response stream. What you want to do is to ask the
JSP environment to evaluate or run a JSP using a populated request
object.

> A possibly related question is that I would like to be able to
> 'forward' between webapp components, not just 'redirect'. For example,
> I only want to have one of my components using jpython, the others
> will use cpython and mod_python or one of the other frameworks. I want
> to be able to invoke between them as easily as I can invoke resources
> within them. So, I could 'forward' to a jsp page e.g. in the above case.
>
> (In java, I can say
>
> rd = getServletContext().getRequestDispatcher("/import.jsp");
> rd.forward(request, response);
> )
>
> I hope that makes sense.

Yes, you want to hand over control to another component, rather than
sending a redirect to the client which makes a new request which then
arrives at that component. In the JSP case, I think you need two
things:

1. To be able to do this kind of "internal redirect", which is really
just asking the server to invoke some other component within the same
request.
2. The ability to provide data which gets used when evaluating the
JSP.

The first part could be done by accessing the Servlet API directly
through a copy of the request object held by a WebStack Transaction
object. I don't provide any convenience methods for getting the
underlying environment, but I could certainly add something to start
you off conveniently; then you'd use method calls much like those
you've described. Exposing the environment's dispatch mechanisms is
something I've avoided because there may be restrictions in various
environments, and I'd rather remain mostly unaware of the detail of,
for example, how stuff like Zope's dispatch mechanisms work. ;-)

The second part requires a bit more work, probably, since JSPs
typically make use of things like sessions, request parameters and
request attributes, but the latter for WebStack applications currently
reside within WebStack itself, ignoring the Java Servlet
implementation of request attributes. What I should do is to change
WebStack.JavaServlet.Transaction to use the Servlet API capabilities
here instead - it'd involve overriding the default attribute support
in WebStack.Generic.Transaction, exposing the underlying attributes
possibly via a dictionary-like class.

I'll have a look at this in the next couple of days and try and push
some of my changes out.

Paul

Kevin Glynn

unread,
Oct 3, 2007, 11:10:23 AM10/3/07
to webstack...@googlegroups.com

Paul Boddie writes:
>

> > In the context of the JavaServlet adapter I want to use JSP pages for
> > the View part of my application (results, errors, etc.). I had
> > thought that I could use FileResources for this, but afaics appservers
> > (such as tomcat) rely on file extension not contenttype to detect jsp
> > page and FileResources are just copied straight onto the transaction's
> > response stream.
>
> Yes, the FileResource is just a convenience class which knows how to
> copy files to the response stream. What you want to do is to ask the
> JSP environment to evaluate or run a JSP using a populated request
> object.
>

yes, that makes sense to me.

sure, me too! But you still think you can expose this ability? I was
thinking that there could be a new type of dynamic Resource identified
by a path that the component can invoke. Under the covers it would ask
the underlying environment to do a forward.

> The second part requires a bit more work, probably, since JSPs
> typically make use of things like sessions, request parameters and
> request attributes, but the latter for WebStack applications currently
> reside within WebStack itself, ignoring the Java Servlet
> implementation of request attributes. What I should do is to change
> WebStack.JavaServlet.Transaction to use the Servlet API capabilities
> here instead - it'd involve overriding the default attribute support
> in WebStack.Generic.Transaction, exposing the underlying attributes
> possibly via a dictionary-like class.
>

Oh, I hadn't noticed that the attributes were not really request
attributes. We would need at least request attributes and session
attributes (needed for use with the redirect).

> I'll have a look at this in the next couple of days and try and push
> some of my changes out.
>

That would be great. If we can't do this then I believe that would be
a showstopper for our scenario.

cheers
k

Reply all
Reply to author
Forward
0 new messages