8 Replies Latest reply on May 19, 2008 6:31 AM by Adrian Brock

    Deployers in AS

    Andrew Rubinger Master

      We've previously talked about the deployers being an integration point with AS, and therefore should be placed within the AS source tree.

      Why is this the case? I thought the deployers only depended on (sometimes each other and) MC. If they were to be removed, we wouldn't have to mock up/recreate their functionality when Unit Testing other areas that depend on Deployers' output.

      As a concrete example, the EJB3 Proxy Component makes use of output from the MergedJBossMetaDataDeployer and Ejb3Deployer. Am I mocking up this data when I could be setting up an MC Deployer Chain from the real thing?

      S,
      ALR

        • 1. Re: Deployers in AS
          Scott Stark Master

          That is probably true for the newer more aspectized deployers, but legacy deployers like ejb2 and the war deployer still have way too many dependencies on other jbossas pieces to pull out.

          The Ejb3Deployer does have other integration pieces like JBossASDepdencyPolicy, JBossASKernel, Ejb3JBoss5Deployment, so those would have to be separated out into another layer and injected when configured for jbossas.

          • 2. Re: Deployers in AS
            Andrew Rubinger Master

            I'll put it on my "for another day" wishlist. :)

            Thanks for clearing this up.

            S,
            ALR

            • 3. Re: Deployers in AS
              Adrian Brock Master

               

              "ALRubinger" wrote:
              We've previously talked about the deployers being an integration point with AS, and therefore should be placed within the AS source tree.


              That is correct. Here's a repeat of the reasons I've stated before in both the aop,
              tomcat and webservices forums.

              NOTE: This is an idealisation of where we want to get to, rather how it has
              actually being done now.

              1) DO IT

              Individual projects should not be making policy decisions. They're job is to "do one
              thing well". In ejb3's case, its task is to create an EJB container from an EJBMetaData object.

              The deployers are just a mechanism to construct metadata and then
              create the MC ControllerContext(s) that will actually instantiate the real objects.

              The parsing available in the metadata project (from ejb-jar.xml and jboss.xml)
              should be enough to write your tests (using the same hooks that the deployers
              use to create the real objects).
              You don't care how the EJBMetaData gets constructed, that is a policy decision of the
              appserver. e.g. parsing annotations, programmatically or something else.

              i.e. Appserver/deployers is:
              Some artifacts -> metadata
              ejb3 is:
              ejbmetadata -> ejb3 container

              The examples I give are the MC and new classloader. Neither of these projects
              depend upon the deployers. Instead there are deployers that integrate this code.
              e.g. when I test unit test the classloaders, I just parse the
              jboss-classloading.xml (or create it programmatically) and then use the
              same ClassLoading api that is used by the classloader deployers.

              2) Standalone usage

              The individual projects should not depend upon the appserver's deployers
              or even the deployment api.
              Use case: If I want to re-use ejb3 programmatically I should just be
              able to instantiate the ejb3 metadata and make some call to a factory in the ejb3
              project.

              If I have to mock out deployment api (which I have to do with the current ejb3 api
              because it wronglg depends upon the deployers api)
              or otherwise make use of appserver specific stuff there is something wrong.

              This also reflects the idea that the deployer and runtime are different ideas/artifacts.
              i.e. the ejb3 deployer(s) are just responsible for creating and manipulating metadata
              then using the MC to activate it via the runtime component. (See for example
              the split we did of the Tomcat service).

              There should be no runtime parameters/service injection etc. onto the deployers
              that should be injected onto the runtime service.

              NOTE: There's another reason for this seperation which is we
              want to be able "bootstrap" an appserver configuration "offline" in
              a management client to verify it works without actually starting it.
              i.e. it just goes through the deployers and dependency validation without
              actually constructing the real services.
              This is impossible without a proper seperation.

              3) Configuration

              Deployer and runtime configuration is a policy decision of the appserver.
              If I want to swap out, augment or otherwise change how EJBMetaData gets
              constructed that is something that is done in the integration project i.e. the AS.

              The configuration files should therefore live there where they can be easily changed.

              To make version control easy/managable, it also makes sense for the deployer to live
              in the same codebase (although obviously not a requirement).

              But more importantly, there will be many different configurations/implementations.
              e.g. JBoss Embedded has a totally different mechansim (search the externally
              constructed "classpath") on how to find ejb deployments to
              what the appserver does.


              SUMMARY

              EJB3's job should be to provide a Runtime service that can be used to
              construct EJB3 container(s) from EJBMetaData (and others)
              with other service injections onto that service.

              The Appserver's job (or any other project) is to create that metadata
              (currently done using the aspectized deployers) and use that Runtime service
              (currently done via the MC).

              • 4. Re: Deployers in AS
                Andrew Rubinger Master

                 

                "adrian@jboss.org" wrote:
                The parsing available in the metadata project (from ejb-jar.xml and jboss.xml)
                should be enough to write your tests (using the same hooks that the deployers
                use to create the real objects).
                You don't care how the EJBMetaData gets constructed, that is a policy decision of the
                appserver. e.g. parsing annotations, programmatically or something else.


                This assumes that EJB3 is intended for use only within the AS Environment. The Deployers in question need be an integration point only between jboss-metadata/MC and ejb3/MC, not AS. If I want to start up an Embedded or Standalone EJB3 Environment, I should be able to use the same Deployers, as they depend only on the MC Deployment API and other dependencies of EJB3.

                "adrian@jboss.org" wrote:
                The individual projects should not depend upon the appserver's deployers
                or even the deployment api.
                Use case: If I want to re-use ejb3 programmatically I should just be
                able to instantiate the ejb3 metadata and make some call to a factory in the ejb3
                project.


                The EJB3 Components should not depend on the Deployers, true. Only metadata, and I'm doing a refactoring effort now to create Containers from only the metadata objects. The end result will eventually make programmatic creation of an EJB possible.

                However, an Assembly of EJB3 Standalone/Embedded should be able to re-use the same Deployers used in AS. That way, we don't have to create the metadata on our own by duplicating the logic already written.

                "adrian@jboss.org" wrote:
                Deployer and runtime configuration is a policy decision of the appserver.
                If I want to swap out, augment or otherwise change how EJBMetaData gets
                constructed that is something that is done in the integration project i.e. the AS.


                AS is not the only target integration project. So configuration is a policy decision of whatever is providing the runtime, and this is achieved by editing the ejb3-deployers-beans.xml file accordingly.

                S,
                ALR

                • 5. Re: Deployers in AS
                  Adrian Brock Master

                   

                  "ALRubinger" wrote:

                  This assumes that EJB3 is intended for use only within the AS Environment. The Deployers in question need be an integration point only between jboss-metadata/MC and ejb3/MC, not AS. If I want to start up an Embedded or Standalone EJB3 Environment, I should be able to use the same Deployers, as they depend only on the MC Deployment API and other dependencies of EJB3.


                  JBoss Embeded and JBoss AS sharing the same metadata processing features
                  (or not) is a different issue to what EJB3 should do with the metadata they supply


                  • 6. Re: Deployers in AS
                    Andrew Rubinger Master

                     

                    "adrian@jboss.org" wrote:
                    JBoss Embeded and JBoss AS sharing the same metadata processing features
                    (or not) is a different issue to what EJB3 should do with the metadata they supply


                    In this case, I'm talking strictly EJB3 Embedded, not JBossAS Embedded.

                    We've established and agreed upon the responsibility of EJB3 to produce EJBs from metadata, no matter how it's supplied.

                    Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree such that another Assembly may consume them without depending upon AS? In turn, AS would consume the same deployers and use them just as they are now, only on the CP as JARs.

                    S,
                    ALR

                    • 7. Re: Deployers in AS
                      Andrew Rubinger Master

                       

                      "ALRubinger" wrote:
                      Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree...


                      Aside from the pieces Scott has identified as needing abstraction and extraction. I just want to hear "Yes, this is possible with some work, and wouldn't violate a central tenant of the AS Structuring Rules."

                      S,
                      ALR

                      • 8. Re: Deployers in AS
                        Adrian Brock Master

                         

                        "ALRubinger" wrote:
                        "ALRubinger" wrote:
                        Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree...


                        Aside from the pieces Scott has identified as needing abstraction and extraction. I just want to hear "Yes, this is possible with some work, and wouldn't violate a central tenant of the AS Structuring Rules."


                        Yes, that's possible. But that's a minor task compared with making sure the
                        cart doesn't lead the horse, i.e. the EJB3 runtime doesn't depend upon the deployers.