portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Resolved: (JS2-260) Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper
Date Wed, 18 May 2005 18:48:55 GMT
     [ 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:
For more information on JIRA, see:

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

View raw message