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