portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Dalquist <eric.dalqu...@doit.wisc.edu>
Subject Re: Embeddable Pluto 2.0 container for Jetspeed-2
Date Tue, 12 Feb 2008 12:37:32 GMT

To introduce myself I'm a developer on the uPortal project and was one 
of the people involved in upgrading from Pluto 1.0.1 to 1.1. I will say 
up front it was a fair bit of work. We essentially removed the 1.0 
support code and wrote the 1.1 support code from scratch. The result was 
a smaller amount of code required in uPortal to make use of Pluto 1.1 
with no loss in functionality and actually a gain in functionality in 
many places. I have more comments in-line.

Ate Douma wrote:
> Dear committers, community,
> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
> but we want and need to upgrade and migrate to the latest Pluto 
> container under
> development, aka the not yet released Pluto 2.0 targeted as the 
> JSR-286 RI.
> This however is currently impossible to do because of the 
> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
> Technically, viewed from the POV of an easy to embed container for the 
> Pluto Portal Driver, or environments which only need the 
> out-of-the-box features
> provided, these architectural changes have resulted in a much simpler 
> and easier to understand and maintain model and API, and as such these 
> changes were great!
> But... for a portal like Jetspeed-2, which provides a much enhanced 
> usage and feature list *on container level*, these architectural 
> changes have, simply put,
> completely broken with the functional and technical "contract" 
> provided by Pluto 1.0.x and as such make it now impossible for us to 
> migrate to the current Pluto
> container.
> As it is the primary mission and goal of the Pluto project to provide 
> an embeddable portlet container for portals like its Apache Portals 
> sibling project
> Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to 
> discuss what needs and can to be done, on both Jetspeed-2 and Pluto 
> side, to bring our
> projects back together, and how to restore the original *functional* 
> contract Pluto provided with version 1.0.x.
> To this end, we'll present our (short) assessment how the current 
> Pluto container API and implementation has changed and broken with the 
> old Pluto 1.0.x
> features which Jetspeed-2 depends upon to be able to maintain our 
> current Jetspeed-2 features, as well as what we think needs to be done 
> *functionally* to
> restore these features.
> To be very clear: we're not asking nor suggesting to restore the old 
> Pluto 1.0.x API and SPI as is. We fully expect and are willing to 
> adapt Jetspeed-2 to the
> new Pluto architecture as much as needed, even while that most likely 
> will now cause Jetspeed-2 itself to have to break with its own public 
> API and thus lose
> (some) backwards compatibility. After all, Pluto now has had several 
> releases based on its new Pluto 1.1.x architecture and we (as Apache 
> Portals community)
> have the obligation to maintain as much backwards compatibility for 
> the users of these versions as well.
> So, what we will propose later on is to work towards a solution which 
> will restore the ability for Jetspeed to properly use and embed the 
> new Pluto 2.0
> container but still maintain the lightweight and simple configuration 
> and usage of the container for portals like the Pluto Portal Driver 
> and other use-cases
> without breaking its current "contract".
> But first lets get down to some of the issues we have identified so 
> far. This is most likely not the complete list but covers the most 
> important ones.
> The Pluto 1.0.x object model API (OM)
> =====================================
> Pluto 1.0.x provided a fully interface based object model to represent 
> the web and portlet deployment descriptors (web.xml and portlet.xml).
> Through factory methods, the Pluto 1.0.x container only used these 
> interfaces in its implementation. That allowed Jetspeed and other 
> portals to supply its own
> implementation of the OM and use that to provide enhanced features 
> like database persistence, extended meta data, caching control, etc.
> Of course, Pluto 1.0.x also provided its own implementation classes of 
> the OM and Jetspeed uses these as base classes but provides extended 
> implementations to
> hook them up and into its own backend and management features.
> Pluto 1.1.x completely dropped all of this. Instead, a new descriptor 
> API was provided with a complete new set of classes (no interfaces!) 
> which are used and
> instantiated directly within the container with no factory support or 
> any other way of extending the current implementation.
> As such, the current container only allows usage of the web.xml and 
> portlet.xml descriptors and features derived from them as provided by 
> the container.
> Furthermore, as the loading and management of the descriptors is now 
> done directly (and only) by the container itself, there is no way for 
> Jetspeed to hook into
> this process anymore.
> Effectively, this means that descriptor persistence, caching, custom 
> extensions, *standard* support for custom portlet mode or window-state 
> mapping,
> etc. all no longer are possible with the current Pluto container. Not 
> just for Jetspeed but any portal needing and depending on these features.
We use make both custom portlet modes and window states available to 
deployed portlets and this functions as expected in Pluto 1.1, the 
descriptor objects provide information about which custom modes and 
states the portlet has declared.
> The Pluto 1.1.x/2.0 PortletContextManager, PortletDescriptorRegistry 
> and PortletServlet
> =======================================================================================

