Deployer chains and interceptors

[starksm64]

We have been talking about allowing multiple deployers to process a deployment for a while now. What is the status of adding this to head? I would like to get moving on this with the thought of getting this into a future 4.0.x release. Some issues to resolve:


A virtual filesystem aspect should exist to isolate each deployer from having to perform jar/filesystem manipulations in looking for resources
There may need to be a notion of
deployment interceptors associated with one or more subdeployers as opposed to needing to implement a full supdeployer to create deployment side effects

[julien1]

Ok, here is the design I have in mind for the new deployer aspects.
This will be part of JBoss Kernel M2 release due by end of January.

Deploying Deployers:
First you have to be able to deploy a deployer. Not an easy task as I imagine
the deployer will have dependencies on other services. The aim will be to minimize
these dependencies to ease the problem.

Basic Architecture:
The basic architecture of the aspectized deployer is that the deployments
work with a tree of DeploymentInfo objects just like the deployers do now.
There are two major differences:
1) The deployers do not deal with urls, they deal with VFS contexts
2) The deployers do not create objects directly, instead they create kernel
MetaData objects and submit them to the kernel for instantiation/configuration
to obtain correct ordering of startup/shutdown

Deployment Mode:
The deployers work in two different modes
1) The first step is to ask who recognises the VFS context. This is so
the responsible deployer can correctly decide which part of the context
takes part in the classloading and where the metadata is located.
Additionally, this may introduce subdeployments (VFS contexts) if the
deployment allows/contains them.
2) The second step (the main chain) allows each deployer to augment the
kernel metadata with its own config.

Deployer Ordering:
Since the deployers are working on a metadata model rather than
constructing objects directly, there should be less problem with ordering.
Most ordering will be in the classloader/instantiation/config stage,
the deployer should insert that ordering in the form of dependencies in the metadata.
The only ordering required of the deployer chain is where one deployer
needs to work on the kernel metadata output of another deployer.

Killing two birds with one stone:
The problems mentioned with the deployer requiring other services
and the first tasks performed by package specific deployers,
i.e. identifying the deployment and its structure
can be easily solved by splitting the deployers into two classes
1) A structural component that says "I recognise this deployment and this is
how it is structured"
2) An interpretive component that creates the kernel metadata from the
package.

[julien1]

one issue I have in mind regarding multiple processor for a deployment is how to coordinate the different processors between them.

[starksm64]

Coordinate in terms of ordering? Some deployers clearly depend on other types like the web service deployer needing an ejb or war deployment, at least today. Others are just there for side effects and really only care that there is a deployer. Perhaps an ordered chain of interceptors added to the current single deployer model is the right way to extend this.

[dimitris]

I imagine we need something like Subdeployers exposing an additional interface to register/deregister interceptors.

Some issues that come to my mind:

- I'd prefer not to have one more Interceptor class. The JMX interceptor seems too much for this, while I'm not yet sure if something can be re-used from the future 5.0 kernel interceptor

- For the interceptor to gain control we'll have to possibly create another set of methods on the SubDeployer interface to be used by MainDeployer (e.g. interceptedInit, intereceptedCreate/Start/Stop/Destroy) that delegate to the interceptor chain, with the default interceptor calling the standard init/create/start/stop/destroy methods.

- About the ordering, wherever we've used interceptors so far, it is by means of explicit declaration in some xml file. I don't know how the aop framework handles this for "dynamic" interceptor registrations, so at the most I'd imagine something like, add()/addFirst()/addLast()

- Since the set of methods for the subdeployer interface is fixed, maybe it makes sense instead of a "generic" interceptor to have a specific SubDeployerHandler

- From the webservice deployer it seems the problem with the existing notification based scheme, is that the "attaching" deployer cannot fail the "primary" deployment

[julien1]

yes at least this interceptor chain can use a typed interface, it does not makes sense to use the generic interceptor interface.

one concern regarding to improve the WARDeployer would be to have tomcat use an input stream for web.xml when it deploys a war file instead of opening the stream by itslef.
Thus that would avoid the rewrite the modified web.xml on the disk which overwrites the original document.

