+1, I like the design proposed below.
--- David Sean Taylor <[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
