1 2 Previous Next 16 Replies Latest reply on Nov 22, 2004 12:14 PM by Adrian Brock

    Deployer chains and interceptors

    Scott Stark Master

      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

        • 1. Re: Deployer chains and interceptors
          Viet Master

          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.

          • 2. Re: Deployer chains and interceptors
            Viet Master

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

            • 3. Re: Deployer chains and interceptors
              Scott Stark Master

              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.

              • 4. Re: Deployer chains and interceptors
                Dimitris Andreadis Master

                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

                • 5. Re: Deployer chains and interceptors
                  Viet Master

                  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.

                  • 6. Re: Deployer chains and interceptors
                    Dimitris Andreadis Master

                    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.

                    • 7. Re: Deployer chains and interceptors
                      Viet Master

                      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 :-)

                      • 8. Re: Deployer chains and interceptors
                        Adrian Brock Master

                        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.

                        • 9. Re: Deployer chains and interceptors
                          Adrian Brock Master

                          Let's take some use cases (simplified)

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

                          • 10. Re: Deployer chains and interceptors
                            Viet Master

                            nice Adrian, as usual, beats us.

                            • 11. Re: Deployer chains and interceptors
                              Adrian Brock Master

                              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

                              • 12. Re: Deployer chains and interceptors
                                Adrian Brock Master

                                2) Deploy an ejb

                                Mode 1
                                This is already done by the jar deployer

                                Mode 2
                                Construct kernel metadata from the ejb metadata

                                • 13. Re: Deployer chains and interceptors
                                  Adrian Brock Master

                                  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

                                  • 14. Re: Deployer chains and interceptors
                                    Adrian Brock Master

                                    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

                                    1 2 Previous Next