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. Regards, Artem. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
