[jira] Resolved: (JS2-260) Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper

["Ate Douma (JIRA)" <je...@portals.apache.org>]

     [ http://issues.apache.org/jira/browse/JS2-260?page=all ]
     
Ate Douma resolved JS2-260:
---------------------------

    Resolution: Fixed

> Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper
> ---------------------------------------------------------------------------------------------
>
>          Key: JS2-260
>          URL: http://issues.apache.org/jira/browse/JS2-260
>      Project: Jetspeed 2
>         Type: Improvement
>   Components: Container
>     Versions: 2.0-M2
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>     Priority: Minor
>      Fix For: 2.0-M3, 2.0-FINAL

>
> 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.

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org