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