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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
