[ http://issues.apache.org/jira/browse/PLUTO-216?page=all ]
Elliot Metsger updated PLUTO-216:
---------------------------------
Attachment: PLUTO-216-01.patch
Attaching PLUTO-216-01.patch.
> JSTL 1.1 EL (Expression Language) won't work by default with the Pluto
> Deployer/Descriptors sub-project
> -------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-216
> URL: http://issues.apache.org/jira/browse/PLUTO-216
> Project: Pluto
> Type: Improvement
> Components: deployer
> Versions: 1.0.1
> Environment: Pluto 1.0.1 final, Tomcat 5.5, Java 1.5, JSTL 1.1
> Reporter: Elliot Metsger
> Attachments: PLUTO-216-01.patch
>
> Note: this issue affects the Descriptors sub-project but I didn't see a
> Component labeled "Descriptors".
> Another Note: Everything in here is MHO! I'm new to this stuff.
> In order to use JSTL 1.1 in a portlet view, one must use a servlet container
> that supports Servlet Specification version 2.4 and JSP 2.0. Tomcat 5.5
> (which supports servlet spec 2.4/JSP 2.0) won't "activate" the JSTL 1.1
> expression language unless the attribute "version" with a value of "2.4" is
> present in the <web-app> element of the web.xml deployment descriptor. I
> presume this is for backwards compatability with JSTL 1.0 (see appendix A.1
> of JSTL 1.1 spec).
> This is an issue for portlet authors that use JSTL 1.1 EL who deploy with or
> run in the pluto container, because the Pluto descriptors and portal
> sub-projects don't preserve the "version" attribute on the <web-app> element
> if it is placed there by the portlet author.
> This potentially involves a number of changes affecting the Descriptors
> sub-project (There may be classes in the Portal sub-project to be dealt with
> as well, when the deployment descriptor is unmarshaled):
> 1. The models for Servlet 2.4 descriptors are different from Servlet 2.3
> descriptors. This could lead to supporting multiple castor mapping files
> instead of a singular mapping file. Currently the existing mapping file
> won't marshal a valid Servlet 2.4 web.xml. This is fixed by implementing two
> custom castor field handlers (to handle the pesky <distributable/> element),
> and re-ordering some of the elements in the mapping file (and adding a
> "version" field w/ accessors in the WebAppDD class).
> 2. The existing web.xml file shipped with 1.0.1 final that is used by the
> test cases claims to be a Servlet 2.4 descriptor but it doesn't validate
> against the 2.4 XSD. This is fixed by signifigantly re-factoring the
> document. Additional elements (such as <jsp-config>) are introduced into the
> web.xml file that don't have corresponding Java objects - the corresponding
> Java objects need to be created and the castor mapping updated in order for
> the unit tests to pass (e.g. there is a problem with unmarshaling a 2.4
> descriptor).
> 3. Minor modifications were made to AbstractCastorDescriptorService in order
> to allow implementations to suppy their own
> org.apache.xml.serializer.OutputFormat (since Servlet 2.3 descriptors should
> have a Doctype and Servlet 2.4 descriptors don't).
> These are just three issues that I've found so far. I started out by trying
> to do the simplest thing possible: just have the Descriptors sub-project
> preserve a version attribute if it is present. It has kind of snowballed
> from there as I dug into the code.
> Probably the Descriptors project doesn't need to know everything about the
> descriptor. If castor runs across elements during marshaling that aren't
> defined in the mapping file, it can be ignorant of the elements (as long as
> they aren't required for Pluto's purposes!); when it comes time to unmarshal
> the descriptor it can just spit the unknown elements back out into the
> web.xml in document order. So the solution may be simpler than I've outlined
> above.
> I'm going to go back and try to do the simplest thing and I'll put a patch on
> this issue and see what people think.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
