geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: deploying minimal web app
Date Sat, 02 Apr 2005 00:37:57 GMT
Scott Anderson wrote:
> 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 

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.


View raw message