Awesome!  Welcome aboard elliot.   

I am about 3-4 weeks from getting over the hump on up a pretty hectic
project.  Looking forward to helping you and craig make some progress again.
. .

> -----Original Message-----
> From: Elliot Metsger (JIRA) [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, July 22, 2006 1:41 PM
> To: [email protected]
> Subject: [jira] Resolved: (PLUTO-219) <distributable> element 
> in web.xml files produced by the descriptor/depolyer 
> sub-projects is not valid with respect to the Servlet 2.4 xsd
> 
>      [ http://issues.apache.org/jira/browse/PLUTO-219?page=all ]
> 
> Elliot Metsger resolved PLUTO-219.
> ----------------------------------
> 
>     Resolution: Fixed
> 
> Improved the handling of the <distributable/> element by 
> Castor and the Admin portlet.  The patch attached to this 
> issue was the basis for the fix, but was modified before it 
> was committed.
> 
> Here's a summary of the changes:
> Added 
> descriptors/src/java/org/apache/pluto/descriptors/servlet/Dist
> ributableDD.java
> + Models the <distributable/> web-app element
> 
> Modified 
> descriptors/src/test/org/apache/pluto/descriptors/servlet/WebA
> ppDDTest.java
> + Added test for the Distributable object
> 
> Modified 
> descriptors/src/java/org/apache/pluto/descriptors/servlet/WebA
> ppDD.java
> + Changed distributable field type from boolean to DistributableDD 
> + Updated accessors
> 
> Modified 
> descriptors/src/conf/org/apache/pluto/descriptors/servlet/cast
> or-web-xml-mapping.xml
> + Changed the Distributable field to be a DistributableDD 
> object Added a 
> + the DistributableDDCastorFieldHandler to the Distributable 
> field Added 
> + the Distributable class, with its field handler 
> + DistributableCastorFieldHandler
> 
> Added 
> descriptors/src/java/org/apache/pluto/descriptors/servlet/Dist
> ributableCastorFieldHandler.java
> + Intercepts Castor access to the distributable field.  
> + Places an empty <distributable/> element in web.xml if a web-app is 
> + marked distributable
> 
> Added 
> descriptors/src/java/org/apache/pluto/descriptors/servlet/Dist
> ributableDDCastorFieldHandler.java
> + Intercepts Castor access to the DistributableDD field
> 
> Modified 
> portal/src/java/org/apache/pluto/portlet/admin/services/Deploy
> WarService.java
> + Updated the error message thrown when extractFile(String,String) 
> + obtains a null InputStream Updated addRecordsToWebXml 
> method - it now 
> + checks for elements with no bodies.  E.g. a 
> "<distributable/>" element
> 
> > <distributable> element in web.xml files produced by the 
> > descriptor/depolyer sub-projects is not valid with respect to the 
> > Servlet 2.4 xsd
> > 
> ----------------------------------------------------------------------
> > --------------------------------------------------------------------
> >
> >                 Key: PLUTO-219
> >                 URL: http://issues.apache.org/jira/browse/PLUTO-219
> >             Project: Pluto
> >          Issue Type: Bug
> >    Affects Versions: 1.0.1
> >         Environment: Apache Tomcat 5.5.15 Servlet 2.4 webapp
> >            Reporter: Elliot Metsger
> >         Assigned To: Elliot Metsger
> >             Fix For: 1.0.2
> >
> >         Attachments: PLUTO-219-01.patch
> >
> >
> > Perhaps against best practices I have a portlet that puts 
> objects into session attributes that don't implement 
> Serializable.  Normally I prevent warnings from Tomcat by 
> configuring a session manager (a <Manager> element inside a 
> <Context> container) with an empty path name.  See 
> http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#St
andard%20Implementation (look for the pathname attribute).
> > However Tomcat (at least v 5.5.15 does) seems to ignore my 
> <Manager pathname=""/> directive when the portlet's web.xml 
> has a "<distributable>" element present.  Tomcat then fires 
> off errors about placing non-serializable objects in the 
> portlet session.
> > I think the Pluto descriptors/deployer needs to put the 
> <distributable> element into a web.xml only when its required.
> 
> --
> 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
> 
>         

Reply via email to