cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject RE: Portal - PortletDefinitionRegistryImpl question
Date Fri, 27 Aug 2004 06:29:59 GMT
At 8/26/2004  11:19 PM, you wrote:

>A JSR-168 portlet (or a set of them) is a complete webapp plus
>a configuration file! Pluto and therefore Cocoon uses the
>easiest way to handle this by using the servlet engine to
>deploy those portlet webapps - I don't know how other
>portal engines do it.

Yes. But I was under the impression that the portlet.xml file would exist 
within the Cocoon webapp along with all the portlets.


> >
> > Also, how does that actually work?  How does the portlet run
> > if it needs jars from the other webapp? Wouldn't you get a
> > ClassNotFoundException?
>You don't need classes etc. If a portlet is used the request
>is forwarded to the portlet webapp.
>
>So, currently only looking in the Cocoon war would break
>the JSR-168 feature.
>If you don't need JSR-168 portlets, you can use a different
>portal manager and turn off the support.

I'm not sure why that would break anything. My reading of the spec led me 
to believe that a Portal is a single webapp with all portlets deployed 
within it.  In this case, all the portlets would have to exist within the 
war.  I absolutely need the support, but I was planning on packaging all 
the available portlets inside the war.


>However, the best solution would be a deployment functionality
>for JSR-168 in Cocoon.

Do you have any suggestions on how this could be accomplished?  I'd be 
happy to implement it, but using the services available to servlets I'm not 
sure how to do that.  In fact, because our war is packaged in an ear I 
can't even find out the context path during initialization.


>Carsten





Mime
View raw message