portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: Portlet Container Integration
Date Tue, 08 Nov 2005 02:06:41 GMT


Ate Douma wrote:
> David H. DeWolf wrote:
> 
>> Hello Jetspeed!
>>
>> I've taken a cursory glance at jetspeed's integration with pluto to 
>> start thinking about the migration of jetspeed to pluto 1.1.  
> 
> Great! Looking forward working with you on that. After the 2.0-FINAL 
> release ;-)

Absolutely.  For right now I'm just focusing on trying to make sure that 
pluto has all of our basis are covered.

> 
> I noticed
> 
>> a few things that I found interesting and was wondering if I could 
>> gather some feedback from those of you that are more familiar with 
>> jetspeed.
>>
>> Of particular interest was the fact that you use more than one invoker 
>> implementation.  I was rather surprised by this simply because IMHO 
>> the invoker itself is at the core of the container implementation.  
>> That said, once I dove a little deeper I found that this is required 
>> in order to support some sort of "hot deployment" feature where the 
>> portal picks up potlet apps which are placed in a specific directory.  
>> Is this correct?
> 
> No quite.
> We support internal (local) and external portlets.
> Local portlets run within the context of the portal itself.
> As that requires a complete different handling (in fact, somewhat easier)
> of classloading, the two ways are handled by different invokers.

So for the internal invoker - do you basically implement the servlet 
spec yourselves - or do the portlet apps somehow get "unpacked" into the 
local context so that resources can be served by the app servers servlet 
container?

> 
>>
>> If so, would you mind providing an overview of how you support the 
>> rest of the servlet specification (as required by the portlet spec) 
>> without deploying the portlet apps directly in the app server?
> 
> The external invoker (ServletPortletInvoker) is much like the one in 
> Pluto Portal.

As of right now, in 1.1, having this second invoker would be 
accomplished by having a second embeded container.  Do you see a problem 
with this approach?

> 
>>
>> In addition to this, if any of you have a chance to take a look at 
>> pluto 1.1 (now the trunk) and provide any feedback regarding any other 
>> "big holes" that you see preventing jetspeeds migration to 1.1, it 
>> would be very appreciated.
> 
> I'd like to do so as soon as I get my hands free.
> But I'm afraid it'll have to wait until after ApacheCON from my account 
> as I
> still need to prepare for our presentation there (as co-speaker of David 
> Taylor)
> and the rest of my time will have to go into the 2.0-FINAL release.

Excellent. I'll look forward to meeting both of you there.  I'll be 
presenting on embedding 1.1. . .

> After that, I'm all ears to look into pluto 1.1.

Thanks,

David

> 
> Regards,
> 
> Ate
> 
>>
>> Thanks,
>>
>> David
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
>>
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 


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


Mime
View raw message