[jira] Commented: (PLUTO-510) Web deployment descriptor model loading and rewriting broken and out-dated

["Eric Dalquist (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PLUTO-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639669#action_12639669 ] 

Eric Dalquist commented on PLUTO-510:
-------------------------------------

+1 for the XPath based web.xml rewriting approach, with Pluto 1.0 uPortal had implemented a similar approach to deal with multiple versions of web.xml files. I've also verified that uPortal doesn't reference anything from org.apache.pluto.descriptors.servlet anywhere and I agree that this API shouldn't be used anyways due the the issues mentioned above.

> 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.