[
https://issues.apache.org/jira/browse/PLUTO-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved PLUTO-510.
-----------------------------
Resolution: Fixed
Done
> 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.
