You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Craig Doremus (JIRA)" <ji...@apache.org> on 2006/04/15 18:50:01 UTC
[jira] Updated: (PLUTO-216) JSTL 1.1 EL (Expression Language) won't
work by default with the Pluto Deployer/Descriptors sub-project
[ http://issues.apache.org/jira/browse/PLUTO-216?page=all ]
Craig Doremus updated PLUTO-216:
--------------------------------
Fix Version: 1.0.2
> 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
> 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