Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Dear committers, community,

Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, but we want and need to upgrade and migrate to the latest Pluto container under
development, aka the not yet released Pluto 2.0 targeted as the JSR-286 RI.

This however is currently impossible to do because of the architectural changes Pluto underwent from version 1.0.x to 1.1.x.

Technically, viewed from the POV of an easy to embed container for the Pluto Portal Driver, or environments which only need the out-of-the-box features
provided, these architectural changes have resulted in a much simpler and easier to understand and maintain model and API, and as such these changes were great!

But... for a portal like Jetspeed-2, which provides a much enhanced usage and feature list *on container level*, these architectural changes have, simply put,
completely broken with the functional and technical "contract" provided by Pluto 1.0.x and as such make it now impossible for us to migrate to the current Pluto
container.

As it is the primary mission and goal of the Pluto project to provide an embeddable portlet container for portals like its Apache Portals sibling project
Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to discuss what needs and can to be done, on both Jetspeed-2 and Pluto side, to bring our
projects back together, and how to restore the original *functional* contract Pluto provided with version 1.0.x.

To this end, we'll present our (short) assessment how the current Pluto container API and implementation has changed and broken with the old Pluto 1.0.x
features which Jetspeed-2 depends upon to be able to maintain our current Jetspeed-2 features, as well as what we think needs to be done *functionally* to
restore these features.

To be very clear: we're not asking nor suggesting to restore the old Pluto 1.0.x API and SPI as is. We fully expect and are willing to adapt Jetspeed-2 to the
new Pluto architecture as much as needed, even while that most likely will now cause Jetspeed-2 itself to have to break with its own public API and thus lose
(some) backwards compatibility. After all, Pluto now has had several releases based on its new Pluto 1.1.x architecture and we (as Apache Portals community)
have the obligation to maintain as much backwards compatibility for the users of these versions as well.

So, what we will propose later on is to work towards a solution which will restore the ability for Jetspeed to properly use and embed the new Pluto 2.0
container but still maintain the lightweight and simple configuration and usage of the container for portals like the Pluto Portal Driver and other use-cases
without breaking its current "contract".

But first lets get down to some of the issues we have identified so far. This is most likely not the complete list but covers the most important ones.

The Pluto 1.0.x object model API (OM)
=====================================
Pluto 1.0.x provided a fully interface based object model to represent the web and portlet deployment descriptors (web.xml and portlet.xml).
Through factory methods, the Pluto 1.0.x container only used these interfaces in its implementation. That allowed Jetspeed and other portals to supply its own
implementation of the OM and use that to provide enhanced features like database persistence, extended meta data, caching control, etc.
Of course, Pluto 1.0.x also provided its own implementation classes of the OM and Jetspeed uses these as base classes but provides extended implementations to
hook them up and into its own backend and management features.

Pluto 1.1.x completely dropped all of this. Instead, a new descriptor API was provided with a complete new set of classes (no interfaces!) which are used and
instantiated directly within the container with no factory support or any other way of extending the current implementation.
As such, the current container only allows usage of the web.xml and portlet.xml descriptors and features derived from them as provided by the container.
Furthermore, as the loading and management of the descriptors is now done directly (and only) by the container itself, there is no way for Jetspeed to hook into
this process anymore.

Effectively, this means that descriptor persistence, caching, custom extensions, *standard* support for custom portlet mode or window-state mapping,
etc. all no longer are possible with the current Pluto container. Not just for Jetspeed but any portal needing and depending on these features.

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

So please, provide feedback and ideas how to solve these issues. And suggestions for alternative solutions will very much appreciated too!

With kind regards,

Dennis Dam
David Sean Taylor
Ate Douma

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Carsten,

Thanks for your comments and the heads-up.

So it looks Cocoon portal is very much in the same situation as Jetspeed-2 here.

About the compatibility to 1.1.x, see my response to David Jencks: I still consider it to be important enough to at least do our best to maintain.

Regards,

Ate

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

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Carsten Ziegeler <cz...@apache.org>]

Some time ago I tried upgrading the Cocoon portal to Pluto 1.1.x but as 
everything is different compared to 1.0.1 I simply stopped the migration.

Without going into all the details the proposed changes sound very good 
to me. Cocoon uses its own OM classes and own servlet for calling 
portlets as well, so these seem to be substantial requirements.

I don't think that we really need to care that much about compatibility 
to 1.1.x - it's a 2.0 version :) Of course we should try to be as 
compatible as possible.

I haven't done anything with Pluto for a long time, the only code base I 
know is 1.0.x :(

Carsten

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


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Oops, I made one mistake in my previous response:

<snip/>

>> What about Jetspeed providing its own "PortletServlet" implementation. 
>> The portlet servlet is pretty simple, initing the portlet, fixing up 
>> the request and response and dispatching to the container. 
> Of course, we could even extend the Pluto PortletServlet for that end.
> The problem is though, the current Pluto PortletServlet is completely 
> tied to the concrete PortalAdministrationService and PortletContextManager.
> And as the container itself also requires the usage of these classes 
> (not interfaces) there is no point (yet) to do so.

Above I meant PortletDescriptorRegistry, not PortalAdministrationService.

Sorry about this.

Regards,

Ate

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Oops, I made one mistake in my previous response:

<snip/>

>> What about Jetspeed providing its own "PortletServlet" implementation. 
>> The portlet servlet is pretty simple, initing the portlet, fixing up 
>> the request and response and dispatching to the container. 
> Of course, we could even extend the Pluto PortletServlet for that end.
> The problem is though, the current Pluto PortletServlet is completely 
> tied to the concrete PortalAdministrationService and PortletContextManager.
> And as the container itself also requires the usage of these classes 
> (not interfaces) there is no point (yet) to do so.

Above I meant PortletDescriptorRegistry, not PortalAdministrationService.

Sorry about this.

Regards,

Ate

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Elliot Metsger wrote:
> Sorry Ate, everyone, for the delayed response.  Life happens, right? :)
Really :)

> 
> First I am totally supportive of getting Pluto 2 to work with JS.  The 
> rest is just details :)  
Thanks, lets get started ;)

> I know there are other projects (uPortal, Sakai) which have migrated to and embedded (respectively) Pluto 1.1.
> 
> Ate Douma wrote:
> 
> <snip>
> 
>>
>> 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.
> 
> Here are my comments on the Descriptor OM.  There was an intentional 
> design decision made with the 1.1 descriptor om: specifically that no 
> behaviors or responsibilities are attached to model.
I agree with this on general level.

> The model is 
> orthogonal to the behaviors.  Restricting the OM to what are essentially 
> just beans or value objects makes it easy for embedders: they aren't 
> forced to implement a bunch of interfaces.  
Sure, but the way it is implemented now that also is as far as you can go.
The base problem is that creation and management of the descriptor beans is and can only be done by the container itself.
That makes it very easy if you don't need more then the behavior which *the container* attaches to them, but expanding beyond that isn't possible.
In my view, the OM *needs* to be defined as interfaces (or you would need again portal provided factories to get hold of concrete instances) and the container 
should restrict itself to only using these interfaces.
There is nothing wrong with also providing concrete bean implementations like the current descriptor API does, and *by default* use these through a pluggable 
Registry service. Out of the box, the container will then behave exactly as it does now, and this will have no impact for current embedders like uPortal and 
Sakai. So its a simple and easy to provide win-win solution for both sides.

> And if they want additional 
> behaviors like persistence they can add them in the portal implementation.
Which is the problem: we can't.

> 
> uPortal for example (and Eric correct me if I'm wrong) has a relatively 
> straight forward model of portlet -windows, -entities, -deployments, and 
> applications and has a hibernate-based implementation for persisting them.
No. I've looked at uPortal and AFAIK, they do have their own model for things like PortletWindow etc. but that doesn't extend to the deployment descriptor beans 
themselves for which the whole management is under control of the Pluto container only.
The uPortal model objects are somewhat "attached" to the Pluto interaction, but for example the PortletWindow interface is itself wrapped inside the Pluto 
container to *override* specific behavior like for getting the ServletContext. The fact Pluto needs this is based on its own Registry and PortletContext 
management implementation which cannot be replaced at the moment.
And as Eric Dalquist also mentioned, providing our own PortletContext implementation isn't possible at all (and we definitely do need that).

> 
> A little off topic, I think there improvments that need to be made to 
> the descriptor impl - Eric Dalquist has some good ideas.  The goal there 
> being to load the descriptor impl from the webapp classloader instead of 
> having to pollute a shared classloader with the descriptor impl and all 
> of its dependencies.
Sure, that will probably work fine for us too, only the portal itself will need that in its classloader AFAIK.

> 
> 
>> 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.
> 
> I'm not sure what you mean here.  Generally the pluto container, along 
> with the descriptor api and impl are deployed in a shared classloader, 
> so you only need one instance.
The classes are shared yes, but multiple instances need to be created.
AFAIK now a separate instance of the PortletContainer is needed for each portlet application as it needs to be initialized with a ServletContext. This is needed 
I think because the Registry and PortletContext managers are scoped to the ServletContext as well.

> 
>> 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).
> 
> What about Jetspeed providing its own "PortletServlet" implementation. 
> The portlet servlet is pretty simple, initing the portlet, fixing up the 
> request and response and dispatching to the container. 
Of course, we could even extend the Pluto PortletServlet for that end.
The problem is though, the current Pluto PortletServlet is completely tied to the concrete PortalAdministrationService and PortletContextManager.
And as the container itself also requires the usage of these classes (not interfaces) there is no point (yet) to do so.

> You'll need to 
> have the assembler use your servlet implementation when assembling web.xml.
Jetspeed currently uses its own deploy-tool both for offline and runtime "infusion" of portal agnostic portlet applications which allows us to support "hot" 
deployment of portlet applications in Jetspeed.
It might be interesting to evaluate how much overlap there is between the Pluto assembler and our deploy-tool component and see if we can join efforts to 
provide a generic solution which can be used both by Pluto and Jetspeed?

> 
>> 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.
> 
> Normally the container will sit in a shared classloader, so there is 
> only a single instance of PortletServlet in a JVM. 
No. A single instance for each reference in each web.xml, so at least one for each portlet application, and for the default pluto container one for each portlet.

> When PortletServlet 
> is initialized, it registers the available portlets with the 
> RegistryService.
> 
> The Registry Service is an interface and a portal can have its own 
> implementation.  You can dynamically register new portlets on the 
> registry service.
The PortletRegistryService is implemented by the Pluto PortletContextManager which is used as a static singleton instance, PortletContextManager.getManager().
This PortletContextManager is directly referenced by the Pluto PortletServlet. Additionally, itself directly references the PortletDecriptorRegistry, also as 
static singleton instance. And finally, the Pluto PortletContainerImpl and the PortletEntityImpl also directly reference this static instance.
So, it currently is impossible to provide our own implementation of these services, which I meant by these not being proper SPI but merely API services.
In my opinion, the static references to these service implementations need to be replaced by interface references only to be able to provide our own.
Only then it makes sense to provide our own Jetspeed PortletServlet and/or extend the Pluto PortletServlet.
> 
>>
>> 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.
> 
> Let me come back on this issue, I need to look at the code a bit more to 
> understand.  I do see where PCM is used instead of the interface.  It 
> may be easy to switch to using the interface.  E.g. PortletContainerImpl 
> already has a reference to OptionalContainerServices so looking up the 
> Registry Service by interface instead of instantiating PCM directly 
> should be doable.  There may be classloader issue.
> 
> In general there should be a way to inject the impl that you require. If 
> there isn't a way, there's definintly a problem that we need to 
> design/code a solution to.
Cool, I think we'll be able to get to a proper solution for this.

> 
>>
>> Solution
>> ========
> 
> I gotta run now but I'd like to take some more time and reply in more 
> detail, icluding commenting on the solution.
> 
> Thanks Ate and JS team for bringing these issues up!
> 
> Elliot

Thanks Elliot,

Regards,

Ate

