Wednesday, January 21, 2009

pondering WebappToolServlet

In my intermittent work on the Sakai tool side, using the Eclipse Sakai plugin, I have seen references to WebappToolServlet in the generated web.xml.

Clearly it's the first stage in handling requests. Stuff worked so I haven't worried about it. However I poked around a bit and found this:

WebappToolServlet is a CARET invention (pace Andrew Thornton)
that was created to allow other Java view technologies than JSF
to work in the Sakai dispatching environment.
[snip - about going to conferences where all this is discussed - casey]
Without WebappToolServlet the context path part of the URL will
be mapped incorrectly, as well as various other parts of the
request object being empty. This correction cannot be made with
a simple filter, since on initial entry to the context there is
no valid URL.
Yes, Spring is meant to avoid all dependence on the container, but
this is plain JSPs here. This is no kind of supported option in
Sakai - you are basically "on your own" - although I'm
sure the few folks that have done JSP work in Sakai (Andy, Ian)
will be glad to help you out.
The supported/recommended option in Sakai until now has been JSF,
which is what the dispatching environment was designed for.
We are expecting a transition to RSF underway over these few
The most direct step towards sanity you could take if you insist
on sticking with JSPs is to move to SpringMVC. This defines
various taglibs that should let you resolve beans as variables.
As a "framework" it's pretty useless however (naturally I would
say that...)

whcih explains enough for me. Since I just want to use something to bootstrap the GWT stuff and move forward I'll no longer ponder WebappToolServlet.

No comments: