+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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
******************************************
* Scott T. Weaver *
* <[EMAIL PROTECTED]> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