> 
>> 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).
>>
>> So please, provide feedback and ideas how to solve these issues. And 
>> suggestions for alternative solutions will very much appreciated too!
>>
>> With kind regards,
>>
>> Dennis Dam
>> David Sean Taylor
>> Ate Douma
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Elliot Metsger wrote:
> Sorry Ate, everyone, for the delayed response.  Life happens, right? :)
Really :)

> 
> First I am totally supportive of getting Pluto 2 to work with JS.  The 
> rest is just details :)  
Thanks, lets get started ;)

> I know there are other projects (uPortal, Sakai) which have migrated to and embedded (respectively) Pluto 1.1.
> 
> Ate Douma wrote:
> 
> <snip>
> 
>>
>> 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.
> 
> Here are my comments on the Descriptor OM.  There was an intentional 
> design decision made with the 1.1 descriptor om: specifically that no 
> behaviors or responsibilities are attached to model.
I agree with this on general level.

> The model is 
> orthogonal to the behaviors.  Restricting the OM to what are essentially 
> just beans or value objects makes it easy for embedders: they aren't 
> forced to implement a bunch of interfaces.  
Sure, but the way it is implemented now that also is as far as you can go.
The base problem is that creation and management of the descriptor beans is and can only be done by the container itself.
That makes it very easy if you don't need more then the behavior which *the container* attaches to them, but expanding beyond that isn't possible.
In my view, the OM *needs* to be defined as interfaces (or you would need again portal provided factories to get hold of concrete instances) and the container 
should restrict itself to only using these interfaces.
There is nothing wrong with also providing concrete bean implementations like the current descriptor API does, and *by default* use these through a pluggable 
Registry service. Out of the box, the container will then behave exactly as it does now, and this will have no impact for current embedders like uPortal and 
Sakai. So its a simple and easy to provide win-win solution for both sides.

> And if they want additional 
> behaviors like persistence they can add them in the portal implementation.
Which is the problem: we can't.

> 
> uPortal for example (and Eric correct me if I'm wrong) has a relatively 
> straight forward model of portlet -windows, -entities, -deployments, and 
> applications and has a hibernate-based implementation for persisting them.
No. I've looked at uPortal and AFAIK, they do have their own model for things like PortletWindow etc. but that doesn't extend to the deployment descriptor beans 
themselves for which the whole management is under control of the Pluto container only.
The uPortal model objects are somewhat "attached" to the Pluto interaction, but for example the PortletWindow interface is itself wrapped inside the Pluto 
container to *override* specific behavior like for getting the ServletContext. The fact Pluto needs this is based on its own Registry and PortletContext 
management implementation which cannot be replaced at the moment.
And as Eric Dalquist also mentioned, providing our own PortletContext implementation isn't possible at all (and we definitely do need that).

> 
> A little off topic, I think there improvments that need to be made to 
> the descriptor impl - Eric Dalquist has some good ideas.  The goal there 
> being to load the descriptor impl from the webapp classloader instead of 
> having to pollute a shared classloader with the descriptor impl and all 
> of its dependencies.
Sure, that will probably work fine for us too, only the portal itself will need that in its classloader AFAIK.

> 
> 
>> 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.
> 
> I'm not sure what you mean here.  Generally the pluto container, along 
> with the descriptor api and impl are deployed in a shared classloader, 
> so you only need one instance.
The classes are shared yes, but multiple instances need to be created.
AFAIK now a separate instance of the PortletContainer is needed for each portlet application as it needs to be initialized with a ServletContext. This is needed 
I think because the Registry and PortletContext managers are scoped to the ServletContext as well.

> 
>> 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).
> 
> What about Jetspeed providing its own "PortletServlet" implementation. 
> The portlet servlet is pretty simple, initing the portlet, fixing up the 
> request and response and dispatching to the container. 
Of course, we could even extend the Pluto PortletServlet for that end.
The problem is though, the current Pluto PortletServlet is completely tied to the concrete PortalAdministrationService and PortletContextManager.
And as the container itself also requires the usage of these classes (not interfaces) there is no point (yet) to do so.

> You'll need to 
> have the assembler use your servlet implementation when assembling web.xml.
Jetspeed currently uses its own deploy-tool both for offline and runtime "infusion" of portal agnostic portlet applications which allows us to support "hot" 
deployment of portlet applications in Jetspeed.
It might be interesting to evaluate how much overlap there is between the Pluto assembler and our deploy-tool component and see if we can join efforts to 
provide a generic solution which can be used both by Pluto and Jetspeed?

> 
>> 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.
> 
> Normally the container will sit in a shared classloader, so there is 
> only a single instance of PortletServlet in a JVM. 
No. A single instance for each reference in each web.xml, so at least one for each portlet application, and for the default pluto container one for each portlet.

> When PortletServlet 
> is initialized, it registers the available portlets with the 
> RegistryService.
> 
> The Registry Service is an interface and a portal can have its own 
> implementation.  You can dynamically register new portlets on the 
> registry service.
The PortletRegistryService is implemented by the Pluto PortletContextManager which is used as a static singleton instance, PortletContextManager.getManager().
This PortletContextManager is directly referenced by the Pluto PortletServlet. Additionally, itself directly references the PortletDecriptorRegistry, also as 
static singleton instance. And finally, the Pluto PortletContainerImpl and the PortletEntityImpl also directly reference this static instance.
So, it currently is impossible to provide our own implementation of these services, which I meant by these not being proper SPI but merely API services.
In my opinion, the static references to these service implementations need to be replaced by interface references only to be able to provide our own.
Only then it makes sense to provide our own Jetspeed PortletServlet and/or extend the Pluto PortletServlet.
> 
>>
>> 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.
> 
> Let me come back on this issue, I need to look at the code a bit more to 
> understand.  I do see where PCM is used instead of the interface.  It 
> may be easy to switch to using the interface.  E.g. PortletContainerImpl 
> already has a reference to OptionalContainerServices so looking up the 
> Registry Service by interface instead of instantiating PCM directly 
> should be doable.  There may be classloader issue.
> 
> In general there should be a way to inject the impl that you require. If 
> there isn't a way, there's definintly a problem that we need to 
> design/code a solution to.
Cool, I think we'll be able to get to a proper solution for this.

> 
>>
>> Solution
>> ========
> 
> I gotta run now but I'd like to take some more time and reply in more 
> detail, icluding commenting on the solution.
> 
> Thanks Ate and JS team for bringing these issues up!
> 
> Elliot

Thanks Elliot,

Regards,

Ate

> 
>> 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).
>>
>> So please, provide feedback and ideas how to solve these issues. And 
>> suggestions for alternative solutions will very much appreciated too!
>>
>> With kind regards,
>>
>> Dennis Dam
>> David Sean Taylor
>> Ate Douma
>>
> 

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Elliot Metsger <em...@jhu.edu>]

Sorry Ate, everyone, for the delayed response.  Life happens, right? :)

First I am totally supportive of getting Pluto 2 to work with JS.  The 
rest is just details :)  I know there are other projects (uPortal, 
Sakai) which have migrated to and embedded (respectively) Pluto 1.1.

Ate Douma wrote:

<snip>

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

Here are my comments on the Descriptor OM.  There was an intentional 
design decision made with the 1.1 descriptor om: specifically that no 
behaviors or responsibilities are attached to model.  The model is 
orthogonal to the behaviors.  Restricting the OM to what are essentially 
just beans or value objects makes it easy for embedders: they aren't 
forced to implement a bunch of interfaces.  And if they want additional 
behaviors like persistence they can add them in the portal implementation.

uPortal for example (and Eric correct me if I'm wrong) has a relatively 
straight forward model of portlet -windows, -entities, -deployments, and 
applications and has a hibernate-based implementation for persisting them.

A little off topic, I think there improvments that need to be made to 
the descriptor impl - Eric Dalquist has some good ideas.  The goal there 
being to load the descriptor impl from the webapp classloader instead of 
having to pollute a shared classloader with the descriptor impl and all 
of its dependencies.


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

I'm not sure what you mean here.  Generally the pluto container, along 
with the descriptor api and impl are deployed in a shared classloader, 
so you only need one instance.

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

What about Jetspeed providing its own "PortletServlet" implementation. 
The portlet servlet is pretty simple, initing the portlet, fixing up the 
request and response and dispatching to the container.  You'll need to 
have the assembler use your servlet implementation when assembling web.xml.

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

Normally the container will sit in a shared classloader, so there is 
only a single instance of PortletServlet in a JVM.  When PortletServlet 
is initialized, it registers the available portlets with the 
RegistryService.

The Registry Service is an interface and a portal can have its own 
implementation.  You can dynamically register new portlets on the 
registry service.

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

Let me come back on this issue, I need to look at the code a bit more to 
understand.  I do see where PCM is used instead of the interface.  It 
may be easy to switch to using the interface.  E.g. PortletContainerImpl 
already has a reference to OptionalContainerServices so looking up the 
Registry Service by interface instead of instantiating PCM directly 
should be doable.  There may be classloader issue.

In general there should be a way to inject the impl that you require. 
If there isn't a way, there's definintly a problem that we need to 
design/code a solution to.

> 
> Solution
> ========

I gotta run now but I'd like to take some more time and reply in more 
detail, icluding commenting on the solution.

Thanks Ate and JS team for bringing these issues up!

Elliot

> 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).
> 
> So please, provide feedback and ideas how to solve these issues. And 
> suggestions for alternative solutions will very much appreciated too!
> 
> With kind regards,
> 
> Dennis Dam
> David Sean Taylor
> Ate Douma
> 

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[csev <cs...@umich.edu>]

On Feb 15, 2008, at 8:24 AM, Ate Douma wrote:

> It is not our intention to make it much harder than that for sure,  
> but with the many enhancements for JSR-286 some changes will indeed  
> be needed at your side too for upgrading to Pluto 2.0

I fully expect this - I just want to make it clear that I am also  
completely happy if the SPI needs further changes to meet Jetspeed's  
needs.  Put another way - if getting Sakai to 2.0 is a little harder  
because the SPI changed to meet Jetspeed 2's needs - this will not  
make me unhappy.  On the contrary - it will make me quite *happy* -  
because the more folks that consume the SPI - the better the SPI  
becomes.  SPIs are not like APIs - they tend to have to grow and  
adjust to new, unimagined use cases almost all the time.

> We'll do our best to maintain as much of the current integration  
> support, just make it possible and easier to also integrate on the  
> level we need for Jetspeed.
> Any insight and opinion you might have on that while we lay out our  
> plans will be much appreciated!

Thanks - I will be lurking like always and offer help when I can.

/Chuck

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[csev <cs...@umich.edu>]

On Feb 15, 2008, at 8:24 AM, Ate Douma wrote:

> It is not our intention to make it much harder than that for sure,  
> but with the many enhancements for JSR-286 some changes will indeed  
> be needed at your side too for upgrading to Pluto 2.0

I fully expect this - I just want to make it clear that I am also  
completely happy if the SPI needs further changes to meet Jetspeed's  
needs.  Put another way - if getting Sakai to 2.0 is a little harder  
because the SPI changed to meet Jetspeed 2's needs - this will not  
make me unhappy.  On the contrary - it will make me quite *happy* -  
because the more folks that consume the SPI - the better the SPI  
becomes.  SPIs are not like APIs - they tend to have to grow and  
adjust to new, unimagined use cases almost all the time.

> We'll do our best to maintain as much of the current integration  
> support, just make it possible and easier to also integrate on the  
> level we need for Jetspeed.
> Any insight and opinion you might have on that while we lay out our  
> plans will be much appreciated!

Thanks - I will be lurking like always and offer help when I can.

/Chuck

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Hi Chuck,

Thanks for the clear and positive response.

Like maybe uPortal, it looks like Sakai doesn't need or use as much integration and extendability from the pluto container as Jetspeed depends upon.
And I fully understand and support the much easier integration the new Pluto 1.1.x architecture has delivered.

