[
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.