> With the switch to Pluto 1.1.x, the container added control and 
> management of the above mentioned deployment descriptors and fully 
> integrated them with the
> container interaction which now depend on this management 
> *implementation*, and also hooked that up on the portlet application 
> context.
> This means that now you need a separate container instance for each 
> portlet application and that the container itself loads and manages 
> the descriptors.
> Also, interaction with the container now requires the use of the Pluto 
> provided PortletServlet (although that one possibly can be extended) 
> as it is tied to the
> PortletContextManager directly (which in turn is tied to the 
> PortletDescriptorRegistry).
> Besides the obvious problem that this effectively blocks delegating 
> management of the context and descriptors for the portal, it also 
> forces the usage and
> interaction with portlets to the Pluto provided implementation.
> For instance, Pluto delegates interaction to each portlet through a 
> separate instance of its PortletServlet, while Jetspeed currently has 
> its own more generic
> JetspeedContainerServlet which is not tied to a single portlet. The 
> Jetspeed solution allows for dynamically enabling/adding portlets (as 
> defined in
> portlet.xml) without any need to rewrite the web.xml. But using the 
> Pluto PortletServlet requires changing the web.xml (and thus reloading 
> the context) to do so.
> 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. It does look like there is no way to provide your 
own PortletContext impl.
> 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
> Pluto 1.1.x/2.0 container.
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.
> 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
> and thereby cannot be regarded as a proper SPI interface anymore.
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.
> Solution
> ========
> 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
> maintains backwards compatibility for current Pluto 1.1.x users.
> 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 OM interfaces
> - 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
> When done properly, the above changes should still allow using the 
> current implementation without any functional or even technical 
> consequence.
> Now, the above changes will mean a lot of work and lots of testing as 
> well to make sure everything remains working as expected.
> We, as primary Jetspeed committers have much at stake here so we are 
> definitely willing to help out and do much of the grunt work.
> And of course, we will have a large amount of work to do at Jetspeed 
> Portal side as well: all our Pluto Factory implementations have become 
> useless, all Pluto
> OM packages (and some interfaces) have changed, and we will need to 
> provide new implementations for the Pluto SPI container services.
We (uPortal Developers) can also be involved in this process to provide 
the perspective of another portal that does quite a bit with hooks into 
Pluto though it sounds like we do less than Jetspeed does.
> For our implementations of the Pluto SPI container services, we will 
> definitely look at the current Pluto provided implementations and 
> where possible try to
> make use of them as much as possible. To that end, we will probably 
> also need to be able to hook in our own extensions which might require 
> some additional
> refactoring but should not result in functional or technical changes 
> of the default Pluto services.
> Note: we want to migrate to Pluto 2.0 for our next Jetspeed 2.2 
> release. But, for that release we'll stick to only using the JSR-168 
> container features.
> Then, for the following major release, version 2.3 which we currently 
> have scheduled sometime this summer, we will provide full JSR-286 
> compliance.
> So, our initial goal is to get Pluto 2.0 working again with Jetspeed-2 
> but stick to our current features.
> This all is clearly not something which can be done or will be ready 
> overnight, nor possible to do all by ourselves.
> But we do need to start resolving this ASAP so it won't hold up the 
> release of both Pluto 2.0 and Jetspeed 2.2 longer than needed.
> As said: the above proposal is still just an idea. And of course how 
> to do all this, is fully open for debate and we are very interested in 
> hearing the opinions
> of other committers and community members (also from other portals 
> embedding Pluto 1.1.x).
> So please, provide feedback and ideas how to solve these issues. And 
> suggestions for alternative solutions will very much appreciated too!
This sounds like a great proposal. As I've said above uPortal has 
already gone through the pain (and yes there was some pain) of moving to 
Pluto 1.1 but the simplification of our portlet support code was more 
than worth it along with putting us in a position to more easily (we 
hope) move to Pluto 2.0. I would be more than happy to talk about the 
approaches uPortal has taken with using Pluto 1.1 and be involved with 
discussions about these upcoming changes to Pluto 1.1 to make it as 
useful as possible for other portals as well.
> With kind regards,
> Dennis Dam
> David Sean Taylor
> Ate Douma

View raw message