[ http://issues.apache.org/jira/browse/PLUTO-216?page=all ]
Elliot Metsger resolved PLUTO-216.
----------------------------------
Resolution: Fixed
Patch committed revision 429058. The patches attached to this issue were are
the basis for the commit, but were modified.
The 'maven deploy' goal can now deploy portlets using 2.3 and 2.4 web.xml
descriptors (whether or not xml namespaces are used).
The admin portlet can deploy portlets using 2.3 and 2.4 web.xml descriptors,
but 2.4 web.xml descriptors cannot use xml namespaces.
All unit tests pass, and the Pluto testsuite portlet passes all tests.
> 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
> Issue Type: Improvement
> Components: deployer
> Affects Versions: 1.0.1
> Environment: Pluto 1.0.1 final, Tomcat 5.5, Java 1.5, JSTL 1.1
> Reporter: Elliot Metsger
> Assigned To: Elliot Metsger
> Fix For: 1.0.2
>
> Attachments: PLUTO-216-01.patch, PLUTO-216-02-cumulative.txt
>
>
> 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
