Re: [Deployment] Deployment of packed wars ears etc

[Jan Bartel]

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 [mailto:[EMAIL PROTECTED]
        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
--
/****************************************
 * Jan Bartel <[EMAIL PROTECTED]>
 * Associate
 * Core Developers Network LLC
 * http://www.coredevelopers.net
 ****************************************/