[jira] Assigned: (PLUTO-481) Pluto 2.0 Refactoring Initiative

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLUTO-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma reassigned PLUTO-481:
-------------------------------

    Assignee: Ate Douma  (was: Dennis Dam)

> Pluto 2.0 Refactoring Initiative
> --------------------------------
>
>                 Key: PLUTO-481
>                 URL: https://issues.apache.org/jira/browse/PLUTO-481
>             Project: Pluto
>          Issue Type: Improvement
>          Components: portlet container
>            Reporter: David Sean Taylor
>            Assignee: Ate Douma
>             Fix For: 2.0.0
>
>
> 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.
> 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.
> 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.
> 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.
> 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
> 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.
> 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).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.