[jboss-dev] Deployment chains

Adrian Brock abrock at redhat.com
Fri Oct 3 10:42:56 EDT 2008


I'm currently working on tidying up the deployers in JBoss5
as part of that I'm adding some JMX operations so
you can query the deployer chains.

The initial simple list (it doesn't look very good without the css 
which you get from the jmx console:-) is attached.

A quick scan of this shows some funny things or at least
some misunderstanding of the relative ordering parameter.

The relative order parameter only applies when the deployers
have similar input/outputs. It's there for when you have multiple 
"filter"s. i.e. a deployer that has the same input/output type
and you need to control the order in which the filters run
(you should try to design away such a requirement if possible).

e.g. VFSClassLoaderClassPathDeployer is a filter
it inputs and outputs ClassLoadingMetaData.
So does the ClassLoadingDefaultDeployer.

1) Webservices

org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPreJSE
org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerPostJSE

Currently the ordering of these is pretty weak.

i.e. there is no guarantee the PRE will run before the POST,
except that the relative order of PRE is -1 compared with Tomcat
and the POST must run after Tomcat.

This is very brittle to changes in the Tomcat Deployer which
might move it earlier in the chain due to changes in its requirements.
i.e. The TomcatDeployer takes some additional metadata beyond
JBossWebMetaData.

Shouldn't the PRE deployer also output JBossWebMetaData
to show it modifies or process it and therefore MUST run before Tomcat?

2) AOP ClassLoading

A similar criticism applies for the AOPClassLoaderDeployer
This has no chain definition at all? Only a relative order based
on the main classloader deployer.

Again this is brittle to a refactoring of how the classloader deployer
works.

3) SEAM

org.jboss.seam.integration.microcontainer.deployers.SeamWebUrlIntegrationDeployer
doesn't specify any output. 
But I don't know where the source is for that?
My guess is that this should really be in Describe and specify an
output of ClassLoadingMetadata since that is where
classloading dependencies should be constructed.

4) WEB CLUSTERING

org.jboss.web.tomcat.service.deployers.ClusteringDependencyDeployer
I don't know what this is doing in Describe since it is not
establing a deployment dependency. Instead it is modifying the
JBossWebMetaData.
I'd guess this should be after the merge of annotations into that
metadata? Although I don't think there is such an annotation
currently? :-)

5+) There could be others. Like I said this is just a quick scan.

TODO

I'm going to be adding some other queries so you can display individual
metadata chains for an attachment type and graphs so can see
where attachments may have orginated from other attachments. 

Additionally you'll also be able to see deployers that were used 
for an individual deployment (including by subdeployment/component).

Any other ideas?
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20081003/bc0edfed/attachment.html 


More information about the jboss-development mailing list