It is not our intention to make it much harder than that for sure, but with the many enhancements for JSR-286 some changes will indeed be needed at your side 
too for upgrading to Pluto 2.0

We'll do our best to maintain as much of the current integration support, just make it possible and easier to also integrate on the level we need for Jetspeed.
Any insight and opinion you might have on that while we lay out our plans will be much appreciated!

Regards,

Ate

csev wrote:
> Ate,
> 
> I just wanted to offer some general comments as a consumer of the Pluto 
> 1.1 release - which provides Sakai its JSR-168 support.  Sakai is not a 
> portal - it is a learning management system with basic JSR-168 support 
> as a plugin.  So Sakai makes pretty simple demands on Pluto 1.1.
> 
> I would never have been able to find the time to de-construct Pluto 1.0 
> for use in Sakai.  On the other hand, Pluto 1.1 is amazing to work with.
> 
> We upgrade our version of Pluto 1.1 by simply replacing jar files.  
> Pluto 1.0 could never have done that under any circumstances.
> 
> That said, the SPI is not perfect and will likely never be "perfect".   
> Each integration that I participated in had the effect of evolving and 
> improving the SPI.
> 
> Sakai did not stress Pluto features so all Sakai needed from Pluto was a 
> bit of re-factoring of the source tree to get the right things in jars 
> (apis in an Api jar), implementation in implementation jars, and 
> non-essential stuff somewhere else.
> 
> uPortal is a more functional portal than Sakai and needed to extend the 
> SPI to make things work.  So we got together and jointly figured out 
> what the SPI needs were from uPortal's perspective and made the changes.
> 
> There were tiny incompatible changes that caused Sakai to make slight 
> changes - because we were kind of working together these changes were 
> easily applied to Sakai - I used Sakai to QA several of the minor 
> releases of Pluto.
> 
> Now of course the SPI will change yet again in 2.0 and I fully expect 
> it.  Because we are using the jars, Sakai will have a solid 168 
> implementation as long as we like without being affected by improvements 
> in Pluto 2.0 and beyond.
> 
> I fully expect that a chunk of work will be needed on my part in Sakai 
> to make it into Pluto 2.0 - Some of this might be simply because of 
> JSR-286 and some of the work might be simply changing the SPI interface 
> to meet the needs of Jetspeed.
> 
> So my feeling is that if it is Jetspeed's "turn" to grab Pluto 2.0 - you 
> should feel OK if the SPI needs to change a bit - Jetspeed will have use 
> cases beyond what the SPI supports - so the SPI evolves.  That is what 
> will make Pluto 2.0 really awesome and make Sakai's job of using Pluto 
> 2.0 really easy because you will have done the "hard work" :)
> 
> Don't worry about us laggards - we can stick with what we have trivially 
> or we can catch-up if we want.  Either way we will certainly benefit 
> from the improvements that the Jetspeed work causes in the SPI.
> 
> Charles Severance
> Unviersity of Michigan
> 
>>
>> Ate Douma wrote:
>>> Dear committers, community,
>>>
>>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
>>> but we want and need to upgrade and migrate to the latest Pluto 
>>> container under
>>> development, aka the not yet released Pluto 2.0 targeted as the 
>>> JSR-286 RI.
>>>
>>> This however is currently impossible to do because of the 
>>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>>
>>> Technically, viewed from the POV of an easy to embed container for 
>>> the Pluto Portal Driver, or environments which only need the 
>>> out-of-the-box features
>>> provided, these architectural changes have resulted in a much simpler 
>>> and easier to understand and maintain model and API, and as such 
>>> these changes were great!
>>>
>>> But... for a portal like Jetspeed-2, which provides a much enhanced 
>>> usage and feature list *on container level*, these architectural 
>>> changes have, simply put,
>>> completely broken with the functional and technical "contract" 
>>> provided by Pluto 1.0.x and as such make it now impossible for us to 
>>> migrate to the current Pluto
>>> container.
> 
> [Snip]
> 

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Hi Chuck,

Thanks for the clear and positive response.

Like maybe uPortal, it looks like Sakai doesn't need or use as much integration and extendability from the pluto container as Jetspeed depends upon.
And I fully understand and support the much easier integration the new Pluto 1.1.x architecture has delivered.

It is not our intention to make it much harder than that for sure, but with the many enhancements for JSR-286 some changes will indeed be needed at your side 
too for upgrading to Pluto 2.0

We'll do our best to maintain as much of the current integration support, just make it possible and easier to also integrate on the level we need for Jetspeed.
Any insight and opinion you might have on that while we lay out our plans will be much appreciated!

Regards,

Ate

csev wrote:
> Ate,
> 
> I just wanted to offer some general comments as a consumer of the Pluto 
> 1.1 release - which provides Sakai its JSR-168 support.  Sakai is not a 
> portal - it is a learning management system with basic JSR-168 support 
> as a plugin.  So Sakai makes pretty simple demands on Pluto 1.1.
> 
> I would never have been able to find the time to de-construct Pluto 1.0 
> for use in Sakai.  On the other hand, Pluto 1.1 is amazing to work with.
> 
> We upgrade our version of Pluto 1.1 by simply replacing jar files.  
> Pluto 1.0 could never have done that under any circumstances.
> 
> That said, the SPI is not perfect and will likely never be "perfect".   
> Each integration that I participated in had the effect of evolving and 
> improving the SPI.
> 
> Sakai did not stress Pluto features so all Sakai needed from Pluto was a 
> bit of re-factoring of the source tree to get the right things in jars 
> (apis in an Api jar), implementation in implementation jars, and 
> non-essential stuff somewhere else.
> 
> uPortal is a more functional portal than Sakai and needed to extend the 
> SPI to make things work.  So we got together and jointly figured out 
> what the SPI needs were from uPortal's perspective and made the changes.
> 
> There were tiny incompatible changes that caused Sakai to make slight 
> changes - because we were kind of working together these changes were 
> easily applied to Sakai - I used Sakai to QA several of the minor 
> releases of Pluto.
> 
> Now of course the SPI will change yet again in 2.0 and I fully expect 
> it.  Because we are using the jars, Sakai will have a solid 168 
> implementation as long as we like without being affected by improvements 
> in Pluto 2.0 and beyond.
> 
> I fully expect that a chunk of work will be needed on my part in Sakai 
> to make it into Pluto 2.0 - Some of this might be simply because of 
> JSR-286 and some of the work might be simply changing the SPI interface 
> to meet the needs of Jetspeed.
> 
> So my feeling is that if it is Jetspeed's "turn" to grab Pluto 2.0 - you 
> should feel OK if the SPI needs to change a bit - Jetspeed will have use 
> cases beyond what the SPI supports - so the SPI evolves.  That is what 
> will make Pluto 2.0 really awesome and make Sakai's job of using Pluto 
> 2.0 really easy because you will have done the "hard work" :)
> 
> Don't worry about us laggards - we can stick with what we have trivially 
> or we can catch-up if we want.  Either way we will certainly benefit 
> from the improvements that the Jetspeed work causes in the SPI.
> 
> Charles Severance
> Unviersity of Michigan
> 
>>
>> Ate Douma wrote:
>>> Dear committers, community,
>>>
>>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
>>> but we want and need to upgrade and migrate to the latest Pluto 
>>> container under
>>> development, aka the not yet released Pluto 2.0 targeted as the 
>>> JSR-286 RI.
>>>
>>> This however is currently impossible to do because of the 
>>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>>
>>> Technically, viewed from the POV of an easy to embed container for 
>>> the Pluto Portal Driver, or environments which only need the 
>>> out-of-the-box features
>>> provided, these architectural changes have resulted in a much simpler 
>>> and easier to understand and maintain model and API, and as such 
>>> these changes were great!
>>>
>>> But... for a portal like Jetspeed-2, which provides a much enhanced 
>>> usage and feature list *on container level*, these architectural 
>>> changes have, simply put,
>>> completely broken with the functional and technical "contract" 
>>> provided by Pluto 1.0.x and as such make it now impossible for us to 
>>> migrate to the current Pluto
>>> container.
> 
> [Snip]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[csev <cs...@umich.edu>]

Ate,

I just wanted to offer some general comments as a consumer of the  
Pluto 1.1 release - which provides Sakai its JSR-168 support.  Sakai  
is not a portal - it is a learning management system with basic  
JSR-168 support as a plugin.  So Sakai makes pretty simple demands on  
Pluto 1.1.

I would never have been able to find the time to de-construct Pluto  
1.0 for use in Sakai.  On the other hand, Pluto 1.1 is amazing to work  
with.

We upgrade our version of Pluto 1.1 by simply replacing jar files.   
Pluto 1.0 could never have done that under any circumstances.

That said, the SPI is not perfect and will likely never be  
"perfect".   Each integration that I participated in had the effect of  
evolving and improving the SPI.

Sakai did not stress Pluto features so all Sakai needed from Pluto was  
a bit of re-factoring of the source tree to get the right things in  
jars (apis in an Api jar), implementation in implementation jars, and  
non-essential stuff somewhere else.

uPortal is a more functional portal than Sakai and needed to extend  
the SPI to make things work.  So we got together and jointly figured  
out what the SPI needs were from uPortal's perspective and made the  
changes.

There were tiny incompatible changes that caused Sakai to make slight  
changes - because we were kind of working together these changes were  
easily applied to Sakai - I used Sakai to QA several of the minor  
releases of Pluto.

Now of course the SPI will change yet again in 2.0 and I fully expect  
it.  Because we are using the jars, Sakai will have a solid 168  
implementation as long as we like without being affected by  
improvements in Pluto 2.0 and beyond.

I fully expect that a chunk of work will be needed on my part in Sakai  
to make it into Pluto 2.0 - Some of this might be simply because of  
JSR-286 and some of the work might be simply changing the SPI  
interface to meet the needs of Jetspeed.

So my feeling is that if it is Jetspeed's "turn" to grab Pluto 2.0 -  
you should feel OK if the SPI needs to change a bit - Jetspeed will  
have use cases beyond what the SPI supports - so the SPI evolves.   
That is what will make Pluto 2.0 really awesome and make Sakai's job  
of using Pluto 2.0 really easy because you will have done the "hard  
work" :)

Don't worry about us laggards - we can stick with what we have  
trivially or we can catch-up if we want.  Either way we will certainly  
benefit from the improvements that the Jetspeed work causes in the SPI.

Charles Severance
Unviersity of Michigan

>
> Ate Douma wrote:
>> Dear committers, community,
>>
>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168  
>> container, but we want and need to upgrade and migrate to the  
>> latest Pluto container under
>> development, aka the not yet released Pluto 2.0 targeted as the  
>> JSR-286 RI.
>>
>> This however is currently impossible to do because of the  
>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>
>> Technically, viewed from the POV of an easy to embed container for  
>> the Pluto Portal Driver, or environments which only need the out-of- 
>> the-box features
>> provided, these architectural changes have resulted in a much  
>> simpler and easier to understand and maintain model and API, and as  
>> such these changes were great!
>>
>> But... for a portal like Jetspeed-2, which provides a much enhanced  
>> usage and feature list *on container level*, these architectural  
>> changes have, simply put,
>> completely broken with the functional and technical "contract"  
>> provided by Pluto 1.0.x and as such make it now impossible for us  
>> to migrate to the current Pluto
>> container.

[Snip]

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Eric Dalquist <er...@doit.wisc.edu>]

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

