geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [Deployment] Deployment of packed wars ears etc
Date Sun, 24 Aug 2003 02:52:45 GMT
Firstly, I think some of these discussions are a little derailed by 
mismatched terminology. When I say "web container" I mean 
o.a.g.web.AbstractWebApplication, which is an abstract class supporting 
deployment and lifecycle of a web app inside geronimo. "Web container" 
means o.a.g.web.AbstractWebContainer, which is again an abstract class 
supporting aspects of deployment and lifecycles of web apps inside 
geronimo. "Jetty", "Tomcat" etc refer to existing, external web 
container implementations that can be integrated with Geronimo by 
extension of these abstract classes.

Jeremy Boynes wrote:
>>From: Aaron Mulder []
>>	My feeling is that the deployer should unpack and prepare the
>>archives and pass the container something like a ClassLoader and an array
>>of DD references (probably a stack of XMLBeans/Castor beans for each DD or
>>something).  I think we want the deployer service to manage creating the
>>ClassLoader hierarchy across an EAR, and I would want to use the same
>>Geronimo DDs regardless of which servlet or EJB container you have plugged
>>in at the moment, so I don't think we'd do well to delegate everything to
>>the container.
I have no problem with the deployer making the decision whether to 
unpack or not.

I am concerned, however, at the deployer making classloaders on behalf 
of the web container. This is because the servlet spec mandates some 
pretty specific classloading behaviour that I'm not sure should be 
exposed in the deployer. I'm referring here to the whole classloading 
delegation model: the servlet spec says that webapps can load classes 
from WEB-INF in preference to delegating the loading upwards to parent 
class loaders, as is the norm in Java2.  Jetty and no doubt Tomcat go to 
some trouble to implement this, and I'm not sure that it is a good idea 
to place this implementation in the deployer.  Having the deployer 
manage the classloader hierarchy across the EAR seems reasonable, but 
this could be achieved by having the deployer pass a parent classloader 
to the web infrastructure when deploying the web app.

> I'd go even further and say that the container should just contain the
> runtime configuration and that the deployer should be responsible for
> creating that. So it is the deployers job, for example, to build the JNDI
> tree from the DD info rather than the container.

If the deployer creates the java:comp/env context for the webapp,
then by what mechanism can the container obtain it in order to
be able to associate it with a thread handling an inbound request?
I'm not saying the deployer shouldn't create it, just that if it
does, how does it communicate it to the container?


  * Jan Bartel <>
  * Associate
  * Core Developers Network LLC

View raw message