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