<snip>
>>>
>>>
>>> The Pluto 1.1.x service provider interfaces (SPI)
>>> =================================================
>>> Although the new Pluto SPI (comprising of the 
>>> RequiredContainerServices and OptionalContainerServices) generally 
>>> provides a nice and simple interface to plugin
>>> portal specific implementations, certain features available with 
>>> Pluto 1.0.x are no longer available.
>>>
>>> With Pluto 1.0.x, critical components as the PortletContext and 
>>> PortletWindow were accessed by the container through factory classes.
>>> These no longer exist and the pluto container directly instantiates 
>>> its own implementations for these components.
>> You can provide your own PortletWindow impl. Since all container 
>> calls require a PortletWindow (interface) all callbacks simply 
>> provide this interface back to the handling code. We definitely have 
>> a custom PortletWindow implementation that tracks more information 
>> than the Pluto interface describes.
> True, but onces invoked, Pluto will nonetheless *wrap* this interface 
> inside an instance of its own PortletWindowImpl anyway.
> This implementation delegates all the interface methods to the wrapped 
> object itself, except getServletContext() and getPortletEntity() which 
> it overrides.
> And these two method overrides are used to hook back into the internal 
> container content management and descriptor registry.
> That's just my point: the current container simply enforces these 
> dependencies and providing our own implementation of the PortletWindow 
> will be useless.
Ah, so the concern is not that your original window is not available to 
the SPI callbacks (it is via 
InternalPortletWindow.getOriginalPortletWindow()) but that you can't 
control all methods on the PortletWindow impl that Pluto uses internally.
>
>> It does look like there is no way to provide your own PortletContext 
>> impl.
>>>
>>> Jetspeed however very much depends on its own extensions of these 
>>> components to provide support for features like parallel rendering, 
>>> clustering and attaching
>>> additional meta data (or even preferences) to a PortletWindow or 
>>> PortletEntity.
>>> Additionally, while Pluto 1.0.x allowed managing multiple 
>>> PortletWindows for a PortletEntity, this *Portlet Spec* feature has 
>>> been removed from the current
>>> Pluto 1.1.x/2.0 container.
>> Again, I'm not sure the need for portlet container support for this. 
>> We use the DD objects as an easy way to know what is in the .xml 
>> objects. We then internally have our own portlet object model with a 
>> PortletDefinition (admin publishing a portlet), PortletEntity (user 
>> subscribing to portlet), PortletWindow (user viewing a portlet). Each 
>> definition can have N child entities and each entity can have N child 
>> windows. Each level in the model provides extra configuration data 
>> that we expose via the SPIs that we implement. We don't even bother 
>> with the Pluto PortletEntity interface since the only thing Pluto 
>> ever asks for is a PortletWindow.
> Yeah, but what about the preferences? Pluto access the PortletWindow 
> preferences through its *internally managed* PortletEntity. As we have 
> no control here, we  can't put our own preferences extensions (like 
> defined on PSML page level for instance) in place either.
There is the PortletPreferencesService. We have a custom implementation 
that for the getStoredPreferences call collates the preferences from the 
DD, our definition object and our entity object into a single 
preferences view for the portlet. The store call does the work of 
determining what has changed and what to store where. We have a layered 
preference architecture that allows publishers to define preferences 
that are layered on top of the descriptor preferences in addition to the 
standard runtime preferences that are scoped to users.
>
>>>
>>> Lastly, not all of services referenced through these SPI interfaces 
>>> are only accessed through it.
>>> For instance, the 
>>> OptionalContainerService.getPortletRegistryService() is by default 
>>> implemented by the PortletContextManager. But, this implementation 
>>> is very
>>> much directly used (as static instance even) within the container. 
>>> Effectively, the interface is now only an API portals might use, but 
>>> it cannot be replaced
>>> and thereby cannot be regarded as a proper SPI interface anymore.
>> This seems like a pretty big bug. While we didn't have a need for it 
>> I can very much see where moving the descriptor service behind a true 
>> SPI to allow implementers to write their own if they want would be a 
>> good thing.
> Thanks for your view. Although you might not need it now, that can 
> change in the future.
> Having this fixed will help us all.
>
>>>
>>> Solution
>>> ========
>>> As indicated earlier, solving the above issues such that Pluto 2.0 
>>> can be made embeddable again, in Jetspeed or other portals, needs to 
>>> be done in a way which
>>> maintains backwards compatibility for current Pluto 1.1.x users.
>>>
>>> Although we don't have a clear proposal for this, our current idea 
>>> is to:
>>> - define new OM interfaces to be implemented by the current 
>>> descriptor api classes
>>> - enhance the OptionalContainerServices SPI to provide additional 
>>> services for loading and managing the deployment descriptors
>>> - enhance the OptionalContainerServices SPI to provide additional 
>>> services for accessing components like PortletContext, PortletWindow 
>>> etc.
>>> - refactor the container implementation to only use the OM interfaces
>>> - refactor the container implementation to only use the SPI provided 
>>> services and no longer directly binding to its service implementations
>> These all seem like great solutions and it seems to me they could be 
>> done with very minor changes required of people that have already 
>> implemented 1.1
> That's the goal!
> Reviewing this proposal and monitoring and checking the changes onces 
> we start performing them is and will be very helpful.
>
Glad we can help.

-Eric

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

Hi Eric,

Thanks for your very precise and informative response.

I also have a few comments inline of course.

Regards,

Ate

Eric Dalquist wrote:
> Ate,
> 
> To introduce myself I'm a developer on the uPortal project and was one 
> of the people involved in upgrading from Pluto 1.0.1 to 1.1. I will say 
> up front it was a fair bit of work. We essentially removed the 1.0 
> support code and wrote the 1.1 support code from scratch. The result was 
> a smaller amount of code required in uPortal to make use of Pluto 1.1 
> with no loss in functionality and actually a gain in functionality in 
> many places. I have more comments in-line.
> 
> Ate Douma wrote:
>> Dear committers, community,
>>
>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
>> but we want and need to upgrade and migrate to the latest Pluto 
>> container under
>> development, aka the not yet released Pluto 2.0 targeted as the 
>> JSR-286 RI.
>>
>> This however is currently impossible to do because of the 
>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>
>> Technically, viewed from the POV of an easy to embed container for the 
>> Pluto Portal Driver, or environments which only need the 
>> out-of-the-box features
>> provided, these architectural changes have resulted in a much simpler 
>> and easier to understand and maintain model and API, and as such these 
>> changes were great!
>>
>> But... for a portal like Jetspeed-2, which provides a much enhanced 
>> usage and feature list *on container level*, these architectural 
>> changes have, simply put,
>> completely broken with the functional and technical "contract" 
>> provided by Pluto 1.0.x and as such make it now impossible for us to 
>> migrate to the current Pluto
>> container.
>>
>> As it is the primary mission and goal of the Pluto project to provide 
>> an embeddable portlet container for portals like its Apache Portals 
>> sibling project
>> Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to 
>> discuss what needs and can to be done, on both Jetspeed-2 and Pluto 
>> side, to bring our
>> projects back together, and how to restore the original *functional* 
>> contract Pluto provided with version 1.0.x.
>>
>> To this end, we'll present our (short) assessment how the current 
>> Pluto container API and implementation has changed and broken with the 
>> old Pluto 1.0.x
>> features which Jetspeed-2 depends upon to be able to maintain our 
>> current Jetspeed-2 features, as well as what we think needs to be done 
>> *functionally* to
>> restore these features.
>>
>> To be very clear: we're not asking nor suggesting to restore the old 
>> Pluto 1.0.x API and SPI as is. We fully expect and are willing to 
>> adapt Jetspeed-2 to the
>> new Pluto architecture as much as needed, even while that most likely 
>> will now cause Jetspeed-2 itself to have to break with its own public 
>> API and thus lose
>> (some) backwards compatibility. After all, Pluto now has had several 
>> releases based on its new Pluto 1.1.x architecture and we (as Apache 
>> Portals community)
>> have the obligation to maintain as much backwards compatibility for 
>> the users of these versions as well.
>>
>> So, what we will propose later on is to work towards a solution which 
>> will restore the ability for Jetspeed to properly use and embed the 
>> new Pluto 2.0
>> container but still maintain the lightweight and simple configuration 
>> and usage of the container for portals like the Pluto Portal Driver 
>> and other use-cases
>> without breaking its current "contract".
>>
>> But first lets get down to some of the issues we have identified so 
>> far. This is most likely not the complete list but covers the most 
>> important ones.
>>
>> The Pluto 1.0.x object model API (OM)
>> =====================================
>> Pluto 1.0.x provided a fully interface based object model to represent 
>> the web and portlet deployment descriptors (web.xml and portlet.xml).
>> Through factory methods, the Pluto 1.0.x container only used these 
>> interfaces in its implementation. That allowed Jetspeed and other 
>> portals to supply its own
>> implementation of the OM and use that to provide enhanced features 
>> like database persistence, extended meta data, caching control, etc.
>> Of course, Pluto 1.0.x also provided its own implementation classes of 
>> the OM and Jetspeed uses these as base classes but provides extended 
>> implementations to
>> hook them up and into its own backend and management features.
>>
>> Pluto 1.1.x completely dropped all of this. Instead, a new descriptor 
>> API was provided with a complete new set of classes (no interfaces!) 
>> which are used and
>> instantiated directly within the container with no factory support or 
>> any other way of extending the current implementation.
>> As such, the current container only allows usage of the web.xml and 
>> portlet.xml descriptors and features derived from them as provided by 
>> the container.
>> Furthermore, as the loading and management of the descriptors is now 
>> done directly (and only) by the container itself, there is no way for 
>> Jetspeed to hook into
>> this process anymore.
>>
>> Effectively, this means that descriptor persistence, caching, custom 
>> extensions, *standard* support for custom portlet mode or window-state 
>> mapping,
>> etc. all no longer are possible with the current Pluto container. Not 
>> just for Jetspeed but any portal needing and depending on these features.
> We use make both custom portlet modes and window states available to 
> deployed portlets and this functions as expected in Pluto 1.1, the 
> descriptor objects provide information about which custom modes and 
> states the portlet has declared.
That information is available from the descriptor itself, true.
But in Jetspeed-2 you can additionally define a custom mapping of existing Portal provided modes/states to the ones defined by the portlet.
For this we leverage an additional deployment descriptor which meta data is linked to the (persistent) object model representation of the standard portlet 
descriptor. This extension mechanism is no longer doable with Pluto.
>>
>> The Pluto 1.1.x/2.0 PortletContextManager, PortletDescriptorRegistry 
>> and PortletServlet
>> ======================================================================================= 
>>
>> With the switch to Pluto 1.1.x, the container added control and 
>> management of the above mentioned deployment descriptors and fully 
>> integrated them with the
>> container interaction which now depend on this management 
>> *implementation*, and also hooked that up on the portlet application 
>> context.
>> This means that now you need a separate container instance for each 
>> portlet application and that the container itself loads and manages 
>> the descriptors.
>> Also, interaction with the container now requires the use of the Pluto 
>> provided PortletServlet (although that one possibly can be extended) 
>> as it is tied to the
>> PortletContextManager directly (which in turn is tied to the 
>> PortletDescriptorRegistry).
>>
>> Besides the obvious problem that this effectively blocks delegating 
>> management of the context and descriptors for the portal, it also 
>> forces the usage and
>> interaction with portlets to the Pluto provided implementation.
>> For instance, Pluto delegates interaction to each portlet through a 
>> separate instance of its PortletServlet, while Jetspeed currently has 
>> its own more generic
>> JetspeedContainerServlet which is not tied to a single portlet. The 
>> Jetspeed solution allows for dynamically enabling/adding portlets (as 
>> defined in
>> portlet.xml) without any need to rewrite the web.xml. But using the 
>> Pluto PortletServlet requires changing the web.xml (and thus reloading 
>> the context) to do so.
>>
>> The Pluto 1.1.x service provider interfaces (SPI)
>> =================================================
>> Although the new Pluto SPI (comprising of the 
>> RequiredContainerServices and OptionalContainerServices) generally 
>> provides a nice and simple interface to plugin
>> portal specific implementations, certain features available with Pluto 
>> 1.0.x are no longer available.
>>
>> With Pluto 1.0.x, critical components as the PortletContext and 
>> PortletWindow were accessed by the container through factory classes.
>> These no longer exist and the pluto container directly instantiates 
>> its own implementations for these components.
> You can provide your own PortletWindow impl. Since all container calls 
> require a PortletWindow (interface) all callbacks simply provide this 
> interface back to the handling code. We definitely have a custom 
> PortletWindow implementation that tracks more information than the Pluto 
> interface describes.
True, but onces invoked, Pluto will nonetheless *wrap* this interface inside an instance of its own PortletWindowImpl anyway.
This implementation delegates all the interface methods to the wrapped object itself, except getServletContext() and getPortletEntity() which it overrides.
And these two method overrides are used to hook back into the internal container content management and descriptor registry.
That's just my point: the current container simply enforces these dependencies and providing our own implementation of the PortletWindow will be useless.

