You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by CD...@hannaford.com on 2006/04/14 23:50:36 UTC

Moving toward a Pluto 1.1 beta release

I'm hoping to be able to put in some time in the next week to cut a Pluto 
1.1 beta1 release, which is long overdue. I created an Ant build 
(dist-build.xml) for bundling up a binary and source release, so I am 
running out of excuses! 

I also created a wiki page to guide the release process: 
http://wiki.apache.org/portals/Pluto/PlutoRelease110Beta1.

There appears to be no show-stopper bugs to block this release, but, hey, 
it's only a beta! I thank Zheng for running the code through the JSR-168 
TCK, where he reports that Pluto 1.1 passes all tests. Nice job!

If there are any objections, please let me know, and stay tuned and I'll 
let you all know when a 'test' build is up.

TIA
/Craig

Re: Moving toward a Pluto 1.1 beta release

Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> CDoremus@hannaford.com schrieb:
>> Thank you, Carsten, for helping out. I will update the source
>> distributions and the release plan.
>>
>> BTW, is there a Maven goal that adds the license header?
> I don't think so - I did it manually. I think there are still some files
> without
> the correct header: some html files (package.html) and the apt docs.
> I can add the header there in the next days if noone beats me to it.
> 
I just added the last missing headers - I hope I did not oversee any file.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Moving toward a Pluto 1.1 beta release

Posted by Carsten Ziegeler <cz...@apache.org>.
CDoremus@hannaford.com schrieb:
> 
> Thank you, Carsten, for helping out. I will update the source
> distributions and the release plan.
> 
> BTW, is there a Maven goal that adds the license header?
I don't think so - I did it manually. I think there are still some files
without
the correct header: some html files (package.html) and the apt docs.
I can add the header there in the next days if noone beats me to it.

Carsten

Re: Moving toward a Pluto 1.1 beta release

Posted by CD...@hannaford.com.
Thank you, Carsten, for helping out. I will update the source 
distributions and the release plan.

BTW, is there a Maven goal that adds the license header?
/Craig




Carsten Ziegeler <cz...@apache.org> 
04/21/2006 05:51 AM
Please respond to
pluto-dev@portals.apache.org


To
pluto-dev@portals.apache.org
cc

Subject
Re: Moving toward a Pluto 1.1 beta release






I wasn't able to test that version directly, but for a proper release
(even a beta release) we need a license header at the top of each file.

I just added the missing header to some files.

Carsten

CDoremus@hannaford.com wrote:
> 
> I'm hoping to be able to put in some time in the next week to cut a
> Pluto 1.1 beta1 release, which is long overdue. I created an Ant build
> (dist-build.xml) for bundling up a binary and source release, so I am
> running out of excuses!
> 
> I also created a wiki page to guide the release process:
> http://wiki.apache.org/portals/Pluto/PlutoRelease110Beta1.
> 
> There appears to be no show-stopper bugs to block this release, but,
> hey, it's only a beta! I thank Zheng for running the code through the
> JSR-168 TCK, where he reports that Pluto 1.1 passes all tests. Nice job!
> 
> If there are any objections, please let me know, and stay tuned and I'll
> let you all know when a 'test' build is up.
> 
> TIA
> /Craig


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/


Re: Moving toward a Pluto 1.1 beta release

Posted by Carsten Ziegeler <cz...@apache.org>.
I wasn't able to test that version directly, but for a proper release
(even a beta release) we need a license header at the top of each file.

I just added the missing header to some files.

Carsten

CDoremus@hannaford.com wrote:
> 
> I'm hoping to be able to put in some time in the next week to cut a
> Pluto 1.1 beta1 release, which is long overdue. I created an Ant build
> (dist-build.xml) for bundling up a binary and source release, so I am
> running out of excuses!
> 
> I also created a wiki page to guide the release process:
> http://wiki.apache.org/portals/Pluto/PlutoRelease110Beta1.
> 
> There appears to be no show-stopper bugs to block this release, but,
> hey, it's only a beta! I thank Zheng for running the code through the
> JSR-168 TCK, where he reports that Pluto 1.1 passes all tests. Nice job!
> 
> If there are any objections, please let me know, and stay tuned and I'll
> let you all know when a 'test' build is up.
> 
> TIA
> /Craig


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: Castor and XML namespaces (was Moving toward a Pluto 1.1 beta releas

Posted by Elliot Metsger <em...@jhu.edu>.

Elliot Metsger wrote:
> 
> I finally figured out that if you feed Castor a servlet 2.4 xml with a
> default namespace, the mapping fails, but if you feed it one with a null
> namespace, it works.
> 

Ah - this behavior appears to be governed by the
"org.exolab.castor.parser.namespaces" property in
portal/webapp/WEB-INF/classes/castor.properties.

By default the property is false, but for the portal subproject it is true. 
This results in failed deployment of portlets using a 2.4 servlet descriptor
using the admin portlet, but the same portlet would deploy just fine (with
PLUTO-216 applied) using the descriptors project (maven deploy goal).

So I'll investigate the ramifications of switching the
"org.exolab.castor.parser.namespaces" property to "false" for the portal
subproject, either programatically or via the properties file.  

I'm not sure what the list thinks about this - any thoughts on switching
this property value to false for pluto 1.0.2?  If it is too big or risky
change, I could write up some documentation for the website for the eventual
1.0.2 maintenance release.

Thanks,
Elliot

-- 
View this message in context: http://www.nabble.com/Moving-toward-a-Pluto-1.1-beta-release-tf1451971.html#a5533949
Sent from the Pluto - Dev forum at Nabble.com.


Castor and XML namespaces (was Moving toward a Pluto 1.1 beta release)

Posted by Elliot Metsger <em...@jhu.edu>.
Craig,

Thanks for the hints below.  I did have to update
DeployWarService.updateWebXml() for PLUTO-219 (distributable handling), but
for PLUTO-216 the problem is related to how Castor deals with namespaces
when unmarshalling (I don't know perhaps after I get past this immediate
issue with Castor I'll need to take another look at
DeployWarService.updateWebXml() if additional elements have been added as
you noted below)

Just to backtrack a second/refresh - the problem that I'm trying to solve is
that you get an NPE when attempting to deploy a portlet using a servlet 2.4
webapp with the admin portlet:
SEVERE: Error in Portlet
java.lang.NullPointerException
        at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:109)
        at
