Minor Description
In my pursuit of fixing the parallel rendering problem (http://issues.apache.org/jira/browse/JS2-226)
I found out we use PortletContainerServices.prepare("jetspeed") calls several times in the PortletRendererImpl.
This method "prepares" the Pluto PortletContainer by putting the named ("jetspeed") container and its environment in a Stack in a ThreadLocal.
This is required by Pluto before the container and/or its services can be accessed.
For "normal" container interaction this need not be done by the portal as Pluto does so itself.
But, if you want/need to access its services independently outside a container invocation this preparation must be done otherwise Pluto will throw an exception.
Because Pluto maintains the current "container" context in a ThreadLocal Stack, after using the services they
should be "released" again.
But, although the services are "prepared" several times, they are never "released", resulting in a useless
filling of the Stack with the same context.
After looking into this more deeply, I discovered the reason why we prepare the PortletContainerServices:
to be able to get to the NamespaceMapper from Pluto (using NamespaceAccessor.getNamespaceMapper()).
As Jetspeed itself provides the NamespaceMapper to use by Pluto I find it odd why we should need to use the
Pluto PortletContainerServices to get back at it.
Furthermore, we currently use the NamespaceMapper of Pluto which itself uses the hardcoded "Pluto_" prefix.
Also, I found we have our own NamespaceMapper (in commons) but that is not used yet (nor does it implement
the NamespaceMapper interface).
As I liked to remove the unneeded (and incomplete) usage of the PortletContainerServices, I decided to
provide a complete and configurable implementation of the NamespaceMapper: the JetspeedNamespaceMapper.
This (interface) extension of the Pluto NamespaceMapper provides the option to specify our own prefix.
Default, this now is "js_", but it can be configured (even back to "Pluto_" if you want) through the spring context.
I moved our old NamespaceMapper from the commons subproject to a new JetspeedNamespaceMapperImpl under the
portal subproject keeping the package org.apache.jetspeed.container.namespace, and also implemented the
Pluto NamespaceMapper interface.
As our own JetspeedNamespaceMapper now is a true spring component, I replaced the
NamespaceAccessor.getNamespaceMapper() calls by getting the JetspeedNamespaceMapperFactory from the spring ComponentManager.
As result, the need to call PortletContainerServices.prepare("jetspeed") is now gone and I subsequently
removed those as well.
This doesn't solve yet the parallel rendering problem but at least the container interactions are cleaner
now.