7 Replies Latest reply on Jul 12, 2006 12:59 PM by Scott Stark

    VFSDeploymentScanner questions

    Scott Stark Master

      I updated the VDFDeploymentScanner Dimitris had worked to a VFSDeploymentScanner that integrates with the VFS and ProfileService(See org.jboss.system.server.profileservice.VFSDeploymentScannerImpl in the system2 module).

      A number of questions came up in this update.

      1. What does hot deployment mean in the context of a ProfileService? The current implementation simply uses hot deployment as a simple mechanism to add deployments to the current server profile. Its a shortcut for editing the profile via some admin tool.

      1a. In this context, what does touching a deployment mean? Any deployment added via hot deployment could have been edited any number of management tools and overriden the raw deployment metadata.

      1b. Should a hot deployment service be a pure development notion that only loads deployments into memory and does not update the current profile?

      2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?

        • 1. Re: VFSDeploymentScanner questions
          Adrian Brock Master

          There should be two types of "hot deployment".

          1) The original version which is just a way to add urls (with no
          chance of overrides by a management tool).

          2) A more up-to-date version for the management tool
          where you can specify a directory rather than a single url to deploy.
          This is just a more convenient way of specifying urls.

          In fact, (1) is just a subset of (2) where there is no "GUI" intervention

          • 2. Re: VFSDeploymentScanner questions
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:

            2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?


            I'm not sure I understand this?

            The deployments contain many pieces of metadata that are deployed
            in an aspectized way. They still need an ordering, but based on the
            metadata rather than the deployment suffix.

            e.g. aop must be before classloading, classloading before
            "instantiation", etc.

            Other dependendencies (between services and entry points)
            should be via the microcontainer. We are trying to remove
            the implicit dependency of the suffix ordering and replace it
            with a semi-implicit (i.e. added by deployer) dependency.

            e.g. If an ejb uses another ejb/datasource then the
            "enc/resource/reference" deployer adds this.
            e.g.2. Trivially, the above also requires a dependency on naming
            e.g.3. A web deployment has a dependency on the web container
            etc.

            • 3. Re: VFSDeploymentScanner questions
              Scott Stark Master

               

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

              2. The ordering of deployments based on suffix is largely useless with the current deployment framework that has any number of deployers operate on a deployment. Correct startup order is a function of deployers adding the correct dependency metadata to the kernel deployments they create. Any deployment package level dependency control would seem to be an aspect/deployer that used its own metadata to create place holder kernel objects (or used equivalents from jsr77) to introduce coarse grained dependencies. The question is, is this assement correct, and do we need such a coarse grained deployment aspect/deployer?


              I'm not sure I understand this?

              The deployments contain many pieces of metadata that are deployed
              in an aspectized way. They still need an ordering, but based on the
              metadata rather than the deployment suffix.

              e.g. aop must be before classloading, classloading before
              "instantiation", etc.

              Other dependendencies (between services and entry points)
              should be via the microcontainer. We are trying to remove
              the implicit dependency of the suffix ordering and replace it
              with a semi-implicit (i.e. added by deployer) dependency.

              e.g. If an ejb uses another ejb/datasource then the
              "enc/resource/reference" deployer adds this.
              e.g.2. Trivially, the above also requires a dependency on naming
              e.g.3. A web deployment has a dependency on the web container
              etc.

              Right, this is what I'm saying. The previous notion of ordering the deployment contexts based on the deployment suffix has little meaning since the deployments get passed through the ordered list of deployers/aspects. Only if there are implicit dependencies like a legacy service looking up an ejb via jndi would there be meaning in having the sar depend on the target ejb jar. Such a dependency should an explicit deployment context level dependency rather than some deployment name based ordering.


              • 4. Re: VFSDeploymentScanner questions
                Scott Stark Master

                 

                "adrian@jboss.org" wrote:
                There should be two types of "hot deployment".

                1) The original version which is just a way to add urls (with no
                chance of overrides by a management tool).

                2) A more up-to-date version for the management tool
                where you can specify a directory rather than a single url to deploy.
                This is just a more convenient way of specifying urls.

                In fact, (1) is just a subset of (2) where there is no "GUI" intervention


                This difference is just convienence of expressing deployments. What I'm asking about is whether the ProfileService is the only source of deployments, or whether the hot deployment service bypasses the ProfileService and uses the MainDeployer directly (as it does today). The latter would effectively eliminate the hot deployment service as usable in prod environments.





                • 5. Re: VFSDeploymentScanner questions
                  Adrian Brock Master

                  Like I said on a different thread,

                  I see the basic dev environment "hot deployment" service
                  that works like JBoss4 just being a kind a simple profile service
                  that runs in memory.

                  We need this kind of simple profile service to make easy for
                  people to port JBoss4 configs and not have to deal with
                  two different paradigms internally.

                  • 6. Re: VFSDeploymentScanner questions
                    Bill Burke Master

                    We also don't want to force developers into a tool-based deployment model that most other vendors have. Ops might like the new approach, but development won't.

                    • 7. Re: VFSDeploymentScanner questions
                      Scott Stark Master

                      I don't see why the hot deployment notion cannot be the baseline tool for deployment, and still have integration with the ProfileService. My concern with regard to leaving the hot deployment notion as something completely separate from the ProfileService is that it won't be used. If we wan't a similar prod compatible ease of use deployment, at least for single node systems, there will have to be some service that integrates hot deployment type of additions to the ProfileService. As far as I can see the only reason not to look at building the hot deployment service on top of the ProfileService would be the additional time it takes to complete an initial implementation. I can create a MainDeployer based implementation as a starting point to allow jboss5 to get to the point of deploying the existing configurations and look at an alternate implementation independently.