portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: AW: [J2] Access to ComponentManager from a portlet application
Date Fri, 04 Jun 2004 18:19:30 GMT
+1, I like the design proposed below.

--- David Sean Taylor <david@bluesunrise.com> 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
> 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

---------------------------------------------------------------------
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