Web deployment descriptor model loading and rewriting broken and out-dated
---------------------------------------------------------------------------
Key: PLUTO-510
URL: https://issues.apache.org/jira/browse/PLUTO-510
Project: Pluto
Issue Type: Bug
Components: descriptor
Affects Versions: 2.0.0, 2.0-refactoring
Reporter: Ate Douma
Assignee: Ate Douma
Priority: Critical
Fix For: 2.0.0, 2.0-refactoring
The current Castor based web deployment descriptor loading and rewriting is
rather out-dated, based upon and supporting servlet spec 2.3 only.
Furthermore, it isn't doing it properly even for 2.3 compliant web.xml.
As with Portlet 2.0 we need to support (at least) servlet spec 2.4 too, the
current broken model is really getting in the way and right now its *very* easy
to break Pluto like by adding multiple descriptions (separate languages) or
many other things.
We either have to expand it to support the full servlet 2.4 (or even 2.5)
web-app xsd, or otherwise choose a different solution for AFAIK the only usage
rewriting the descriptor to inject the Pluto PortletServlet during assembly.
NB: there some other related open issues for this, see: PLUTO-466, PLUTO-471
As I've been looking into the portlet descriptor loading using JAXB, I also
gave it some thought of replacing the outdated Castor configuration with a JAXB
based model too.
But, the servlet spec descriptors are *far* more complex and extensive than the
portlet descriptors, and using JAXB (default) resulted in about +/- 90 object
classes...
Reviewing again the real usage here, maintaining a full web.xml object model
*just* to inject a servlet and servlet mapping during assembly, (it is *not*
used/needed by the container), seems to be too much trouble worth it.
Although Jetspeed does use the (old still Pluto 1.0.1 based) WebApplication
object model, it does so for a complete different purpose, and not directly
related to the container by itself.
Furthermore Jetspeed only uses the interfaces, not any of the Pluto
implementation classes for it.
On the other hand, Jetspeed also has this need of rewriting the web.xml to
inject its container servlet, just like Pluto, but for that it uses a very
lightweight XPath based solution, not the Object model.
Coming to a conclusion, I've reviewed the Jetspeed solution for servlet
injection and rewrote it a little to only depend on the now standard J2SE5
XPath API and replaced the Pluto WebApp object model usage with it (as an
independent Pluto only implementation, not tied to Jetspeed).
As result, I could then throw out all the pluto.om.servlet classes and
interfaces and the Castor service handling for that.
While this might potentially break some external usages of these interfaces
(well, that is: those dependent on Pluto 1.1.xx versions), so this causes a
small migration side-effect,
anyone *relying* on the current Pluto web.xml object model handling should be
reviewing that already anyway because of its out-dated and broken state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
