I am going to make a slight addition to the API. org.apache.jetspeed.tools.pamanager.PortletApplicationManagement will require and additional startPortletApplication method that takes a specific context path argument. This will have minimal effect on Jetspeed as a whole. org.apache.jetspeed.tools.pamanager.PortletApplicationManager will require the implemnetation of this method and org.apache.jetspeed.container.JetspeedContainerServlet will need to call it. If no "contextPath" init parameter has been defined for the org.apache.jetspeed.container.JetspeedContainerServlet, it will use "/"+contextName as the default which is basically what is happening at the moment.

This will effect effect third party implementors who have written their own implementations of PortletApplicationManagement. Fortunately, in most cases, this is a very trivial task.

Scott,

If I understand it correctly, will you implement the change to the JetspeedContainerServlet in an optional way?
Existing war files "infused" in the old way preferably should still continue to work "the old way" if possible.

BTW: did you discover how this used to be possible in the past (seemingly without api changes) but now no longer?

Yes, the servlet checks to see if the "contextPath" was provided as init parameter in the web.xml. If it was not, it will use "/"+contextName, which if you look at the original startPortletApplication method, does the exact same thing but within the method itself.

I don't think we ever fullu supported "/" for portlet apps and I am pretty sure the contextPath started being ignored early on in the 2.0 development cycle. This was fairly easy to get past as you could just change the entry in the WEB_APPLICATION table to be "/". However, it appears now that this entry gets reset every time the container starts up, at least it was for me.

I guess the entry in the WEB_APPLICATION table is reset because you modified the web.xml which triggers a reregistration (I think the web.xml changes check was added post 2.0)

Yeah, the checksum logic was an addition that wasn't in the earlier versions of 2.0 (which is what I have been using up to this point).

I merged these changes to the 2.2. trunk too now