[dimitris]

I'm not aware of this tomcat problem. I presume having a virtual file system would help, yet, I think interceptors and vfs could be solved seperately.

So, do you prefer the current deployment scheme plus interceptors (i.e. war, ejb, sar, etc. deployers with the ability to attach extra interceptors)? In that case adding interceptors will be an exception for cases likes Nukes or WebServices, so ordering may not be so important - we can just add interceptors first in the chain.

The other model is to have all subdeployers being "aspects" in a single chain. I believe this is Adrian's plan for 5.0 but I don't know if this is realistic for 4.0.

[julien1]

This is not a problem currently because Portal and WS don't do the same :

WS modifies the web.xml
Portal modifies the tomcat StandardContext object to inject its servlet

In case Portal do the same as WS, I think it would not work because both of them would modify web.xml and I am sure there would have issues for that regarding to the backup file and who process first, etc...

Having a VFS would be a must :-)

[adrian.brock]

Ok, here is the design I have in mind for the new deployer aspects.
This will be part of JBoss Kernel M2 release due by end of January.

Deploying Deployers:
First you have to be able to deploy a deployer. Not an easy task as I imagine
the deployer will have dependencies on other services. The aim will be to minimize
these dependencies to ease the problem.

Basic Architecture:
The basic architecture of the aspectized deployer is that the deployments
work with a tree of DeploymentInfo objects just like the deployers do now.
There are two major differences:
1) The deployers do not deal with urls, they deal with VFS contexts
2) The deployers do not create objects directly, instead they create kernel
MetaData objects and submit them to the kernel for instantiation/configuration
to obtain correct ordering of startup/shutdown

Deployment Mode:
The deployers work in two different modes
1) The first step is to ask who recognises the VFS context. This is so
the responsible deployer can correctly decide which part of the context
takes part in the classloading and where the metadata is located.
Additionally, this may introduce subdeployments (VFS contexts) if the
deployment allows/contains them.
2) The second step (the main chain) allows each deployer to augment the
kernel metadata with its own config.

Deployer Ordering:
Since the deployers are working on a metadata model rather than
constructing objects directly, there should be less problem with ordering.
Most ordering will be in the classloader/instantiation/config stage,
the deployer should insert that ordering in the form of dependencies in the metadata.
The only ordering required of the deployer chain is where one deployer
needs to work on the kernel metadata output of another deployer.

Killing two birds with one stone:
The problems mentioned with the deployer requiring other services
and the first tasks performed by package specific deployers,
i.e. identifying the deployment and its structure
can be easily solved by splitting the deployers into two classes
1) A structural component that says "I recognise this deployment and this is
how it is structured"
2) An interpretive component that creates the kernel metadata from the
package.

[adrian.brock]

Let's take some use cases (simplified)

1) deploy a jar
2) deploy an ejb
3) deploy a war
4) deploy an ear

[julien1]

nice Adrian, as usual, beats us.

[adrian.brock]

1) deploy a jar, this is also the classloader aspect

Mode 1:
The jar deployer will be simply make the root of a deployment the classloader
context if no other deployer has already decided (an example of deployer ordering)

Mode 2:
It adds classloader metadata (regardless of who specified the context)
to the DeploymentInfo for the jar

[adrian.brock]

2) Deploy an ejb

Mode 1
This is already done by the jar deployer

Mode 2
Construct kernel metadata from the ejb metadata

[adrian.brock]

3) Deploy a war

Mode 1
Makes the classloader context WEB-INF/lib and WEB-INF/classes
Overrides the subdeployment routine as wars do not contain subdeployments
Specifies WEB-INF as the metadata location rather than META-INF

Mode 2
Constructs kernel metadata for the Tomcat config objects

[adrian.brock]

4) Deploy an ear

Mode 1
Overrides the classloader context to be a "NULL" classloader
Overrides the subdeployment routine to only look at deployments specified
in application.xml and jboss-app.xml

Mode 2
Nothing - handled by the relevent deployer of the subdeployments