On 03/10/2010 11:58 PM, Eric Dalquist wrote:
I'm working on upgrading uPortal to Pluto 2.0 and had a question about
how the code is split up. The embedding documentation and what I know
about Pluto implies that a full portal shouldn't need to depend on
anything from the pluto-portal-driver JAR. That said it seems like a lot
of the default implementations of the core Pluto services live in the
JAR, most critically PortletInvokerServiceImpl which seems onerous for a
portal to re-implement since its functionality is tightly coupled to the
portlet invoking servlet.
I think you mean o.a.pluto.driver.container.DefaultPortletInvokerService,
right?
Is the intent that portals embedding Pluto reference code from
pluto-portal-driver or should some of these default service
implementations be moved into the container impl?
The pluto container handling and wrapping has been split up in two levels and you have to make a choice on which level you'll need to
integrate it.
The core pluto container (only) should be used if your portal needs and wants full
control of how portlets "live" and are managed within it.
It assumes *nothing* about how the "registry", lifecycle or for instance preferences etc. are managed or how portlets are invoked (e.g.
PortletInvokerService) but fully delegates that back to the portal.
The pluto driver container builds on this core container by providing a minimal level of *example* handling for this, suitable enough for
(at least) the Pluto Portal Driver *testing* portal. It allows one to provide only have to provide basic service support from the embedding
portal as the Pluto Portal Driver does.
I agree the pluto driver container might not yet provide the cleanest, most flexible sort of configurations, however you still can override
and provide some critical features if you want: it allows Spring based configuration management as Pluto Portal Driver uses too.
However, the primary goal for Pluto 2.0 was to make sure the core container was fully JSR-286 compliant and properly embeddable in a portal
like Jetspeed, which *does* need to manage all of the container infrastructure by itself.
As in the example of the portlet invoker, Jetspeed uses a different invocation approach, only needing a single "container" servlet per web
app, unlike the Pluto invoker servlet which is (and needs to be) configured for each individual portlet which is cumbersome if you need to
add new portlets on the fly as we can do with Jetspeed.
The Pluto Portal Driver, and thereby the portal driver container merely serve as example and as testbed to ensure the JSR-286 TCK can be run
and validated properly, nothing more.
If you intend to use the portal driver container but need more flexibility, I think it shouldn't be too hard to further componentize it to
allow more fine-grained overrides and extension points.
However moving portal driver container services into the core container really would break the clean separation of concerns setup right now.
For Jetspeed-2 we don't need those as we provide our own already and therefore don't want such "example" services in there either.
Changes in the portal driver container however are fine and won't affect us at
all.
Important note: we're planning to do a new Jetspeed-2 2.2.1 release very soon
for which we'll need a new Pluto 2.0.1 release as well.
There are a few remaining outstanding issues recorded against 2.0.1, most of which I think can be closed or moved to a new Pluto 2.0.2 (or
later) version.
If you intend to start major changes for the pluto portal driver, is it possible to hold those off for a few more weeks (say April) so we
can wrap up the 2.0.1 release first? Otherwise I propose to create a temporary branch for Pluto 2.0.2 which we then can merge back to trunk
after the release.
Regards,
Ate
-Eric
