You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David Sean Taylor (JIRA)" <ji...@apache.org> on 2008/04/09 20:21:24 UTC
[jira] Created: (PLUTO-481) Pluto 2.0 Refactoring Initiative
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: Dennis Dam
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.
[jira] Resolved: (PLUTO-481) Pluto 2.0 Refactoring Initiative
Posted by "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 resolved PLUTO-481.
-----------------------------
Resolution: Fixed
The big refactoring is over!
While there are plenty of features which need "improvement" and of course lots of other cleanup/fixing issues, we've *have* Pluto 2 now again embedded within Jetspeed!
And, there are a few minor TCK 2.0 issues open as well, introduced by changes on the trunk before this refactoring, the refactoring branch actually is already more compliant than the trunk itself.
So, we're calling this task which was primarily targeted at getting Pluto embeddable again for other portals, and Jetspeed specifically, as *finished*.
I'll send out a vote to the list shortly for the next step: promoting this branch as the new trunk!
The current trunk can then be stored away as a pre-2.0-refactoring-trunk-merge branch.
> 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.
Re: [jira] Created: (PLUTO-481) Pluto 2.0 Refactoring Initiative
Posted by Ate Douma <at...@douma.nu>.
Hi Craig,
Yes: please do apply fixes/patches to both the trunk and the branch.
If all goes well and the branch works out as we intend it to be, the easiest way of "merging" back would be to swap out
the trunk with the branch itself.
So, yes, we'd like to keep the branch in sync with trunk changes to be able to so that.
Regards,
Ate
CDoremus@hannaford.com wrote:
>
> David,
> Thanks to you and Ate for taking the lead on this effort. I'm sure the
> result will be a better Pluto and Jetspeed product. Unfortunately, other
> commitments won't allow me to contribute a large block of time to help this
> effort, but I'd like to chip in when I have the time.
>
> In particular, I'd like to help apply some of the patches that our users
> supply from time to time like the ones that Mike Freeman just contributed.
> Should they be applied to both the trunk and 2.0-spi-refactoring branch?
> Please advise.
> /Craig
>
>
>
>
>
>
> "David Sean
> Taylor (JIRA)"
> <ji...@apache.org> To
> pluto-dev@portals.apache.org
> 04/09/2008 02:21 cc
> PM
> Subject
> [jira] Created: (PLUTO-481) Pluto
> Please respond to 2.0 Refactoring Initiative
> pluto-dev@portals
> .apache.org
>
>
>
>
>
>
>
>
> 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: Dennis Dam
> 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.
>
>
>
>
Re: [jira] Created: (PLUTO-481) Pluto 2.0 Refactoring Initiative
Posted by CD...@hannaford.com.
David,
Thanks to you and Ate for taking the lead on this effort. I'm sure the
result will be a better Pluto and Jetspeed product. Unfortunately, other
commitments won't allow me to contribute a large block of time to help this
effort, but I'd like to chip in when I have the time.
In particular, I'd like to help apply some of the patches that our users
supply from time to time like the ones that Mike Freeman just contributed.
Should they be applied to both the trunk and 2.0-spi-refactoring branch?
Please advise.
/Craig
"David Sean
Taylor (JIRA)"
<ji...@apache.org> To
pluto-dev@portals.apache.org
04/09/2008 02:21 cc
PM
Subject
[jira] Created: (PLUTO-481) Pluto
Please respond to 2.0 Refactoring Initiative
pluto-dev@portals
.apache.org
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: Dennis Dam
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.
[jira] Assigned: (PLUTO-481) Pluto 2.0 Refactoring Initiative
Posted by "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.
[jira] Commented: (PLUTO-481) Pluto 2.0 Refactoring Initiative
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637730#action_12637730 ]
Ate Douma commented on PLUTO-481:
---------------------------------
David Taylor and myself will start working on this issue again shortly, in coordination with the work on Jetspeed JIRA issue JS2-871.
We have been working very hard the last weeks on a major refactoring for Jetspeed 2.2, completely replacing our security model and our security attributes and portlet preferences back end.
Now, we're finally ready to make the deep dive and start on the way overdue upgrade to Pluto 2.0.
For that, there is still very much to do of course, both on the Pluto and Jetspeed side.
We will try working on this max. time, together with the help of other Jetspeed committers too (Dennis, Woonsan, Vivek).
Our current goal is to have this completed and properly working for both Pluto and Jetspeed *before* ApacheCon US 2008!
Its going to be a tight schedule for sure, but given enough time, help and *lots* of good luck, we are definitely going to try.
And maybe, just maybe, we'll then even be able to announce a *release* of both Pluto 2.0 and Jetspeed 2.2 together at the ApacheCon...
> 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.