> It does look like there is no way to provide your 
> own PortletContext impl.
>>
>> Jetspeed however very much depends on its own extensions of these 
>> components to provide support for features like parallel rendering, 
>> clustering and attaching
>> additional meta data (or even preferences) to a PortletWindow or 
>> PortletEntity.
>> Additionally, while Pluto 1.0.x allowed managing multiple 
>> PortletWindows for a PortletEntity, this *Portlet Spec* feature has 
>> been removed from the current
>> Pluto 1.1.x/2.0 container.
> Again, I'm not sure the need for portlet container support for this. We 
> use the DD objects as an easy way to know what is in the .xml objects. 
> We then internally have our own portlet object model with a 
> PortletDefinition (admin publishing a portlet), PortletEntity (user 
> subscribing to portlet), PortletWindow (user viewing a portlet). Each 
> definition can have N child entities and each entity can have N child 
> windows. Each level in the model provides extra configuration data that 
> we expose via the SPIs that we implement. We don't even bother with the 
> Pluto PortletEntity interface since the only thing Pluto ever asks for 
> is a PortletWindow.
Yeah, but what about the preferences? Pluto access the PortletWindow preferences through its *internally managed* PortletEntity. As we have no control here, we 
  can't put our own preferences extensions (like defined on PSML page level for instance) in place either.

>>
>> Lastly, not all of services referenced through these SPI interfaces 
>> are only accessed through it.
>> For instance, the OptionalContainerService.getPortletRegistryService() 
>> is by default implemented by the PortletContextManager. But, this 
>> implementation is very
>> much directly used (as static instance even) within the container. 
>> Effectively, the interface is now only an API portals might use, but 
>> it cannot be replaced
>> and thereby cannot be regarded as a proper SPI interface anymore.
> This seems like a pretty big bug. While we didn't have a need for it I 
> can very much see where moving the descriptor service behind a true SPI 
> to allow implementers to write their own if they want would be a good 
> thing.
Thanks for your view. Although you might not need it now, that can change in the future.
Having this fixed will help us all.

>>
>> Solution
>> ========
>> As indicated earlier, solving the above issues such that Pluto 2.0 can 
>> be made embeddable again, in Jetspeed or other portals, needs to be 
>> done in a way which
>> maintains backwards compatibility for current Pluto 1.1.x users.
>>
>> Although we don't have a clear proposal for this, our current idea is to:
>> - define new OM interfaces to be implemented by the current descriptor 
>> api classes
>> - enhance the OptionalContainerServices SPI to provide additional 
>> services for loading and managing the deployment descriptors
>> - enhance the OptionalContainerServices SPI to provide additional 
>> services for accessing components like PortletContext, PortletWindow etc.
>> - refactor the container implementation to only use the OM interfaces
>> - refactor the container implementation to only use the SPI provided 
>> services and no longer directly binding to its service implementations
> These all seem like great solutions and it seems to me they could be 
> done with very minor changes required of people that have already 
> implemented 1.1
That's the goal!
Reviewing this proposal and monitoring and checking the changes onces we start performing them is and will be very helpful.

>>
>> When done properly, the above changes should still allow using the 
>> current implementation without any functional or even technical 
>> consequence.
>>
>> Now, the above changes will mean a lot of work and lots of testing as 
>> well to make sure everything remains working as expected.
>> We, as primary Jetspeed committers have much at stake here so we are 
>> definitely willing to help out and do much of the grunt work.
>> And of course, we will have a large amount of work to do at Jetspeed 
>> Portal side as well: all our Pluto Factory implementations have become 
>> useless, all Pluto
>> OM packages (and some interfaces) have changed, and we will need to 
>> provide new implementations for the Pluto SPI container services.
> We (uPortal Developers) can also be involved in this process to provide 
> the perspective of another portal that does quite a bit with hooks into 
> Pluto though it sounds like we do less than Jetspeed does.
Thanks!

>>
>> For our implementations of the Pluto SPI container services, we will 
>> definitely look at the current Pluto provided implementations and 
>> where possible try to
>> make use of them as much as possible. To that end, we will probably 
>> also need to be able to hook in our own extensions which might require 
>> some additional
>> refactoring but should not result in functional or technical changes 
>> of the default Pluto services.
>>
>> Note: we want to migrate to Pluto 2.0 for our next Jetspeed 2.2 
>> release. But, for that release we'll stick to only using the JSR-168 
>> container features.
>> Then, for the following major release, version 2.3 which we currently 
>> have scheduled sometime this summer, we will provide full JSR-286 
>> compliance.
>> So, our initial goal is to get Pluto 2.0 working again with Jetspeed-2 
>> but stick to our current features.
>>
>> This all is clearly not something which can be done or will be ready 
>> overnight, nor possible to do all by ourselves.
>> But we do need to start resolving this ASAP so it won't hold up the 
>> release of both Pluto 2.0 and Jetspeed 2.2 longer than needed.
>>
>> As said: the above proposal is still just an idea. And of course how 
>> to do all this, is fully open for debate and we are very interested in 
>> hearing the opinions
>> of other committers and community members (also from other portals 
>> embedding Pluto 1.1.x).
>>
>> So please, provide feedback and ideas how to solve these issues. And 
>> suggestions for alternative solutions will very much appreciated too!
> This sounds like a great proposal. As I've said above uPortal has 
> already gone through the pain (and yes there was some pain) of moving to 
> Pluto 1.1 but the simplification of our portlet support code was more 
> than worth it along with putting us in a position to more easily (we 
> hope) move to Pluto 2.0. I would be more than happy to talk about the 
> approaches uPortal has taken with using Pluto 1.1 and be involved with 
> discussions about these upcoming changes to Pluto 1.1 to make it as 
> useful as possible for other portals as well.
>>
>> With kind regards,
>>
>> Dennis Dam
>> David Sean Taylor
>> Ate Douma
>>
>>

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[csev <cs...@umich.edu>]

Ate,

I just wanted to offer some general comments as a consumer of the  
Pluto 1.1 release - which provides Sakai its JSR-168 support.  Sakai  
is not a portal - it is a learning management system with basic  
JSR-168 support as a plugin.  So Sakai makes pretty simple demands on  
Pluto 1.1.

I would never have been able to find the time to de-construct Pluto  
1.0 for use in Sakai.  On the other hand, Pluto 1.1 is amazing to work  
with.

We upgrade our version of Pluto 1.1 by simply replacing jar files.   
Pluto 1.0 could never have done that under any circumstances.

That said, the SPI is not perfect and will likely never be  
"perfect".   Each integration that I participated in had the effect of  
evolving and improving the SPI.

Sakai did not stress Pluto features so all Sakai needed from Pluto was  
a bit of re-factoring of the source tree to get the right things in  
jars (apis in an Api jar), implementation in implementation jars, and  
non-essential stuff somewhere else.

uPortal is a more functional portal than Sakai and needed to extend  
the SPI to make things work.  So we got together and jointly figured  
out what the SPI needs were from uPortal's perspective and made the  
changes.

There were tiny incompatible changes that caused Sakai to make slight  
changes - because we were kind of working together these changes were  
easily applied to Sakai - I used Sakai to QA several of the minor  
releases of Pluto.

Now of course the SPI will change yet again in 2.0 and I fully expect  
it.  Because we are using the jars, Sakai will have a solid 168  
implementation as long as we like without being affected by  
improvements in Pluto 2.0 and beyond.

I fully expect that a chunk of work will be needed on my part in Sakai  
to make it into Pluto 2.0 - Some of this might be simply because of  
JSR-286 and some of the work might be simply changing the SPI  
interface to meet the needs of Jetspeed.

So my feeling is that if it is Jetspeed's "turn" to grab Pluto 2.0 -  
you should feel OK if the SPI needs to change a bit - Jetspeed will  
have use cases beyond what the SPI supports - so the SPI evolves.   
That is what will make Pluto 2.0 really awesome and make Sakai's job  
of using Pluto 2.0 really easy because you will have done the "hard  
work" :)

Don't worry about us laggards - we can stick with what we have  
trivially or we can catch-up if we want.  Either way we will certainly  
benefit from the improvements that the Jetspeed work causes in the SPI.

Charles Severance
Unviersity of Michigan

>
> Ate Douma wrote:
>> Dear committers, community,
>>
>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168  
>> container, but we want and need to upgrade and migrate to the  
>> latest Pluto container under
>> development, aka the not yet released Pluto 2.0 targeted as the  
>> JSR-286 RI.
>>
>> This however is currently impossible to do because of the  
>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>
>> Technically, viewed from the POV of an easy to embed container for  
>> the Pluto Portal Driver, or environments which only need the out-of- 
>> the-box features
>> provided, these architectural changes have resulted in a much  
>> simpler and easier to understand and maintain model and API, and as  
>> such these changes were great!
>>
>> But... for a portal like Jetspeed-2, which provides a much enhanced  
>> usage and feature list *on container level*, these architectural  
>> changes have, simply put,
>> completely broken with the functional and technical "contract"  
>> provided by Pluto 1.0.x and as such make it now impossible for us  
>> to migrate to the current Pluto
>> container.

[Snip]

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Eric Dalquist <er...@doit.wisc.edu>]

Ate,

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

