portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: AW: [J2] Access to ComponentManager from a portlet application
Date Fri, 04 Jun 2004 18:57:40 GMT
+1.
I also kind of like the Portlet Service Framework of GridSphere, which they adapted from IBM
WebSphere portal.
They have a more formal api which also allows services between (external) portlets.
GridSphere doc about it: http://www.gridsphere.org/gridsphere/docs/ReferenceGuide/ch06s01.html

As we are currently not ready to support something that fancy yet, I fully support the current
proposal.
Still, a services api between portlets really would be neat which I would like to see in the
future as well.
And, something like that might be defined in a future spec...

Scott T Weaver wrote:
> +1.  Well, thought out approach that is very simple.
> 
> On Fri, 2004-06-04 at 13:48, David Sean Taylor wrote:
> 
>>On Jun 4, 2004, at 1:55 AM, Grinshtein, Artem wrote:
>>
>>
>>>David Sean Taylor wrote:
>>>
>>>
>>>>We need to agree that having portlet applications with
>>>>knowledge of and
>>>>access to the portal implementation is a good thing.
>>>>For one thing, that PA is not portable.
>>>>
>>>>A second approach is to store all Jetspeed-specific portlets in the
>>>>'jetspeed' PA.
>>>>The jetspeed web application is also a portlet application.
>>>>The two PAM portlets run inside the Jetspeed 'portlet application'.
>>>
>>>If PAM portlets will be implemented as Struts-portlets, the jetspeed 
>>>web
>>>application has to provide struts-specific configuration and libraries.
>>>In this case has the jetspeed WA additionally dependencies
>>>and becomes too complex.
>>>
>>>
>>>>I think there is a good argument for supporting Jetspeed-specific PAs.
>>>>For example, to replace your PAM PA or JetspeedUserManagement
>>>>PA, just
>>>>swap undeploy the old jar and deploy the new.
>>>>So if we were to support this scenario, how does the PA get access to
>>>>Jetspeed public components such as the Registry component?
>>>>My original intent for CPS "Common Portlet Services" - was to support
>>>>just that.
>>>>Im also thinking of a JNDI-type lookup, although we will
>>>>still need to
>>>>resolve class loader issues.
>>>
>>>We can declare all CPSs that a Jetspeed-specific PA needs in 
>>>jetspeed-portlet.xml
>>>(similarly too user attributes in portlet.xml). The declared services 
>>>can be placed
>>>to the portlet context (in a picocontainer?) by initializing of the PA.
>>>This approach has the advantage that a portal admin/deployer has an 
>>>overview which CPSs are necessary for PAs and it's possible to check 
>>>by deploying of a PA whether the CPSs are available.
>>>
>>
>>I like this. Here is a quick prototype, just to make sure we are in 
>>agreement. Please comment and modify:
>>
>>jetspeed-portlet.xml:
>>
>><portlet-app id="PAM"
>>....
>>     <services>
>>           <service name='PortletRegistryComponent'/>
>>           <service name='PortletEntityAccessComponent'/>
>>     </services>
>>....
>>
>>The portlet would retrieve the component  via the PortletContext:
>>
>>
>>PortletRegistryComponent registry = 
>>portletContext.getAttribute("cps:PortletRegistryComponent");
>>
>>Only services defined in the descriptor are allowed to be located.
>>If a service is specified in the descriptor, and it does not exist in 
>>the portal, the the portlet will fail on deployment.
>>The service name is the name of the component in Jetspeed Pico 
>>container. (We could have an internal mapping to abstract from the 
>>component names).
>>The portal only needs to compile against the jetspeed-api jar
>>NOTE: I don't currently see the registry API in the jetspeed-api, the 
>>API will need to be decoupled from the component.
>>
>>If  we agree on the above, I will create JIRA issues to:
>>
>>1. enhance jetspeed-portlet.xml to support services
>>2. enhance the deployer to validate services
>>3. implement PortletContext.getAttribute
>>4. move the PAM portlets back into the PAM PA
>>5. start a new PA, User Info Manager PA (your original proposal)
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


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


Mime
View raw message