I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago....
Now, the better way imho would be if the portlets would run "inside of Cocoon" rather than "inside of Tomcat". So, you deploy your portlet wars into your Cocoon war (or a totally different place) and you don't have to deploy the portlets as usual web applications in your servlet engine. I think this should be possible, but of course needs some work to be done. Apart from that, if you have any issues/questions/suggestions about Pluto, just asked on the pluto mailing list ;) Carsten > -----Original Message----- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 13, 2004 1:40 AM > To: [EMAIL PROTECTED] > Subject: JSR-168 Portlets > > I have been working for the last 2 days trying to figure out > how to get > JSR-168 portlets, packaged as their own webapp, to work with > the Cocoon portal. Has anyone ever gotten this to work? I > have come to the conclusion that, due to the design of Pluto, > it is not realistically possible. > > The problem I am seeing is that Pluto has a couple of > singleton classes that it needs to share between the Portal > webapp (i.e. Cocoon) and the portlet webapp. This requires > that the pluto jar file be placed in Tomcat's shared/lib > directory. However, because Tomcat places the WEB-INF/lib > above shared/lib in the class loader chain any Cocoon classes > that reference pluto classes will get a > ClassNotFoundException unless they are also placed in shared > lib. Needless to say, this will end up with all of Cocoon > and everything it uses in shared/lib in short order. > > Maybe I'm missing something, but I just don't understand why > Pluto has to require the singleton classes. It would make > more sense to me for Pluto to store references to the > singleton objects in ServletContext attributes and then > anchor those into a singleton in the Portlet webapp when > Pluto's PortletServlet is entered. > > Comments? > > Ralph > >