Ate Douma wrote:
> Dear committers, community,
>
> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
> but we want and need to upgrade and migrate to the latest Pluto 
> container under
> development, aka the not yet released Pluto 2.0 targeted as the 
> JSR-286 RI.
>
> This however is currently impossible to do because of the 
> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>
> Technically, viewed from the POV of an easy to embed container for the 
> Pluto Portal Driver, or environments which only need the 
> out-of-the-box features
> provided, these architectural changes have resulted in a much simpler 
> and easier to understand and maintain model and API, and as such these 
> changes were great!
>
> But... for a portal like Jetspeed-2, which provides a much enhanced 
> usage and feature list *on container level*, these architectural 
> changes have, simply put,
> completely broken with the functional and technical "contract" 
> provided by Pluto 1.0.x and as such make it now impossible for us to 
> migrate to the current Pluto
> container.
>
> As it is the primary mission and goal of the Pluto project to provide 
> an embeddable portlet container for portals like its Apache Portals 
> sibling project
> Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to 
> discuss what needs and can to be done, on both Jetspeed-2 and Pluto 
> side, to bring our
> projects back together, and how to restore the original *functional* 
> contract Pluto provided with version 1.0.x.
>
> To this end, we'll present our (short) assessment how the current 
> Pluto container API and implementation has changed and broken with the 
> old Pluto 1.0.x
> features which Jetspeed-2 depends upon to be able to maintain our 
> current Jetspeed-2 features, as well as what we think needs to be done 
> *functionally* to
> restore these features.
>
> To be very clear: we're not asking nor suggesting to restore the old 
> Pluto 1.0.x API and SPI as is. We fully expect and are willing to 
> adapt Jetspeed-2 to the
> new Pluto architecture as much as needed, even while that most likely 
> will now cause Jetspeed-2 itself to have to break with its own public 
> API and thus lose
> (some) backwards compatibility. After all, Pluto now has had several 
> releases based on its new Pluto 1.1.x architecture and we (as Apache 
> Portals community)
> have the obligation to maintain as much backwards compatibility for 
> the users of these versions as well.
>
> So, what we will propose later on is to work towards a solution which 
> will restore the ability for Jetspeed to properly use and embed the 
> new Pluto 2.0
> container but still maintain the lightweight and simple configuration 
> and usage of the container for portals like the Pluto Portal Driver 
> and other use-cases
> without breaking its current "contract".
>
> But first lets get down to some of the issues we have identified so 
> far. This is most likely not the complete list but covers the most 
> important ones.
>
> The Pluto 1.0.x object model API (OM)
> =====================================
> Pluto 1.0.x provided a fully interface based object model to represent 
> the web and portlet deployment descriptors (web.xml and portlet.xml).
> Through factory methods, the Pluto 1.0.x container only used these 
> interfaces in its implementation. That allowed Jetspeed and other 
> portals to supply its own
> implementation of the OM and use that to provide enhanced features 
> like database persistence, extended meta data, caching control, etc.
> Of course, Pluto 1.0.x also provided its own implementation classes of 
> the OM and Jetspeed uses these as base classes but provides extended 
> implementations to
> hook them up and into its own backend and management features.
>
> Pluto 1.1.x completely dropped all of this. Instead, a new descriptor 
> API was provided with a complete new set of classes (no interfaces!) 
> which are used and
> instantiated directly within the container with no factory support or 
> any other way of extending the current implementation.
> As such, the current container only allows usage of the web.xml and 
> portlet.xml descriptors and features derived from them as provided by 
> the container.
> Furthermore, as the loading and management of the descriptors is now 
> done directly (and only) by the container itself, there is no way for 
> Jetspeed to hook into
> this process anymore.
>
> Effectively, this means that descriptor persistence, caching, custom 
> extensions, *standard* support for custom portlet mode or window-state 
> mapping,
> etc. all no longer are possible with the current Pluto container. Not 
> just for Jetspeed but any portal needing and depending on these features.
We use make both custom portlet modes and window states available to 
deployed portlets and this functions as expected in Pluto 1.1, the 
descriptor objects provide information about which custom modes and 
states the portlet has declared.
>
> The Pluto 1.1.x/2.0 PortletContextManager, PortletDescriptorRegistry 
> and PortletServlet
> ======================================================================================= 
>
> With the switch to Pluto 1.1.x, the container added control and 
> management of the above mentioned deployment descriptors and fully 
> integrated them with the
> container interaction which now depend on this management 
> *implementation*, and also hooked that up on the portlet application 
> context.
> This means that now you need a separate container instance for each 
> portlet application and that the container itself loads and manages 
> the descriptors.
> Also, interaction with the container now requires the use of the Pluto 
> provided PortletServlet (although that one possibly can be extended) 
> as it is tied to the
> PortletContextManager directly (which in turn is tied to the 
> PortletDescriptorRegistry).
>
> Besides the obvious problem that this effectively blocks delegating 
> management of the context and descriptors for the portal, it also 
> forces the usage and
> interaction with portlets to the Pluto provided implementation.
> For instance, Pluto delegates interaction to each portlet through a 
> separate instance of its PortletServlet, while Jetspeed currently has 
> its own more generic
> JetspeedContainerServlet which is not tied to a single portlet. The 
> Jetspeed solution allows for dynamically enabling/adding portlets (as 
> defined in
> portlet.xml) without any need to rewrite the web.xml. But using the 
> Pluto PortletServlet requires changing the web.xml (and thus reloading 
> the context) to do so.
>
> The Pluto 1.1.x service provider interfaces (SPI)
> =================================================
> Although the new Pluto SPI (comprising of the 
> RequiredContainerServices and OptionalContainerServices) generally 
> provides a nice and simple interface to plugin
> portal specific implementations, certain features available with Pluto 
> 1.0.x are no longer available.
>
> With Pluto 1.0.x, critical components as the PortletContext and 
> PortletWindow were accessed by the container through factory classes.
> These no longer exist and the pluto container directly instantiates 
> its own implementations for these components.
You can provide your own PortletWindow impl. Since all container calls 
require a PortletWindow (interface) all callbacks simply provide this 
interface back to the handling code. We definitely have a custom 
PortletWindow implementation that tracks more information than the Pluto 
interface describes. It does look like there is no way to provide your 
own PortletContext impl.
>
> Jetspeed however very much depends on its own extensions of these 
> components to provide support for features like parallel rendering, 
> clustering and attaching
> additional meta data (or even preferences) to a PortletWindow or 
> PortletEntity.
> Additionally, while Pluto 1.0.x allowed managing multiple 
> PortletWindows for a PortletEntity, this *Portlet Spec* feature has 
> been removed from the current
> Pluto 1.1.x/2.0 container.
Again, I'm not sure the need for portlet container support for this. We 
use the DD objects as an easy way to know what is in the .xml objects. 
We then internally have our own portlet object model with a 
PortletDefinition (admin publishing a portlet), PortletEntity (user 
subscribing to portlet), PortletWindow (user viewing a portlet). Each 
definition can have N child entities and each entity can have N child 
windows. Each level in the model provides extra configuration data that 
we expose via the SPIs that we implement. We don't even bother with the 
Pluto PortletEntity interface since the only thing Pluto ever asks for 
is a PortletWindow.
>
> Lastly, not all of services referenced through these SPI interfaces 
> are only accessed through it.
> For instance, the OptionalContainerService.getPortletRegistryService() 
> is by default implemented by the PortletContextManager. But, this 
> implementation is very
> much directly used (as static instance even) within the container. 
> Effectively, the interface is now only an API portals might use, but 
> it cannot be replaced
> and thereby cannot be regarded as a proper SPI interface anymore.
This seems like a pretty big bug. While we didn't have a need for it I 
can very much see where moving the descriptor service behind a true SPI 
to allow implementers to write their own if they want would be a good thing.
>
> Solution
> ========
> As indicated earlier, solving the above issues such that Pluto 2.0 can 
> be made embeddable again, in Jetspeed or other portals, needs to be 
> done in a way which
> maintains backwards compatibility for current Pluto 1.1.x users.
>
> Although we don't have a clear proposal for this, our current idea is to:
> - define new OM interfaces to be implemented by the current descriptor 
> api classes
> - enhance the OptionalContainerServices SPI to provide additional 
> services for loading and managing the deployment descriptors
> - enhance the OptionalContainerServices SPI to provide additional 
> services for accessing components like PortletContext, PortletWindow etc.
> - refactor the container implementation to only use the OM interfaces
> - refactor the container implementation to only use the SPI provided 
> services and no longer directly binding to its service implementations
These all seem like great solutions and it seems to me they could be 
done with very minor changes required of people that have already 
implemented 1.1
>
> When done properly, the above changes should still allow using the 
> current implementation without any functional or even technical 
> consequence.
>
> Now, the above changes will mean a lot of work and lots of testing as 
> well to make sure everything remains working as expected.
> We, as primary Jetspeed committers have much at stake here so we are 
> definitely willing to help out and do much of the grunt work.
> And of course, we will have a large amount of work to do at Jetspeed 
> Portal side as well: all our Pluto Factory implementations have become 
> useless, all Pluto
> OM packages (and some interfaces) have changed, and we will need to 
> provide new implementations for the Pluto SPI container services.
We (uPortal Developers) can also be involved in this process to provide 
the perspective of another portal that does quite a bit with hooks into 
Pluto though it sounds like we do less than Jetspeed does.
>
> For our implementations of the Pluto SPI container services, we will 
> definitely look at the current Pluto provided implementations and 
> where possible try to
> make use of them as much as possible. To that end, we will probably 
> also need to be able to hook in our own extensions which might require 
> some additional
> refactoring but should not result in functional or technical changes 
> of the default Pluto services.
>
> Note: we want to migrate to Pluto 2.0 for our next Jetspeed 2.2 
> release. But, for that release we'll stick to only using the JSR-168 
> container features.
> Then, for the following major release, version 2.3 which we currently 
> have scheduled sometime this summer, we will provide full JSR-286 
> compliance.
> So, our initial goal is to get Pluto 2.0 working again with Jetspeed-2 
> but stick to our current features.
>
> This all is clearly not something which can be done or will be ready 
> overnight, nor possible to do all by ourselves.
> But we do need to start resolving this ASAP so it won't hold up the 
> release of both Pluto 2.0 and Jetspeed 2.2 longer than needed.
>
> As said: the above proposal is still just an idea. And of course how 
> to do all this, is fully open for debate and we are very interested in 
> hearing the opinions
> of other committers and community members (also from other portals 
> embedding Pluto 1.1.x).
>
> So please, provide feedback and ideas how to solve these issues. And 
> suggestions for alternative solutions will very much appreciated too!
This sounds like a great proposal. As I've said above uPortal has 
already gone through the pain (and yes there was some pain) of moving to 
Pluto 1.1 but the simplification of our portlet support code was more 
than worth it along with putting us in a position to more easily (we 
hope) move to Pluto 2.0. I would be more than happy to talk about the 
approaches uPortal has taken with using Pluto 1.1 and be involved with 
discussions about these upcoming changes to Pluto 1.1 to make it as 
useful as possible for other portals as well.
>
> With kind regards,
>
> Dennis Dam
> David Sean Taylor
> Ate Douma
>
>

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Carsten Ziegeler <cz...@apache.org>]

Some time ago I tried upgrading the Cocoon portal to Pluto 1.1.x but as 
everything is different compared to 1.0.1 I simply stopped the migration.

Without going into all the details the proposed changes sound very good 
to me. Cocoon uses its own OM classes and own servlet for calling 
portlets as well, so these seem to be substantial requirements.

I don't think that we really need to care that much about compatibility 
to 1.1.x - it's a 2.0 version :) Of course we should try to be as 
compatible as possible.

I haven't done anything with Pluto for a long time, the only code base I 
know is 1.0.x :(

Carsten

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


-- 
Carsten Ziegeler
cziegeler@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Ate Douma <at...@douma.nu>]

