geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: [Deployment] Deployment of packed wars ears etc
Date Sun, 24 Aug 2003 06:43:32 GMT

> 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.

Maybe it's terminology again, but there would be a specialized deployer
for web applications that would need to be aware of things like their
classloading model. It would also ensure that it fit in the global
classloading model (like whether there was an EAR involved, whether the
user had chosen the Java2 model to override the normal webapp model).
Hopefully this will get around the JBoss issue where the webapp could be
a black box as far as classloading was concerned, making debugging
problems difficult.

I see the configuration part of deployment as a very distinct phase from
booting a running instance, and I don't think this has been a clear
distinction in the past. Typically configuration was done by using your
favourite IDE (either vi or emacs, you choose :-) to edit the DDs, and
then the entire bundle was 'deployed' by sending its URL to the server
(either directly or by placing a file somewhere a scanner picked it up).

I think JSR88 changes that by saying:
1) the deployment tool is very different from the container provider
2) the communication is by DDBean and DConfigBean instances, not raw XML
3) distribution is distinct from start

So 88 allows all the configuration and distribution stuff to happen
separately. What you get at the end it is a set of modules that can then
be started, possibly at a much later date.

This seems to fit our lifecycle well, where configure/distribute end up
creating MBeans for Containers and Components, and then start turns into
the appropriate start() StateManageable event.

> > 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?

I'm fighting just that issue with the AppClient code right now - my
current thinking is that the AppClientContainer will expose an attribute
that is the java:comp Context and it gets set just like any other. The
AppClientContainer uses a ComponentContextInterceptor to associate it
with the current thread. I just need some AppClient DDBeans to test this


View raw message