6 Replies Latest reply on Feb 7, 2010 2:56 PM by Aslak Knutsen

    What is DeploymentAppenderArchiveGenerator?

    Andrew Rubinger Master

      I'm working on the OpenEJB Container Integration for Arquillian.

       

      DeployableTest has:

       

         public ArchiveGenerator getArchiveGenerator() 
         {
            if(DeployableTest.isInContainer()) 
            {
               return new NullArtifactGenerator();
            }
            return new DeploymentAppenderArchiveGenerator(new UserCreatedArchiveGenerator());
         }

       

      What is DeploymentAppenderArchiveGenerator?  Why not pass the Archive I've made directly into the DeployableContainer.deploy?

       

      S,

      ALR

        • 1. Re: What is DeploymentAppenderArchiveGenerator?
          Andrew Rubinger Master

          And as a corallary:

           

          UserCreatedArchiveGenerator:

                   if(ClassContainer.class.isInstance(archive)) 
                   {
                      ClassContainer<?> classContainer = ClassContainer.class.cast(archive);
                      classContainer.addClass(testCase);
                   }
          

           

          Why are we adding the test class into the user-specified @Deployment?

           

          S,

          ALR

          • 2. Re: What is DeploymentAppenderArchiveGenerator?
            Aslak Knutsen Master

            This is where the upcoming DeploymentPackager SPI comes into play. Each container could have it's own way of packaging. JBoss and Glassfish support ear/war, OpenEJB some jar struct, Weld SE a Bean Archive..

             

            As for now the packaging is handled in only one way, and it assumes a EE ear.

             

            What i've come up with so far is:

             

            The DeploymentAppender SPI:

            - so that any module can append a archive to the final deployment to the container.

             

            The DeploymentEnricher SPI:

            - so any module can add stuff to a module added archive, ie for CDI to add beans.xml

             

            The DeploymentPackager SPI:

            - container controlled packager that 'merges' it into a format that the container can understand

             

            a some what flow in code would be:

            {code}

            container.deploy

            (

            DeploymentPackager.package

            (

               DeploymentEnricher.enrich

               (

                 DeploymentAppender.createArchives()

               )

            )

            )

            {code}

             

            And to answer why you can't just pass your archive to the container.. that works in your embedded container case, but in a local / remote container, we need to add a lot of 'stuff' to the deployment for it to run ie: The Arquillian TestRunner(+ JUnit/TestNG), The Arquillian Core, The protocol for communication with the container, The TestEnrichers for injection in container....

            • 3. Re: What is DeploymentAppenderArchiveGenerator?
              Andrew Rubinger Master

              We're headed down the road to opinionated software.

               

              Here's my use case:

              @Deployment
              public static JavaArchive createDeployment()
              {
                 return Archives.create("slsb.jar", JavaArchive.class).addClasses(EchoLocalBusiness.class, EchoBean.class);
              }
              

               

              I need that deployed.  I don't want it wrapped with any Arquillian stuff, nor altered in any way.  When we do, it blows up.  It's an exaggeration of the uncertainty principle (and observer effect):


              http://en.wikipedia.org/wiki/Observer_effect_%28physics%29

               

              You cannot observe without changing the environment.

               

              This gets down to a design goal: I don't think that the mission of the Arquillian project should be "to run your tests inside a Container".  I think instead it should be "manage container and deployment transparently alongside test lifecycle".

               

              Though running your tests *inside* the container as a deployment is a great feature, I don't think it can be the cornerstone of the project or the default mechanism.  For these reasons:

               

              • When you wrap a user JAR deployment, you change the Global JNDI name of EJBs
              • Target containers may not understand what you're giving them
              • Assuming the user deployment is an EAR, you wrap it in another EAR?  Uh oh.
              • The test, expecting @EJB injection of remote proxies for instance, will skip the remoting layer, and that doesn't get tested
              • The user is no longer testing what they expect; I was shocked to see my @Deployment wasn't being passed along unaltered

               

              aslak wrote:

               

              This is where the upcoming DeploymentPackager SPI comes into play. Each container could have it's own way of packaging. JBoss and Glassfish support ear/war, OpenEJB some jar struct, Weld SE a Bean Archive..

               

              As for now the packaging is handled in only one way, and it assumes a EE ear.


              I'll have to see more about this DeploymentPackager, but it sounds scary as a default.  We let the user specify their deployment; that *is* the package.  In the more rare case that you want to run the test as part of the deployment, that to me is an additional feature and separate concern.

               

              Assumptions are fine if they mimick the default or expected behaviour.  And IMO any assumptions you make *must* be configurable by the user to specify what they need.

               

              aslak wrote:

              And to answer why you can't just pass your archive to the container.. that works in your embedded container case, but in a local / remote container, we need to add a lot of 'stuff' to the deployment for it to run ie: The Arquillian TestRunner(+ JUnit/TestNG), The Arquillian Core, The protocol for communication with the container, The TestEnrichers for injection in container....

               

              I think you've just laid out a fine case for remoting as an aspect.   The most simple case is direct deployment to a local container.  Just forward it along.  If other containers need special handling, then some chain of wrappers may be necessary.  But the core bits are very simple: take the user deployment and put it into the container.

               

              At present moment I'm blocked with doing OpenEJB integration (and GlassFish too) as I want to change the behaviour currently in place in "DeployableTest" (or not use it entirely), but I don't know what I'll break.  More testsuite coverage will help with that.

               

              S,

              ALR

               

               

               


              • 4. Re: What is DeploymentAppenderArchiveGenerator?
                Aslak Knutsen Master

                Here's my use case:

                @Deployment
                public static JavaArchive createDeployment()
                {
                   return Archives.create("slsb.jar", JavaArchive.class).addClasses(EchoLocalBusiness.class, EchoBean.class);
                }
                

                 

                I need that deployed.  I don't want it wrapped with any Arquillian stuff, nor altered in any way.  When we do, it blows up.  It's an exaggeration of the uncertainty principle (and observer effect):

                 

                This is where the DeploymentPackager SPI comes into play. In your case, you only want the users deployment for the OpenEJB integration, you can then let Arquillian use your DeploymentPackager that does not add any other stuff.. since this is a embedded container it should work fine. (same goes for ie Weld-se container).

                • 5. Re: What is DeploymentAppenderArchiveGenerator?
                  Andrew Rubinger Master

                  Neat; how can I wire up a no-op DeploymentPackager?  Or are we not quite there yet and this needs more work?

                   

                  S,

                  ALR

                  • 6. Re: What is DeploymentAppenderArchiveGenerator?
                    Aslak Knutsen Master

                    Not quite there yet..

                     

                    DeploymentPakager and DeploymentEnricher are new SPIs, just on the drawing board inside my head..

                     

                    What we have today is a hardcoded 'DeploymentPackager'(DeploymentAppenderArchiveGenerator) that sucks in all the DeploymentAppeners and creates a ear.