1 2 Previous Next 15 Replies Latest reply on Sep 20, 2006 4:40 PM by bill.burke

    Hot deploying deployers - deployer chains

      Rather than having a single deployer chain,
      what we really need is a tree like structure based on the
      input/output of the metadata structures.

      e.g.

      -- one-to-one
      -< one-to-many
      \- additional branch
      
      Services
      -service.xml -- ServiceDeployment.class -< ServiceMetaData.class -- MBean
       \- LoaderRepositoryConfig.class - ClassLoader
      
      Rars
      .rar -- RARMetaData.class -- ServiceMetaData -- etc.
       \- LoaderRepositoryConfig.class -- etc.
      
      Connection factories
      -ds.xml -- ServiceDeployment.class -- etc.
       \- LoaderRepositoryConfig.class -- etc.
      


      With each deployer defining its inputs and outputs.
      e.g.
      SARDeployer
      input = -service.xml
      output = ServiceDeployment.class

      ServiceDeploymentDeployer
      input = ServiceDeployment.class, ServiceMetaData.class
      output = ServiceMetaData.class

      ServiceDeployer
      input = ServiceMetaData.class
      output = REAL

      This way the chain can built up based on the input/outputs.

      We still need the original relative ordering to decide
      which parts of the chain of get done at what stage,
      e.g. the ServiceClassloaderDeployer is done
      before the ServiceDeploymentDeployer

      The advantage to this, is that we know when a deployer is added
      whether other deployments (really pieces of their metadata)
      are affected. i.e. whether we need to unwind them to
      reprocess something.

      e.g. When I add the RARDeployer to the beginning of the chain
      I only need to see what deployments are rars (end in .rar or have
      a ra.xml) and process the output ServiceMetaData through its
      particular chain.
      e.g.2. If somebody interpolates a deployer
      that processes ServiceMetaData.class between the
      ServiceDeploymentDeployer and the ServiceMetaDataDeployer
      then I need to unwind the work of the ServiceMetaDataDeployer
      to do that work before winding forward again.

      Such a mechanism also gives a more direct link for the front
      end profile service to reprocess part of a deployment
      (including just changing an attribute on an MBean if that
      is all the update requires - i.e. no redeploy).

      The big stumbling block, comes from things like:
      -aop.xml
      -security.xml
      log4j.xml
      where we don't want any (or maybe part) of the deployment to proceed
      until these have established their context.

      But if these are hotdeployed, how do we know they even exist?
      One solution is to be able to define these "show stoppers"
      in the main deployer or profile service metadata.

      However, that still leaves the age old problem,
      how do I apply a -security.xml to the security deployer?

        • 1. Re: Hot deploying deployers - deployer chains
          starksm64

          First, I'm not in agreement that hot deployment of deployers is needed. The only post bootstrap configuration I can see are aspects on the deployers themselves, but this can be a function of an individual deployment, not neccessarily a reconfiguration of the deployer.

          Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.

          • 2. Re: Hot deploying deployers - deployer chains

             

            "scott.stark@jboss.org" wrote:
            First, I'm not in agreement that hot deployment of deployers is needed. The only post bootstrap configuration I can see are aspects on the deployers themselves, but this can be a function of an individual deployment, not neccessarily a reconfiguration of the deployer.


            I'm not sure I understand this.

            What we are talking about will end up in the full solution as
            a profile that looks like:

            * kernel/profile/bootstrap
            This will be semi-hardwired and represents a minimal set
            of features to get the thing working (not what we have now).

            * core configuration
            These will be plugins, to the above, that need to be done early.

            Of course ideally we want as much as possible to be done
            through deployers.

            Thing that fall into this category:
            aop-mc-int
            profile plugins, e.g. JBoss ON integration
            legacy jmx kernel
            core logging (user configurable like conf/log4j.xml)

            * deployers
            A set of deployer packages that plugin to the main deployer/profile.

            * the deployments
            A fixed list, scanner based, something else or a mixture.

            So basically, I don't believe the MainDeployer/deployers
            should be a part of the bootstrap configuration and that
            there will be some form of "hotdeployment" even if it
            is the initial step that creates a fixed list
            before the real deployments are done.

            • 3. Re: Hot deploying deployers - deployer chains

               

              "scott.stark@jboss.org" wrote:

              Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.


              Ignore the deployment context. That is just the current iteration's
              version of the DeploymentInfo. Basically a big horrible
              map of metadata and state about the deployment.

              What we are really dealing with is:
              * managed objects - either predetermined using our metadata formats
              or the unparsed xml and annotations
              * structure - where to look for unparsed metadata and what makes up
              the classpath
              * transient state - used during the deployment

              In the full solution, the management component of the profile
              service should be able to say something like:
              "change the pool size of this datasource"
              and it is the MainDeployer's job to say (based on the meta annotations),
              I can do that (with the help of the relevant deployer)
              without going through a redeploy.

              It can't do that with the current MainDeployer api and DeploymentContext.

              • 4. Re: Hot deploying deployers - deployer chains
                starksm64

                 

                "adrian@jboss.org" wrote:

                So basically, I don't believe the MainDeployer/deployers
                should be a part of the bootstrap configuration and that
                there will be some form of "hotdeployment" even if it
                is the initial step that creates a fixed list
                before the real deployments are done.


                Ok, I'm fine for delaying the loading of the deployers as component of the profile after the bootstrap, but I'm not really interesting in addressing arbitrary hotdeployment of everything outside of the bootstrap kernel as that really is not the primary focus of the deployer redesign.


                • 5. Re: Hot deploying deployers - deployer chains

                   

                  "scott.stark@jboss.org" wrote:

                  Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.


                  But to answer your question (in brief), the Deployment(Context)
                  is structurally analyzed (I assume no predetermined managed objects)
                  into its javaee components which determines the metadata location.

                  This metadata location identifes a list of configuration files
                  -security.xml, -logging.xml (besides the javaee files).

                  These are matched to the deployer chains.

                  e.g. The -security.xml might create an application policy that is
                  added to the metadata repository

                  Input=-security.xml
                  Output=real
                  When=some ordering after the metadata repository context is constructed

                  e.g. A log4j.xml might create a scoped (based on classloader)
                  logging configuration

                  Input=log4j.xml
                  Output=real
                  When=some ordering after the classloader

                  The chains are more important when you have flows like the
                  rar deployer:

                  ra.xml -> rar metadata -> servicemetadata -> mbean
                  rar parser -> rar deployer -> servicedeployer -> real

                  The reason to split the rar parser from the rar deployer is
                  that:
                  1) The rar parser is not required for predetermined metadata
                  2) Some other parser/deployer earlier in the list can construct
                  the rar metadata for deployment from some other mechanism
                  and use the later rar deployer to do the real work

                  • 6. Re: Hot deploying deployers - deployer chains

                     

                    "scott.stark@jboss.org" wrote:
                    "adrian@jboss.org" wrote:

                    So basically, I don't believe the MainDeployer/deployers
                    should be a part of the bootstrap configuration and that
                    there will be some form of "hotdeployment" even if it
                    is the initial step that creates a fixed list
                    before the real deployments are done.


                    Ok, I'm fine for delaying the loading of the deployers as component of the profile after the bootstrap, but I'm not really interesting in addressing arbitrary hotdeployment of everything outside of the bootstrap kernel as that really is not the primary focus of the deployer redesign.


                    So how do you want to structure this?

                    For now, I'd suggest:

                    1) Using the conf/jboss-service.xml
                    as the "core configuration"
                    which would contain:
                    * The static jars to deploy as now
                    * The core logging
                    * The remaining legacy bits

                    We should aim to remove most of this over time,
                    either althogether or into their own deployments.

                    2) Create a server/config/deployers
                    which serves to idenitfy the deployer packages


                    • 7. Re: Hot deploying deployers - deployer chains
                      starksm64

                       

                      "adrian@jboss.org" wrote:

                      So how do you want to structure this?

                      For now, I'd suggest:

                      1) Using the conf/jboss-service.xml
                      as the "core configuration"
                      which would contain:
                      * The static jars to deploy as now
                      * The core logging
                      * The remaining legacy bits

                      We should aim to remove most of this over time,
                      either althogether or into their own deployments.

                      2) Create a server/config/deployers
                      which serves to idenitfy the deployer packages


                      The logging really needs to be part of the core bootstrap. Enabling trace level logging of the kernel using -Dlog4j.configuration=log4j-trace.properties currently is not working as expected, and if we want to use jdk logger we need to install a LogManager early on.

                      I'm not clear on why we need a distinction between 1/2, especially in terms of loading the legacy mbean service descriptor. Why not just have:

                      1. A boostrap-beans.xml to define the kernel and profile service implementation.
                      2. A server/config/deployers to define the deployer packages.

                      If we want a shared class loader used by the deployers the server/config/deployers can include a classloader-beans.xml descriptor pointing to the lib directory and the deployers can declare a dependency on it.


                      • 8. Re: Hot deploying deployers - deployer chains

                         

                        "scott.stark@jboss.org" wrote:

                        The logging really needs to be part of the core bootstrap. Enabling trace level logging of the kernel using -Dlog4j.configuration=log4j-trace.properties currently is not working as expected,
                        .

                        That's because
                        1) -D against run.sh doesn't happen until the parsing of the main() arguments
                        2) It should be a url


                        I'm not clear on why we need a distinction between 1/2, especially in terms of loading the legacy mbean service descriptor. Why not just have:

                        1. A boostrap-beans.xml to define the kernel and profile service implementation.
                        2. A server/config/deployers to define the deployer packages.


                        This is because I want to seperate the core configuration
                        file from the user configurable options.
                        The core configuration is implementation detail that we are likely
                        going to want to change. Mixing it with user options make this hard.

                        This is certainly a short coming of the current conf/jboss-service.xml
                        You can't create one and use it from release to release because it
                        changes.


                        If we want a shared class loader used by the deployers the server/config/deployers can include a classloader-beans.xml descriptor pointing to the lib directory and the deployers can declare a dependency on it.


                        The problem with a classloader-beans.xml is there
                        is no working classloader implementation besides the UCL classloader
                        at the moment.
                        It is something that should be looked at, since there is also
                        currently no way for a -beans.xml to identify itself as scoped.

                        • 9. Re: Hot deploying deployers - deployer chains
                          starksm64

                           

                          "adrian@jboss.org" wrote:
                          "scott.stark@jboss.org" wrote:

                          Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.


                          But to answer your question (in brief), the Deployment(Context)
                          is structurally analyzed (I assume no predetermined managed objects)
                          into its javaee components which determines the metadata location.

                          This metadata location identifes a list of configuration files
                          -security.xml, -logging.xml (besides the javaee files).

                          These are matched to the deployer chains.

                          e.g. The -security.xml might create an application policy that is
                          added to the metadata repository

                          Input=-security.xml
                          Output=real
                          When=some ordering after the metadata repository context is constructed

                          e.g. A log4j.xml might create a scoped (based on classloader)
                          logging configuration

                          Input=log4j.xml
                          Output=real
                          When=some ordering after the classloader

                          The chains are more important when you have flows like the
                          rar deployer:

                          ra.xml -> rar metadata -> servicemetadata -> mbean
                          rar parser -> rar deployer -> servicedeployer -> real

                          The reason to split the rar parser from the rar deployer is
                          that:
                          1) The rar parser is not required for predetermined metadata
                          2) Some other parser/deployer earlier in the list can construct
                          the rar metadata for deployment from some other mechanism
                          and use the later rar deployer to do the real work


                          I agree that structure mapping and even metadata parsing need to be distinct phases of the deployment model. These are needed for the profile service behavior that maps to the jsr88 function, as well as supporting the introduction of aspects that can affect the metadata.

                          I'm not clear on exactly how the input is described and utilized as a key one can use to obtain the correct starting point for a query to the MainDeployer. Input can be anything from vfs path patterns to concrete metadata classes.


                          • 10. Re: Hot deploying deployers - deployer chains
                            starksm64

                             

                            "adrian@jboss.org" wrote:
                            "scott.stark@jboss.org" wrote:

                            The logging really needs to be part of the core bootstrap. Enabling trace level logging of the kernel using -Dlog4j.configuration=log4j-trace.properties currently is not working as expected,
                            .

                            That's because
                            1) -D against run.sh doesn't happen until the parsing of the main() arguments
                            2) It should be a url

                            But the kernel logging starts after the ServerImpl is loaded so this should not matter. I'll drill into this latter.

                            "adrian@jboss.org" wrote:


                            I'm not clear on why we need a distinction between 1/2, especially in terms of loading the legacy mbean service descriptor. Why not just have:

                            1. A boostrap-beans.xml to define the kernel and profile service implementation.
                            2. A server/config/deployers to define the deployer packages.


                            This is because I want to seperate the core configuration
                            file from the user configurable options.
                            The core configuration is implementation detail that we are likely
                            going to want to change. Mixing it with user options make this hard.

                            This is certainly a short coming of the current conf/jboss-service.xml
                            You can't create one and use it from release to release because it
                            changes.

                            Ok, but this is mixing sever configuration files with user configuration files that really should be an implementation detail of the profile service. boostrap-beans.xml is what I'm defining as the core configuration that user's do not touch. It defines the profile service which is what reads in user configuration files and overrides. Without speaking of a particular profile service impl, I don't know where the user configuration lives.

                            "adrian@jboss.org" wrote:


                            If we want a shared class loader used by the deployers the server/config/deployers can include a classloader-beans.xml descriptor pointing to the lib directory and the deployers can declare a dependency on it.


                            The problem with a classloader-beans.xml is there
                            is no working classloader implementation besides the UCL classloader
                            at the moment.
                            It is something that should be looked at, since there is also
                            currently no way for a -beans.xml to identify itself as scoped.


                            This is just an issue of having sufficient support for specifying class loader metadata at the kernel config level, and a class loading deployer to support it. As long as we have a ucl bean factory and class loading deployer I don't see why we can't support the existing scoped ucl model. If I want a scoped bean deployment, I define a LoaderRepositoryConfig bean and reference it, or include a ucl-loader-config.xml descriptor in the deployment.


                            • 11. Re: Hot deploying deployers - deployer chains
                              starksm64

                              So are we going to address an spi change before moving this to trunk?

                              • 12. Re: Hot deploying deployers - deployer chains
                                starksm64

                                Ok, I just want to validate it for jboss messaging then.

                                • 13. Re: Hot deploying deployers - deployer chains

                                  The only thing I'd like to fix is the DeploymentUnit.getDeploymentContext().

                                  Currently this hack is used in two places.

                                  1) In the ServiceClassloaderDeployer to add elements to the classpath
                                  2) In the rar deployer to generate the my.ear#my.rar based on
                                  whether it has a parent.

                                  But I think we can wait to see what other features need to be
                                  exposed on DeploymentUnit before finalising this spi.

                                  e.g. I imagine Tomcat will the root url of the war in order to serve content :-)

                                  And Bill has already mentioned he needs to navigate through the
                                  deployment structure to "guess" the ENC injections.

                                  • 14. Re: Hot deploying deployers - deployer chains
                                    starksm64

                                    The structure of DeploymentUnits in terms of tree is something we should be exposing since there is so much behavior based on this in terms of metadata defaults.

                                    In terms of the class loader metdata, let's just define a base class path based attachment type that can be added/retrieved from the Attachments spi.

                                    1 2 Previous Next