You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2005/05/17 16:48:09 UTC
[jira] Created: (JS2-260) Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper
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
Assigned to: 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
[jira] Commented: (JS2-260) Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-260?page=comments#action_65606 ]
Ate Douma commented on JS2-260:
-------------------------------
I've already committed my changes to the M3_preparation branch.
Will do the same to the CVS-HEAD later this evening.
> 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
[jira] Resolved: (JS2-260) Removing dependency on Pluto PortletContainerServices and providing a JetspeedNamespaceMapper
Posted by "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