portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Portlet Container Integration
Date Tue, 08 Nov 2005 23:53:14 GMT
David H. DeWolf wrote:
> 
> 
> 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?
The local portlets (currently only used for our layout portlets) are loaded
with a custom classloader with has the portal classloader as parent.
So, these run within the portal 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?
I'm not sure I understand what you mean by "second" container. But then,
I haven't looked into Pluto 1.1 at all, so please forgive my ignorance.
I really can't tell yet if that would be a problem or not.
> 
>>
>>>
>>> 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. . .
I haven't decided yet which sessions I will join, but I certainly look
forward meeting you there.

> 
>> 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
> 
> 
> 
> 
> 



---------------------------------------------------------------------
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