7 Replies Latest reply on Sep 23, 2008 12:26 PM by Adrian Brock

    Blog post about deployers

    Bob McWhirter Novice

      Howdy--

      After stepping through MC working on my own deployer, I've tried to outline the behaviour or normal WAR deployment on my blog:

      http://www.fnokd.com/2008/09/17/deployers-in-jboss-microcontainer/

      Comments or corrections muchly appreciated.

      Thanks,

      -Bob

        • 1. Re: Blog post about deployers
          jaikiran pai Master

          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
            Bob McWhirter Novice

            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
              Bob McWhirter Novice

              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.

              • 5. Re: Blog post about deployers
                Ales Justin Master

                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
                  Adrian Brock Master

                  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 Brock Master

                     

                    "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