Hi Ate, I've just committed this by r812877. As I mentioned in the commit message, to make no side-effects, I just copied pluto's portlet 1.0 JAXB package into the new package, "o.a.j.descriptor.om.portlet10", with empty namespace annotation and added into the JAXB context in new jetspeed PortletAppDescriptorService implementation class. Now Jetspeed-2 allows some old style portlet descriptors with no namespace uri with a warning log message.
Kind regards, Woonsan --- On Thu, 9/3/09, Woonsan Ko <[email protected]> wrote: > From: Woonsan Ko <[email protected]> > Subject: Re: On the current strong validation during PA deployment > To: "Jetspeed Developers List" <[email protected]> > Date: Thursday, September 3, 2009, 10:04 AM > Hi Ate, > > Thank you very much for the valuable remarks. > I haven't try to find a solution. I will keep those in mind > when I try to improve this. I'm just guessing that we could > try one more unmarshalling without namespace awareness when > it meets a non-namespaced descriptor. I'll keep you updated > for your review. :) > > Kind regards, > > Woonsan > > --- On Thu, 9/3/09, Ate Douma <[email protected]> > wrote: > > > From: Ate Douma <[email protected]> > > Subject: Re: On the current strong validation during > PA deployment > > To: "Jetspeed Developers List" <[email protected]> > > Date: Thursday, September 3, 2009, 12:01 AM > > Hi Woonsan, > > > > +1 > > > > But be aware that because of the XSD validation > currently > > applied the Pluto based loading of the portlet.xml > might > > assume certain structures to be already ensured, e.g. > > required elements to be available. As result the > internal > > "error" handling might not be as good as expected when > a > > non-validated invalid descriptor is loaded and could > for > > instance lead to uncatched NPEs. > > > > Regards, > > > > Ate > > > > Woonsan Ko wrote: > > > Hi there, > > > > > > During testing RPAD with some useful PAs from > > jp.sf.pal repository, I found that the current > deployment > > component failed to deploy a PA because the descriptor > of > > the PA does not have any namespace uri definition with > the > > following exceptions: > > > > > > java.io.IOException: unexpected element (uri:"", > > local:"portlet-app"). Expected elements are > > <{http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd}portlet-app>,<{http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd}portlet-app> > > > > > > The portlet.xml is like the following: > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > <portlet-app id="charttest" version="1.0"> > > > <snip/> > > > </portlet-app> > > > > > > It's because PortletAppDescriptorServiceImpl of > > pluto-2.0 used by Jetspeed-2.2 is using strong > validation > > with JAXB. I think that's fair for pluto-2.0. > > > However, how about having another option to > ignore > > this kind of validation errors in Jetspeed-2.2? (Also, > I > > think this option should be the default.) It will help > using > > the existing Portlet 1.0 based PAs. > > > > > > To do this, with the new (default) option, I > think we > > need to override the PortletAppDescriptorService for > > JetspeedDescriptorService without throwing exception > > instantly on validation error, while leaving the > validation > > warnings in log files. (See javadoc of > > javax.xml.bind.Unmarshaller for detail examples.) > > > > > > What do you think? > > > > > > Regards, > > > > > > Woonsan > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