David Jencks wrote:
> My comments below are based on not having looked at the pluto 1.1 
> implementation at all and the pluto 1.0.x implementation years ago.
> 
> On Feb 8, 2008, at 11:18 AM, Ate Douma wrote:
> 
>> Dear committers, community,
>>
>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
>> but we want and need to upgrade and migrate to the latest Pluto 
>> container under
>> development, aka the not yet released Pluto 2.0 targeted as the 
>> JSR-286 RI.
>>
>> This however is currently impossible to do because of the 
>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>>
>> Technically, viewed from the POV of an easy to embed container for the 
>> Pluto Portal Driver, or environments which only need the 
>> out-of-the-box features
>> provided, these architectural changes have resulted in a much simpler 
>> and easier to understand and maintain model and API, and as such these 
>> changes were great!
>>
>> But... for a portal like Jetspeed-2, which provides a much enhanced 
>> usage and feature list *on container level*, these architectural 
>> changes have, simply put,
>> completely broken with the functional and technical "contract" 
>> provided by Pluto 1.0.x and as such make it now impossible for us to 
>> migrate to the current Pluto
>> container.
>>
>> As it is the primary mission and goal of the Pluto project to provide 
>> an embeddable portlet container for portals like its Apache Portals 
>> sibling project
>> Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to 
>> discuss what needs and can to be done, on both Jetspeed-2 and Pluto 
>> side, to bring our
>> projects back together, and how to restore the original *functional* 
>> contract Pluto provided with version 1.0.x.
>>
>> To this end, we'll present our (short) assessment how the current 
>> Pluto container API and implementation has changed and broken with the 
>> old Pluto 1.0.x
>> features which Jetspeed-2 depends upon to be able to maintain our 
>> current Jetspeed-2 features, as well as what we think needs to be done 
>> *functionally* to
>> restore these features.
>>
>> To be very clear: we're not asking nor suggesting to restore the old 
>> Pluto 1.0.x API and SPI as is. We fully expect and are willing to 
>> adapt Jetspeed-2 to the
>> new Pluto architecture as much as needed, even while that most likely 
>> will now cause Jetspeed-2 itself to have to break with its own public 
>> API and thus lose
>> (some) backwards compatibility. After all, Pluto now has had several 
>> releases based on its new Pluto 1.1.x architecture and we (as Apache 
>> Portals community)
>> have the obligation to maintain as much backwards compatibility for 
>> the users of these versions as well.
>>
>> So, what we will propose later on is to work towards a solution which 
>> will restore the ability for Jetspeed to properly use and embed the 
>> new Pluto 2.0
>> container but still maintain the lightweight and simple configuration 
>> and usage of the container for portals like the Pluto Portal Driver 
>> and other use-cases
>> without breaking its current "contract".
>>
>> But first lets get down to some of the issues we have identified so 
>> far. This is most likely not the complete list but covers the most 
>> important ones.
>>
>> The Pluto 1.0.x object model API (OM)
>> =====================================
>> Pluto 1.0.x provided a fully interface based object model to represent 
>> the web and portlet deployment descriptors (web.xml and portlet.xml).
>> Through factory methods, the Pluto 1.0.x container only used these 
>> interfaces in its implementation. That allowed Jetspeed and other 
>> portals to supply its own
>> implementation of the OM and use that to provide enhanced features 
>> like database persistence, extended meta data, caching control, etc.
>> Of course, Pluto 1.0.x also provided its own implementation classes of 
>> the OM and Jetspeed uses these as base classes but provides extended 
>> implementations to
>> hook them up and into its own backend and management features.
>>
>> Pluto 1.1.x completely dropped all of this. Instead, a new descriptor 
>> API was provided with a complete new set of classes (no interfaces!) 
>> which are used and
>> instantiated directly within the container with no factory support or 
>> any other way of extending the current implementation.
>> As such, the current container only allows usage of the web.xml and 
>> portlet.xml descriptors and features derived from them as provided by 
>> the container.
>> Furthermore, as the loading and management of the descriptors is now 
>> done directly (and only) by the container itself, there is no way for 
>> Jetspeed to hook into
>> this process anymore.
>>
>> Effectively, this means that descriptor persistence, caching, custom 
>> extensions, *standard* support for custom portlet mode or window-state 
>> mapping,
>> etc. all no longer are possible with the current Pluto container. Not 
>> just for Jetspeed but any portal needing and depending on these features.
> 
> I suggest that there be a very clear separation between deployment code 
> that might look at web.xml, portlet.xml, annotations, or some other 
> source and use these to construct objects describing the portlets, and 
> the "engine" that "runs" these objects.  Rewriting the deployment code 
> to create your own objects is pretty simple and lets you just use 
> objects without needing the complexity of interfaces or factories.  
> Also, everyone has their favorite xml technology and this lets you 
> replace whatever pluto might choose with one you like better.  I've done 
> this with the jetty integration in geronimo and like the results.
Agreed, and that is more or less what I propose.
I have no problem with a basic runtime object model api based on the formal deployment descriptor structure, nor with an implementation which just and only uses 
that model for management at runtime. As long as these two are separated and a different implementation can be provided too.

> 
>>
>> 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.
> 
> I don't think I'll understand this issue without studying the code 
> extensively.  However, from this description it looks like perhaps the 
> "deploy time" translation of xml/annotations to more descriptive 
> internally usable objects is too tied to the "execution" of these 
> objects? 
Exactly, to be precise: I guess up to 100% so.

> I'd expect there would be some kind of 
> "PortletApplicationContext" object that would have a collection of 
> Portlet objects and you could programatically add more Portlet objects 
> to it.  If there is enough separation between the deploy time and run 
> time code this should not be a problem even if the Portlet object didn't 
> come from xml.
In Jetspeed we call that the "Registry" which we seed initially from our own parsing of the deployment descriptors after which we don't even look back at the 
descriptors for runtime access to the "managed" objects in the Registry.

> 
> I don't see a necessary problem with the PortletApplicationContext being 
> the container instance if this simplifies the code. 
Jetspeed provides a centralized management of the Registry across portlet applications, even while they are offline.

> I don't have a 
> strong opinion on the 
> servlet-per-portlet/servelt-per-portlet-application question: it seems 
> to me that with an appropriate servlet container that allows adding 
> servlets to a running web app they would have the same capabilities and 
> each would make some features easier to implement.  For instance adding 
> a servlet to a running web app is harder than not adding it, but 
> implementing portlet role permissions seems easier to me with a 
> servlet-per-portlet approach.
The portlet context is not managed by the web container but the portlet container. As we are (or want to be) in control of the portlet container, managing those 
type of features on the fly is much easier than trying to hook into the web container which might be quite different (or even impossible) depending on the 
product (e.g. Tomcat/Jetty/OC4J/Websphere/Bea etc.)

>>
>> 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.
>>
> 
> Here the long time since I've studied this code is really hurting me.   
> IIRC this all relates to classes that describe a portlet's environment 
> at runtime that are populated by the portal (e.g. jetspeed) and used by  
> the portlet container (pluto) or populated by both the portal and 
> portlet container and used by both.
> 
> Basically what I'd like to see is a strongly typed system (no fishing 
> for services in 6 levels of nested hash maps) based entirely on 
> dependency injection.
> 
> Objects describing the portlet app injected into the portlet container 
> by some deployment system, either plutos or something else
> Environment information supplied by the portal injected from the portal
> Objects that need to be created by the portlet container that also need 
> to be customized for the portal environment created by factories 
> injected by the portal environment.  (I don't really understand how this 
> can be necessary, but if it is then a factory seems like the way to do it).
> 
> 
>> 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.
> 
> Is this really a requirement?  If a substantial improvement can be made 
> in the design I wonder if backwards compatibility is essential.
Well, for Jetspeed-2 itself it wouldn't really matter as we never did embed Pluto 1.1.x

But there are others who do and I think it is important for our community not to break backwards compatibility if not really necessary.
Pluto 2.0 is still also a JSR-168 container too, so for users who don't need JSR-286 but would like to upgrade for general improvements/fixes, backwards 
compatibility is very much important.

Of course, if nobody thinks backwards compatibility is important, I would have no problem with breaking it either.
But I don't think this is/will be the case (e.g. like for uPortal, see Eric Dalquist his reply too).
> 
>>
>> 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).
>>
>> So please, provide feedback and ideas how to solve these issues. And 
>> suggestions for alternative solutions will very much appreciated too
>>
>> With kind regards,
>>
>> Dennis Dam
>> David Sean Taylor
>> Ate Douma
>>
> 
> I hope my partially-informed opinions are helpful and not overly 
> intrusive.
David, your opinions and insight always have been and I expect always will be very helpful and are very much appreciated.

> Unfortunately I can't promise I'll have much time to 
> actually study the code soon, but I am certainly hoping to.  I'll 
> certainly try to explain what I'm talking about more if anyone is 
> interested.
Thanks a lot David, we're interested :)

Regards,

Ate

> 
> thanks
> david jencks
> 
>>
> 
> 

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[David Jencks <da...@yahoo.com>]

My comments below are based on not having looked at the pluto 1.1  
implementation at all and the pluto 1.0.x implementation years ago.

On Feb 8, 2008, at 11:18 AM, Ate Douma wrote:

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

I suggest that there be a very clear separation between deployment  
code that might look at web.xml, portlet.xml, annotations, or some  
other source and use these to construct objects describing the  
portlets, and the "engine" that "runs" these objects.  Rewriting the  
deployment code to create your own objects is pretty simple and lets  
you just use objects without needing the complexity of interfaces or  
factories.  Also, everyone has their favorite xml technology and this  
lets you replace whatever pluto might choose with one you like  
better.  I've done this with the jetty integration in geronimo and  
like the results.

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

I don't think I'll understand this issue without studying the code  
extensively.  However, from this description it looks like perhaps  
the "deploy time" translation of xml/annotations to more descriptive  
internally usable objects is too tied to the "execution" of these  
objects?  I'd expect there would be some kind of  
"PortletApplicationContext" object that would have a collection of  
Portlet objects and you could programatically add more Portlet  
objects to it.  If there is enough separation between the deploy time  
and run time code this should not be a problem even if the Portlet  
object didn't come from xml.

I don't see a necessary problem with the PortletApplicationContext  
being the container instance if this simplifies the code.  I don't  
have a strong opinion on the servlet-per-portlet/servelt-per-portlet- 
application question: it seems to me that with an appropriate servlet  
container that allows adding servlets to a running web app they would  
have the same capabilities and each would make some features easier  
to implement.  For instance adding a servlet to a running web app is  
harder than not adding it, but implementing portlet role permissions  
seems easier to me with a servlet-per-portlet approach.
>
> 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.
>

Here the long time since I've studied this code is really hurting  
me.   IIRC this all relates to classes that describe a portlet's  
environment at runtime that are populated by the portal (e.g.  
jetspeed) and used by  the portlet container (pluto) or populated by  
both the portal and portlet container and used by both.

Basically what I'd like to see is a strongly typed system (no fishing  
for services in 6 levels of nested hash maps) based entirely on  
dependency injection.

Objects describing the portlet app injected into the portlet  
container by some deployment system, either plutos or something else
Environment information supplied by the portal injected from the portal
Objects that need to be created by the portlet container that also  
need to be customized for the portal environment created by factories  
injected by the portal environment.  (I don't really understand how  
this can be necessary, but if it is then a factory seems like the way  
to do it).


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

Is this really a requirement?  If a substantial improvement can be  
made in the design I wonder if backwards compatibility is essential.

>
> 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).
>
> So please, provide feedback and ideas how to solve these issues.  
> And suggestions for alternative solutions will very much  
> appreciated too
>
> With kind regards,
>
> Dennis Dam
> David Sean Taylor
> Ate Douma
>

I hope my partially-informed opinions are helpful and not overly  
intrusive.   Unfortunately I can't promise I'll have much time to  
actually study the code soon, but I am certainly hoping to.  I'll  
certainly try to explain what I'm talking about more if anyone is  
interested.

thanks
david jencks

>

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Eric Dalquist <er...@doit.wisc.edu>]

Ate,

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

