[ http://issues.apache.org/jira/browse/PLUTO-216?page=comments#action_12368003 ]
Elliot Metsger commented on PLUTO-216: -------------------------------------- I'm attaching a patch which is really just to keep track of my changes, I don't think it is ready to be applied yet. It is attached as PLUTO-216-01.patch. The next step is to modify the implementation to use the "servletVersion" field of the WebAppDD class. That will follow in another patch. PLUTO-216-01.patch modifies the following files: descriptors/src/test/org/apache/pluto/descriptors/servlet/CastorMappingTest.java Turned on a debugging flag (for the final patch this would be turned off) descriptors/src/java/org/apache/pluto/descriptors/servlet/WebAppDD.java Modified to add accessors for the "servletVersion" field. descriptors/src/conf/org/apache/pluto/descriptors/servlet/castor-web-xml-mapping.xml Modified to map the "version" attribute of the <web-app> element. PLUTO-216-01.patch adds the following files: descriptors/src/test/org/apache/pluto/descriptors/servlet/WebAppDDVersionTest.java Contains unit tests for the work done. descriptors/src/conf/org/apache/pluto/descriptors/servlet/web-2.3.xml A test web.xml conforming to servlet spec 2.3, used by the WebAppDDVersionTest. This file validates against the Servlet Spec's 2.3 DTD. > 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
