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
