portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Dalquist <eric.dalqu...@doit.wisc.edu>
Subject Re: PortletInvokerServiceImpl in pluto-portal-driver?
Date Thu, 11 Mar 2010 17:07:09 GMT
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,

> Regards,
> Ate
>> -Eric

View raw message