Ate Douma wrote:
> Dear committers, community,
>
> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168 container, 
> but we want and need to upgrade and migrate to the latest Pluto 
> container under
> development, aka the not yet released Pluto 2.0 targeted as the 
> JSR-286 RI.
>
> This however is currently impossible to do because of the 
> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>
> Technically, viewed from the POV of an easy to embed container for the 
> Pluto Portal Driver, or environments which only need the 
> out-of-the-box features
> provided, these architectural changes have resulted in a much simpler 
> and easier to understand and maintain model and API, and as such these 
> changes were great!
>
> But... for a portal like Jetspeed-2, which provides a much enhanced 
> usage and feature list *on container level*, these architectural 
> changes have, simply put,
> completely broken with the functional and technical "contract" 
> provided by Pluto 1.0.x and as such make it now impossible for us to 
> migrate to the current Pluto
> container.
>
> As it is the primary mission and goal of the Pluto project to provide 
> an embeddable portlet container for portals like its Apache Portals 
> sibling project
> Jetspeed-2, it is our view (as Jetspeed-2 committers) that we need to 
> discuss what needs and can to be done, on both Jetspeed-2 and Pluto 
> side, to bring our
> projects back together, and how to restore the original *functional* 
> contract Pluto provided with version 1.0.x.
>
> To this end, we'll present our (short) assessment how the current 
> Pluto container API and implementation has changed and broken with the 
> old Pluto 1.0.x
> features which Jetspeed-2 depends upon to be able to maintain our 
> current Jetspeed-2 features, as well as what we think needs to be done 
> *functionally* to
> restore these features.
>
> To be very clear: we're not asking nor suggesting to restore the old 
> Pluto 1.0.x API and SPI as is. We fully expect and are willing to 
> adapt Jetspeed-2 to the
> new Pluto architecture as much as needed, even while that most likely 
> will now cause Jetspeed-2 itself to have to break with its own public 
> API and thus lose
> (some) backwards compatibility. After all, Pluto now has had several 
> releases based on its new Pluto 1.1.x architecture and we (as Apache 
> Portals community)
> have the obligation to maintain as much backwards compatibility for 
> the users of these versions as well.
>
> So, what we will propose later on is to work towards a solution which 
> will restore the ability for Jetspeed to properly use and embed the 
> new Pluto 2.0
> container but still maintain the lightweight and simple configuration 
> and usage of the container for portals like the Pluto Portal Driver 
> and other use-cases
> without breaking its current "contract".
>
> But first lets get down to some of the issues we have identified so 
> far. This is most likely not the complete list but covers the most 
> important ones.
>
> The Pluto 1.0.x object model API (OM)
> =====================================
> Pluto 1.0.x provided a fully interface based object model to represent 
> the web and portlet deployment descriptors (web.xml and portlet.xml).
> Through factory methods, the Pluto 1.0.x container only used these 
> interfaces in its implementation. That allowed Jetspeed and other 
> portals to supply its own
> implementation of the OM and use that to provide enhanced features 
> like database persistence, extended meta data, caching control, etc.
> Of course, Pluto 1.0.x also provided its own implementation classes of 
> the OM and Jetspeed uses these as base classes but provides extended 
> implementations to
> hook them up and into its own backend and management features.
>
> Pluto 1.1.x completely dropped all of this. Instead, a new descriptor 
> API was provided with a complete new set of classes (no interfaces!) 
> which are used and
> instantiated directly within the container with no factory support or 
> any other way of extending the current implementation.
> As such, the current container only allows usage of the web.xml and 
> portlet.xml descriptors and features derived from them as provided by 
> the container.
> Furthermore, as the loading and management of the descriptors is now 
> done directly (and only) by the container itself, there is no way for 
> Jetspeed to hook into
> this process anymore.
>
> Effectively, this means that descriptor persistence, caching, custom 
> extensions, *standard* support for custom portlet mode or window-state 
> mapping,
> etc. all no longer are possible with the current Pluto container. Not 
> just for Jetspeed but any portal needing and depending on these features.
We use make both custom portlet modes and window states available to 
deployed portlets and this functions as expected in Pluto 1.1, the 
descriptor objects provide information about which custom modes and 
states the portlet has declared.
>
> The Pluto 1.1.x/2.0 PortletContextManager, PortletDescriptorRegistry 
> and PortletServlet
> ======================================================================================= 
>
> With the switch to Pluto 1.1.x, the container added control and 
> management of the above mentioned deployment descriptors and fully 
> integrated them with the
> container interaction which now depend on this management 
> *implementation*, and also hooked that up on the portlet application 
> context.
> This means that now you need a separate container instance for each 
> portlet application and that the container itself loads and manages 
> the descriptors.
> Also, interaction with the container now requires the use of the Pluto 
> provided PortletServlet (although that one possibly can be extended) 
> as it is tied to the
> PortletContextManager directly (which in turn is tied to the 
> PortletDescriptorRegistry).
>
> Besides the obvious problem that this effectively blocks delegating 
> management of the context and descriptors for the portal, it also 
> forces the usage and
> interaction with portlets to the Pluto provided implementation.
> For instance, Pluto delegates interaction to each portlet through a 
> separate instance of its PortletServlet, while Jetspeed currently has 
> its own more generic
> JetspeedContainerServlet which is not tied to a single portlet. The 
> Jetspeed solution allows for dynamically enabling/adding portlets (as 
> defined in
> portlet.xml) without any need to rewrite the web.xml. But using the 
> Pluto PortletServlet requires changing the web.xml (and thus reloading 
> the context) to do so.
>
> The Pluto 1.1.x service provider interfaces (SPI)
> =================================================
> Although the new Pluto SPI (comprising of the 
> RequiredContainerServices and OptionalContainerServices) generally 
> provides a nice and simple interface to plugin
> portal specific implementations, certain features available with Pluto 
> 1.0.x are no longer available.
>
> With Pluto 1.0.x, critical components as the PortletContext and 
> PortletWindow were accessed by the container through factory classes.
> These no longer exist and the pluto container directly instantiates 
> its own implementations for these components.
You can provide your own PortletWindow impl. Since all container calls 
require a PortletWindow (interface) all callbacks simply provide this 
interface back to the handling code. We definitely have a custom 
PortletWindow implementation that tracks more information than the Pluto 
interface describes. It does look like there is no way to provide your 
own PortletContext impl.
>
> Jetspeed however very much depends on its own extensions of these 
> components to provide support for features like parallel rendering, 
> clustering and attaching
> additional meta data (or even preferences) to a PortletWindow or 
> PortletEntity.
> Additionally, while Pluto 1.0.x allowed managing multiple 
> PortletWindows for a PortletEntity, this *Portlet Spec* feature has 
> been removed from the current
> Pluto 1.1.x/2.0 container.
Again, I'm not sure the need for portlet container support for this. We 
use the DD objects as an easy way to know what is in the .xml objects. 
We then internally have our own portlet object model with a 
PortletDefinition (admin publishing a portlet), PortletEntity (user 
subscribing to portlet), PortletWindow (user viewing a portlet). Each 
definition can have N child entities and each entity can have N child 
windows. Each level in the model provides extra configuration data that 
we expose via the SPIs that we implement. We don't even bother with the 
Pluto PortletEntity interface since the only thing Pluto ever asks for 
is a PortletWindow.
>
> Lastly, not all of services referenced through these SPI interfaces 
> are only accessed through it.
> For instance, the OptionalContainerService.getPortletRegistryService() 
> is by default implemented by the PortletContextManager. But, this 
> implementation is very
> much directly used (as static instance even) within the container. 
> Effectively, the interface is now only an API portals might use, but 
> it cannot be replaced
> and thereby cannot be regarded as a proper SPI interface anymore.
This seems like a pretty big bug. While we didn't have a need for it I 
can very much see where moving the descriptor service behind a true SPI 
to allow implementers to write their own if they want would be a good thing.
>
> Solution
> ========
> As indicated earlier, solving the above issues such that Pluto 2.0 can 
> be made embeddable again, in Jetspeed or other portals, needs to be 
> done in a way which
> maintains backwards compatibility for current Pluto 1.1.x users.
>
> Although we don't have a clear proposal for this, our current idea is to:
> - define new OM interfaces to be implemented by the current descriptor 
> api classes
> - enhance the OptionalContainerServices SPI to provide additional 
> services for loading and managing the deployment descriptors
> - enhance the OptionalContainerServices SPI to provide additional 
> services for accessing components like PortletContext, PortletWindow etc.
> - refactor the container implementation to only use the OM interfaces
> - refactor the container implementation to only use the SPI provided 
> services and no longer directly binding to its service implementations
These all seem like great solutions and it seems to me they could be 
done with very minor changes required of people that have already 
implemented 1.1
>
> When done properly, the above changes should still allow using the 
> current implementation without any functional or even technical 
> consequence.
>
> Now, the above changes will mean a lot of work and lots of testing as 
> well to make sure everything remains working as expected.
> We, as primary Jetspeed committers have much at stake here so we are 
> definitely willing to help out and do much of the grunt work.
> And of course, we will have a large amount of work to do at Jetspeed 
> Portal side as well: all our Pluto Factory implementations have become 
> useless, all Pluto
> OM packages (and some interfaces) have changed, and we will need to 
> provide new implementations for the Pluto SPI container services.
We (uPortal Developers) can also be involved in this process to provide 
the perspective of another portal that does quite a bit with hooks into 
Pluto though it sounds like we do less than Jetspeed does.
>
> For our implementations of the Pluto SPI container services, we will 
> definitely look at the current Pluto provided implementations and 
> where possible try to
> make use of them as much as possible. To that end, we will probably 
> also need to be able to hook in our own extensions which might require 
> some additional
> refactoring but should not result in functional or technical changes 
> of the default Pluto services.
>
> Note: we want to migrate to Pluto 2.0 for our next Jetspeed 2.2 
> release. But, for that release we'll stick to only using the JSR-168 
> container features.
> Then, for the following major release, version 2.3 which we currently 
> have scheduled sometime this summer, we will provide full JSR-286 
> compliance.
> So, our initial goal is to get Pluto 2.0 working again with Jetspeed-2 
> but stick to our current features.
>
> This all is clearly not something which can be done or will be ready 
> overnight, nor possible to do all by ourselves.
> But we do need to start resolving this ASAP so it won't hold up the 
> release of both Pluto 2.0 and Jetspeed 2.2 longer than needed.
>
> As said: the above proposal is still just an idea. And of course how 
> to do all this, is fully open for debate and we are very interested in 
> hearing the opinions
> of other committers and community members (also from other portals 
> embedding Pluto 1.1.x).
>
> So please, provide feedback and ideas how to solve these issues. And 
> suggestions for alternative solutions will very much appreciated too!
This sounds like a great proposal. As I've said above uPortal has 
already gone through the pain (and yes there was some pain) of moving to 
Pluto 1.1 but the simplification of our portlet support code was more 
than worth it along with putting us in a position to more easily (we 
hope) move to Pluto 2.0. I would be more than happy to talk about the 
approaches uPortal has taken with using Pluto 1.1 and be involved with 
discussions about these upcoming changes to Pluto 1.1 to make it as 
useful as possible for other portals as well.
>
> With kind regards,
>
> Dennis Dam
> David Sean Taylor
> Ate Douma
>
>

Re: Embeddable Pluto 2.0 container for Jetspeed-2

[Elliot Metsger <em...@jhu.edu>]

Sorry Ate, everyone, for the delayed response.  Life happens, right? :)

First I am totally supportive of getting Pluto 2 to work with JS.  The 
rest is just details :)  I know there are other projects (uPortal, 
Sakai) which have migrated to and embedded (respectively) Pluto 1.1.

Ate Douma wrote:

<snip>

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

Here are my comments on the Descriptor OM.  There was an intentional 
design decision made with the 1.1 descriptor om: specifically that no 
behaviors or responsibilities are attached to model.  The model is 
orthogonal to the behaviors.  Restricting the OM to what are essentially 
just beans or value objects makes it easy for embedders: they aren't 
forced to implement a bunch of interfaces.  And if they want additional 
behaviors like persistence they can add them in the portal implementation.

uPortal for example (and Eric correct me if I'm wrong) has a relatively 
straight forward model of portlet -windows, -entities, -deployments, and 
applications and has a hibernate-based implementation for persisting them.

A little off topic, I think there improvments that need to be made to 
the descriptor impl - Eric Dalquist has some good ideas.  The goal there 
being to load the descriptor impl from the webapp classloader instead of 
having to pollute a shared classloader with the descriptor impl and all 
of its dependencies.


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

I'm not sure what you mean here.  Generally the pluto container, along 
with the descriptor api and impl are deployed in a shared classloader, 
so you only need one instance.

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

What about Jetspeed providing its own "PortletServlet" implementation. 
The portlet servlet is pretty simple, initing the portlet, fixing up the 
request and response and dispatching to the container.  You'll need to 
have the assembler use your servlet implementation when assembling web.xml.

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

Normally the container will sit in a shared classloader, so there is 
only a single instance of PortletServlet in a JVM.  When PortletServlet 
is initialized, it registers the available portlets with the 
RegistryService.

The Registry Service is an interface and a portal can have its own 
implementation.  You can dynamically register new portlets on the 
registry service.

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

Let me come back on this issue, I need to look at the code a bit more to 
understand.  I do see where PCM is used instead of the interface.  It 
may be easy to switch to using the interface.  E.g. PortletContainerImpl 
already has a reference to OptionalContainerServices so looking up the 
Registry Service by interface instead of instantiating PCM directly 
should be doable.  There may be classloader issue.

In general there should be a way to inject the impl that you require. 
If there isn't a way, there's definintly a problem that we need to 
design/code a solution to.

> 
> Solution
> ========

I gotta run now but I'd like to take some more time and reply in more 
detail, icluding commenting on the solution.

Thanks Ate and JS team for bringing these issues up!

Elliot

> 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).
> 
> So please, provide feedback and ideas how to solve these issues. And 
> suggestions for alternative solutions will very much appreciated too!
> 
> With kind regards,
> 
> Dennis Dam
> David Sean Taylor
> Ate Douma
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org