+1. I also kind of like the Portlet Service Framework of GridSphere, which they adapted from IBM WebSphere portal. They have a more formal api which also allows services between (external) portlets. GridSphere doc about it: http://www.gridsphere.org/gridsphere/docs/ReferenceGuide/ch06s01.html
As we are currently not ready to support something that fancy yet, I fully support the current proposal. Still, a services api between portlets really would be neat which I would like to see in the future as well. And, something like that might be defined in a future spec...
Scott T Weaver wrote:
+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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
