portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: AW: [J2] Access to ComponentManager from a portlet application
Date Fri, 04 Jun 2004 17:48:31 GMT

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


Mime
View raw message