[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
