I was not as clear as I could have been. I was referring to a problem Tomcat was having preserving portlet application sessions so that portlets within the same portlet application could share data and find the right application context. This problem was related to Tomcat not properly preserving the session id used when the portal driver web appplication forwarded a client request to a portlet in a portlet application. I believe the tricky part was related to cookie management.
We went through a few of those issues with Jetty too :-) In the end we ended up with a solution where all contexts have the same session id (used in the cookie) but each context's attribute space is isolated from each others so there can be no conflict in attibute names. Session invalidation is server wide.
I was not advocating that portlet applications share their data with other portlet applications. I believe portlet security will be a big issue requiring secure messaging and data interchange as well as portlet sandboxes. You could even see portlet DRM wrappers. I hear talk of portlet messaging being included in the next portlet spec. I would like to see a solution that leverages something like the infobus.
The easiest way to share the libraries is to bundle
the portal and
portlet wars together into an ear and then add the
libraries to the ear
deployment plan as <dependency>'s.
Alternatively you can create a custom config
containing <dependency>s
for the libraries and then make that the parent of
your portal and
portlet applications; this allows them to be
deployed separately.
I don't think the ear solution won't work because I need support for dynamically deploying and undeploying of individual portlet applications while the rest of the portlets registered with the portal application keep on running. What I need is an object from a Pluto jar that is instantiated by the portal driver web application be sent as a request attribute to a portlet web application and a portlet be able to use that object without encountering any classloader issues. I'd think that these shared jars would need be loaded by a common parent classloader to the web apps. It looks like your second option might be this solution?? Isn't there a directory in Jetty dedicated for this purpose? In Tomcat this is the shared/lib directory.
There might be but when its embededed in Geronimo we take over most of those functions. Geronimo does not follow the pattern of loading everything in a directory into the classloader as we wanted to give people precise control; the equivalent mechanism is to list the libraries an application needs as dependencies and then we ensure they are added to its classloader from the repository. The parent/child relationship between configuration ids defines the parent/child classloader structure.
One thing you could do is make all the portlet applications children of the portal application. That way they could see all its classes (including the portlet libraries if the portal declared them as dependencies) but other applications running in the server would be isolated.
On another tack, what mechanism are you using for portlet deployment and for having portlets register with the portal when they start?
One of the things we have considered is adding an SPI into the builder subsystem that would allow portlet deployment (portlet.xml processing) to be integrated with webapp deployment, basically making portlet first class objects just like servlets.
Another would be to provide a mechanism for tying portals to portlet applications so that the portal was aware of lifecycle changes in the portlets. For example, if a portlet app was being restarted the portal would know when it went offline/online and hence could choose how to handle requests to that portlet or the invalidation of its render cache.
-- Jeremy
