-
1. Re: Blog post about deployers
Is each phase handled by a different deployer? For example, in the blog:
One of the earliest stages is the PARSE stage. For normal WAR deployment, the WebAppParsingDeployer does exactly that.
....
As the container enters the CLASSLOADER stage of deployment, normally the WarClassLoaderDeployer -
2. Re: Blog post about deployers
Yes, each Deployer implementation calls setStage(...) to indicate which stage of deployment it should be considered a candidate. There's a variety of base deployers you can build from, which imply the stage. For instance, there's AbstractParsingDeployer which sets the stage to PARSE. Then there's AbstractParsingDeployerWithOutput which designates it'll produce some object (MetaData or other attachments) as the result of the parse.
Based upon available inputs (files, directories, resources or MetaData) it may fire its deploy() and produce more MetaData or alter existing MetaData (or just take an action and produce no meta-data at all).
Within each stage, your deployers are ordered, so you can wedge things before or after existing deployers to change how things ultimately get processed. -
3. Re: Blog post about deployers
As I re-read the post and the code...
WarClassLoaderDeployer actually is bound to POST_PARSE, which occurs after the PARSE stage, but before the CLASSLOADER stage. So it's not always obvious where things are firing by the class name alone.
I'll work on updating the blog-post as I continue to figure this stuff out. -
4. Re: Blog post about deployers
I've updated it slightly and attached a newer diagram:
http://www.fnokd.com/2008/09/17/deployers-in-jboss-microcontainer/ -
5. Re: Blog post about deployers
I see you completely dropped WCLD.
Perhaps you could still leave it,
and just mention that its sole purpose is to create web/war compatible CLMD.
Note: TomcatDeployer is not the last depolyer in this chain. ;-)
Check AbstractWarDeployer::deployWebModule,
where we create ServiceMetaData,
hence making war deployment nothing more than MBean.
And this fact can sometimes be 'exploited' to declare dependency on it. ;-) -
6. Re: Blog post about deployers
PHILOSOPHY
I'd say you mostly got it correct Bob.
The part you are missing is actually the most important part.
The Deployers create components, i.e. metadata for MBeans and POJOs
(or other component models).
They don't directly create anything, deployers are about MetaData processing.
Instead it is the Microcontainer that creates the runtime objects from this
component metadata when their dependencies are satisfied.
CLASSLOADING
The "magic" that occurs in the ClassLoader part is because it is doing
"two stage" deployment.
The DESCRIBE stage populates the ClassLoading system to say what classloaders you
want to construct - ClassLoadingMetaData).
This includes any dependencies (similar to OSGi)
e.g. My deployment needs version 1.0 of the com.acme.foo package.
META-INF/jboss-classloading.xml<classloading xmlns="urn:jboss:classloading:1.0"> <requirements> <package name="com.acme.foo" version="1.0"/> </requirements> </classloading>
Only when that dependency is satisfied (thanks to some more "magic" in
the microcontainer :-) will it allow your deployment to move to the CLASSLOADER stage.
Of course, the CLASSLOADER stage actually creates the classloader
and wires together the related deployments so your deployment can see
the requested modules/packages.
WAR CLASSLOADING
The WEB classloader is probably the most complicated,
so it was probably a bad example for a simple explanation. :-)
In general, the ClassLoadingMetaData comes from three different places.
1) META-INF/jboss-classloading.xml (PARSE STAGE)
2) A specific deployer for the deployment type (POST PARSE)
3) The ClassLoadingDefaultDeployer (DESCRIBE)
For a WAR we have to do special things. WARs get their own classloader
that does "servlet spec" classloading, i.e. parent last,
hence the WARClassLoaderDeployer. This is true whether the WAR is a top
level deployment or a part of another archive, e.g. an EAR
For other deployments the ClassLoadingDefaultDeployer just
creates a simple "standard" classloader for the whole deployment (if you don't describe
it explicitly using the xml). -
7. Re: Blog post about deployers
"adrian@jboss.org" wrote:
1) META-INF/jboss-classloading.xml (PARSE STAGE)
It can also come from<loader-repository/>
configurations for backwards compability with jboss-3/4.x