[ http://issues.apache.org/jira/browse/PLUTO-216?page=all ]
Elliot Metsger updated PLUTO-216:
---------------------------------
Attachment: PLUTO-216-02-cumulative.txt
Attaching a patch for tracking progress, not meant to be applied yet. It is a
cumulative patch (it includes the modifications in PLUTO-216-01.patch).
Added
descriptors/src/test/org/apache/pluto/descriptors/services/impl/FileWebAppDescriptorServiceImplTest.java
Tests the WebAppDescriptorService read() and write() methods to make sure
they work with the "version" attribute
of the <web-app> element properly.
Added
descriptors/src/test/org/apache/pluto/descriptors/servlet/WebAppDDVersionTest.java
Tests the WebAppDD getServletVersion() methods, as well as the (un)marshaling
of the class using the Castor mapping file.
Added
descriptors/src/java/org/apache/pluto/descriptors/servlet/ServletVersionCastorFieldHandler.java
This is a class which implements Castor's AbstractFieldHandler. See
http://www.castor.org/xml-fieldhandlers.html. This
fieldhandler is for the ServletVersion field in the Castor mapping file. The
FieldHandler intercepts the getValue() call and
returns null if the WebAppDD servlet version is 2.3. This prevents Castor
from putting a "version=2.3" attribute in a web.xml
file that is meant to conform to servlet specification 2.3.
Modified
descriptors/src/test/org/apache/pluto/descriptors/services/impl/FileWebAppDescriptorServiceImplTest.java
Turned off debugging
Modified
descriptors/src/java/org/apache/pluto/descriptors/services/impl/AbstractCastorDescriptorService.java
Added protected writeInternal(Object, OutputFormat) throws IOException
method. Allows the implementation to supply their
own OutputFormat (used when working with Servlet 2.4 descriptors that don't
have a doc type).
Modified
descriptors/src/java/org/apache/pluto/descriptors/services/impl/FileWebAppDescriptorServiceImpl.java
Added a new constructor public FileWebAppDescriptorServiceImpl(String,
String) which allows clients to supply their
own context name and web.xml file. Used at the moment by the two new unit
tests.
Modified
descriptors/src/java/org/apache/pluto/descriptors/services/impl/AbstractWebAppDescriptorService.java
Updated the public write(WebAppDD) method to check for the servletVersion
field of the WebAppDD. If the version
is equal to 2.4, then an OutputFormat object is created sans doctype.
Otherwise the default behavior is maintained.
Modified descriptors/src/java/org/apache/pluto/descriptors/servlet/WebAppDD.java
Modified field "servletVersion" to default to the value "2.3".
Modified
descriptors/src/conf/org/apache/pluto/descriptors/servlet/castor-web-xml-mapping.xml
Added the ServletVersion field with its type and castor field handler.
> 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, 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
