PortletInvokerServiceImpl in pluto-portal-driver?

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

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.

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?

-Eric

Re: PortletInvokerServiceImpl in pluto-portal-driver?

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

On 03/11/2010 02:58 AM, Ate Douma wrote:
> 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?
Yes, sorry I was writing the email from memory at home.
>
>>
>> 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.

Thanks for the detailed explanation, it verified what I thought was 
going on with the separation of concerns between the libraries. For now 
we'll just include the pluto-portal-driver JAR, once we get closer to a 
uPortal release I'll probably have some proposals for how to better 
organize the pluto-portal-driver package. I definitely see a value of 
the current organization of the container-api and container JARs. I 
think I'd like to further move things around by moving some of the code 
that is very specific to the driver and all configuration in 
pluto-portal-driver into pluto-portal-driver-impl. That would let 
pluto-portal-driver be used for some default service implementations for 
portals like uPortal that want to override a lot of the service 
callbacks but have no need to re-implement the cross-context dispatching 
approach that Pluto 1.1 and the Pluto 2 driver uses or other things 
viewed as more 'core container' services.

I won't plan on making any changes until after a 2.0.1 release and of 
course would run any changes by this list first. Perhaps with moving 
things around between packages it should be considered a 2.1 release.

Thanks again for the detailed response,
-Eric

>
> Regards,
>
> Ate
>
>>
>> -Eric
>>
>

Re: PortletInvokerServiceImpl in pluto-portal-driver?

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

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
>