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 08:32:47 GMT
Jeremy Boynes wrote:
> 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.

Can you elaborate the deployment vs container architecture then? I have 
been labouring under the impression that the AbstractWebContainer was in 
fact the web application deployer, eg

   * possibly unpacking the war
   * creating the web-app instance
   * setting up the JNDI ENC for the web-app
   * setting up the classloaders for the web-app

Do you see the necessity for a totally separate WebDeployer, and if so, 
what is it's relationship with the WebContainer?

> 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 agree that JSR 88 regularises deployment from the point of view of a 
deployment tool and distinctly separates the config phase from 
distribution phase from the state management (which is really JSR77). 
However, I don't see where JSR88 says that the point of communication 
between the tool and the running j2ee platform instance is DConfigBeans 
and DDBeans etc. This may be my misunderstanding of the spec,  but I 
thought the point of communication was a "deployment plan", which the 
j2ee platform can interpret in any old way it wants. Are you saying that 
geronimo should implement the JSR88 beans as fundamental to our internal 
deployment architecture as well? Are the JSR88 beans, whilst providing a 
bean/tree interface to the descriptors, really the right model to use 
internally - specifically they were crafted for use by a 3rd party 
deployment tool so they have methods that are either extraneous or dodgy 
to expose internally (see my previous email about this). At the very 
least, these beans would need to be re-implemented for internal use to 
throw exceptions if the modifier methods are called.

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


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

View raw message