org.apache.pluto.invoker.impl.PortletInvokerImpl.load(PortletInvokerImpl.java:80)
        at
org.apache.pluto.PortletContainerImpl.portletLoad(PortletContainerImpl.java:218)

This occurs because Castor doesn't map the servlet or servletMapping fields
of WebApplicationDefinitionImpl (in
PortletDefinitionRegistryServiceContextImpl.loadApplicationDefinition) when
unmarshalling a servlet 2.4 xml.

I finally figured out that if you feed Castor a servlet 2.4 xml with a
default namespace, the mapping fails, but if you feed it one with a null
namespace, it works.

So when I upload a portlet with a servlet descriptor like:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" 
    version="2.4">
        <display-name>Servlet 2.4 Webapp</display-name>
        <description>A 2.4 Servlet</description>    
</web-app>

the mapping fails and I get the NPE.  If I use 
<web-app version="2.4">
        <display-name>Servlet 2.4 Webapp</display-name>
        <description>A 2.4 Servlet</description>    
</web-app>

I get past the NPE and my hello world renders.  I suspect the same issue
will apply when deploying portlets from the command line using the
descriptors sub-project.

I'll dig into Castor and their list archives and see if there's an easy
solution.  Thanks again for the pointers,

Elliot



 


CDoremus wrote:
> 
> Hi Elliot,
> 
> I thought that there would be a problem.  There might be a problem in 
> DeployWarService.updateWebXml(), which
> adds the PortletServlet info to web.xml. In doing so, it makes sure that 
> the servlet and servlet-mapping elements for PortletServlet are placed in 
> the proper order, which requires that it iterate through every element 
> web.xml before servlet or servlet-mapping. There might be a problem if 
> there are new elements in the servlet 2.4 spec. So take a look to see 
> whether the PortletServlet elements got added properly. If there are other 
> issues, please let me know.
> 
> TIA
> /Craig
> 
> 
> 
> 
> 
> Elliot Metsger <em...@jhu.edu> 
> 04/19/2006 10:14 AM
> Please respond to
> pluto-dev@portals.apache.org
> 
> 
> To
> pluto-dev@portals.apache.org
> cc
> 
> Subject
> Re: Moving toward a Pluto 1.1 beta release
> 
> 
> 
> 
> 
> 
> Elliot Metsger wrote:
>> Hi Craig,
>> 
>> I'll perform both tests below; I totally understand the prioritation - 
>> no problem there :-)  I'll report back.
> 
> Definitly a problem which manifests itself in the Pluto Portal invoker 
> when deploying a 2.4 servlet via the admin portlet app.  I'm digging...
> 
> 
>> Elliot
>> 
>> CDoremus@hannaford.com wrote:
>> 
>>> Hi Elliot,
>>>
>>> Thanks for the update on your patches to Pluto 1.0.1. Right now I am 
>>> concentrating on getting Pluto 1.1-beta1 out the door.
>>>
>>> I hope to get to your applying your patches to the 1.0.2 branch, but 
>>> that is not a big priority right now.  One thing that I am concerned 
>>> about is how your patch effects the Admin Portlets in Pluto 1.0.1. 
>>> Have you tested this? If not, can you test an Admin Portlet deployment 
>>> with 1). A portlet bundled with a Servlet 2.3 compliant web.xml and 
>>> 2). A portlet bundled with a Servlet 2.4 compliant web.xml?
>>>
>>> TIA
>>> /Craig
> 
> <snip>
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/Moving-toward-a-Pluto-1.1-beta-release-tf1451971.html#a5514504
Sent from the Pluto - Dev forum at Nabble.com.