Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Eric Dalquist]

To avoid an ever growing email I'll snip out a few bits here.

<snip>

The Pluto 1.1.x service provider interfaces (SPI)
=================================================

Although the new Pluto SPI (comprising of the RequiredContainerServices and OptionalContainerServices) generally provides a nice and simple interface to plugin portal specific implementations, certain features available with Pluto 1.0.x are no longer available. With Pluto 1.0.x, critical components as the PortletContext and PortletWindow were accessed by the container through factory classes. These no longer exist and the pluto container directly instantiates its own implementations for these components.

You can provide your own PortletWindow impl. Since all container calls require a PortletWindow (interface) all callbacks simply provide this interface back to the handling code. We definitely have a custom PortletWindow implementation that tracks more information than the Pluto interface describes.

True, but onces invoked, Pluto will nonetheless *wrap* this interface inside an instance of its own PortletWindowImpl anyway. This implementation delegates all the interface methods to the wrapped object itself, except getServletContext() and getPortletEntity() which it overrides. And these two method overrides are used to hook back into the internal container content management and descriptor registry. That's just my point: the current container simply enforces these dependencies and providing our own implementation of the PortletWindow will be useless.

Ah, so the concern is not that your original window is not available to the SPI callbacks (it is via InternalPortletWindow.getOriginalPortletWindow()) but that you can't control all methods on the PortletWindow impl that Pluto uses internally.

It does look like there is no way to provide your own PortletContext impl.

Pluto 1.1.x/2.0 container.

Jetspeed however very much depends on its own extensions of these components to provide support for features like parallel rendering, clustering and attaching additional meta data (or even preferences) to a PortletWindow or PortletEntity. Additionally, while Pluto 1.0.x allowed managing multiple PortletWindows for a PortletEntity, this *Portlet Spec* feature has been removed from the current

Again, I'm not sure the need for portlet container support for this. We use the DD objects as an easy way to know what is in the .xml objects. We then internally have our own portlet object model with a PortletDefinition (admin publishing a portlet), PortletEntity (user subscribing to portlet), PortletWindow (user viewing a portlet). Each definition can have N child entities and each entity can have N child windows. Each level in the model provides extra configuration data that we expose via the SPIs that we implement. We don't even bother with the Pluto PortletEntity interface since the only thing Pluto ever asks for is a PortletWindow.

Yeah, but what about the preferences? Pluto access the PortletWindow preferences through its *internally managed* PortletEntity. As we have no control here, we can't put our own preferences extensions (like defined on PSML page level for instance) in place either.

There is the PortletPreferencesService. We have a custom implementation that for the getStoredPreferences call collates the preferences from the DD, our definition object and our entity object into a single preferences view for the portlet. The store call does the work of determining what has changed and what to store where. We have a layered preference architecture that allows publishers to define preferences that are layered on top of the descriptor preferences in addition to the standard runtime preferences that are scoped to users.

and thereby cannot be regarded as a proper SPI interface anymore.

Lastly, not all of services referenced through these SPI interfaces are only accessed through it. For instance, the OptionalContainerService.getPortletRegistryService() is by default implemented by the PortletContextManager. But, this implementation is very much directly used (as static instance even) within the container. Effectively, the interface is now only an API portals might use, but it cannot be replaced

This seems like a pretty big bug. While we didn't have a need for it I can very much see where moving the descriptor service behind a true SPI to allow implementers to write their own if they want would be a good thing.

Thanks for your view. Although you might not need it now, that can change in the future.

Having this fixed will help us all.

Solution
========

maintains backwards compatibility for current Pluto 1.1.x users.


- refactor the container implementation to only use the OM interfaces

As indicated earlier, solving the above issues such that Pluto 2.0 can be made embeddable again, in Jetspeed or other portals, needs to be done in a way which Although we don't have a clear proposal for this, our current idea is to: - define new OM interfaces to be implemented by the current descriptor api classes - enhance the OptionalContainerServices SPI to provide additional services for loading and managing the deployment descriptors - enhance the OptionalContainerServices SPI to provide additional services for accessing components like PortletContext, PortletWindow etc. - refactor the container implementation to only use the SPI provided services and no longer directly binding to its service implementations

These all seem like great solutions and it seems to me they could be done with very minor changes required of people that have already implemented 1.1

That's the goal!

Reviewing this proposal and monitoring and checking the changes onces we start performing them is and will be very helpful.

Glad we can help.

-Eric

smime.p7s
Description: S/MIME Cryptographic Signature