Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
2.0-refactoring, 2.0.0
-
None
Description
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.