4 Replies Latest reply on Sep 6, 2010 8:20 AM by thomas.diesler

    Shrinkwrap usage in Arquillian tests

    thomas.diesler
    thomas.diesler Sep 6, 2010 5:37 AM

      There are a number of tests that generate shrinkwrap bundles during the execution of test methods. While this was ok for Husky (because we had client side test method execution + explicit call into the husky Bridge + in-framework execution of the remainder of the test method) it is no longer valid for ARQ tests.

       

      If a test methods runs within an OSGi framework I is not clear to me how it can dynamically generate bundles with shrinkwrap. Where do the classes/resources that are packaged with shrinkwrap come from? Does the test package contain and export these assets? Do they reside on the system classpath and are available from there? IMO neither of the last two statements is true.

       

      Currently the BundleSmokeTestCase is disabled because of this issue. That arquillian-osgi-bundle contains and exports the shrinkwrap API is probably ok, but it should not contain the shrinkwrap-impl because we cannot generate Archives from within the OSGi container anyway. This becomes especially apparent when you think about a remote OSGi container (i.e. AS7)

       

      IMHO, we need a notion of a repository (e.g. similar to ~/.m2/repository) where the client portion of the ARQ test case execution can put the Archives that are needed during in-container testing

       

       

      @Deployment
public static Archive<?> createMainTestDeployment()
{
...
}

@SomeOtherDeployment("foo")
public static Archive<?> createFoo()
{
...
}

@SomeOtherDeployment("bar")
public static Archive<?> createBar()
{
...
}

@Test
public void testFoo()
{
     Bundle foo = OSGiContainer.install("foo");
     ...
}

       

      Alternatively, there could be some sort of callback via the JMX protocoll such that the in-container test method can callback to the client side to fetch an Archive on demand.

       

      ARQ-194 Support multiple bundle deployments

      • 9822 Views
      • Tags:
        • 1. Re: Shrinkwrap usage in Arquillian tests
          bosschaert
          bosschaert Sep 6, 2010 6:18 AM (in response to thomas.diesler)

          Thomas Diesler wrote:

           

          Currently the BundleSmokeTestCase is disabled because of this issue. That arquillian-osgi-bundle contains and exports the shrinkwrap API is probably ok, but it should not contain the shrinkwrap-impl because we cannot generate Archives from within the OSGi container anyway. This becomes especially apparent when you think about a remote OSGi container (i.e. AS7)

          I don't fully understand why a bundle (a test bundle) can't create another bundle and install that. Whether this runs in a remote container or not.

          So here's how this is done in the BundleSmokeTestCase. This test is in itself a bundle, which is installed in the remote container. When executed, it creates a potentially large number (the exact amount is parameterized) of bundles and installs these. The classes inside the dynamically generated bundles are bundled up as part of the bundle that contains the BundleSmokeTestCase so available to Shrinkwrap from there (never from the System classpath).

          This test uses Shrinkwrap purely as a utility. It could also use plain Java calls to create the archive, but with Shrinkwrap it's obviously a lot easier. Whether Shrinkwrap is part of the arq bundle, or a separate bundle is a matter of taste IMHO...

           

          The problem with the annotation approach is that for the BundleSmokeTestCase (and it's performance related variations) it's not flexible enough, as you want to be able to parameterize the test to run with hundreds, potentially thousands of bundles. Currently that's just a number passed in. That doesn't work if every bundle requires a separate annotation.

            • Actions
          • 2. Re: Shrinkwrap usage in Arquillian tests
            thomas.diesler
            thomas.diesler Sep 6, 2010 6:47 AM (in response to bosschaert)

            You are saying that the test archive (i.e. the one generated by @Deployment) must contain the superset of all assets that are used by shrinkwrap from within test methods.

             

            If the test archive exports/imports packages put into a shrinkwrap generated bundle, you have two bundles exporting the same package.

            If the test archive does not export/import packages put into a shrinkwrap generated bundle. You have two class loaders for the same package and the test archive cannot integrate with the shrinkwrap generated bundle.

             

            I claim that all test bundles must be generated on the client side with shrinkwrap loading assets from the test client's classpath.

            A requirement we often have is that a given package is contained in a single bundle only. How can an ARQ test bundle generate such a bundle?

              • Actions
            • 3. Re: Shrinkwrap usage in Arquillian tests
              bosschaert
              bosschaert Sep 6, 2010 7:04 AM (in response to thomas.diesler)

              Thomas Diesler wrote:

               

              You are saying that the test archive (i.e. the one generated by @Deployment) must contain the superset of all assets that are used by shrinkwrap from within test methods.

              correct, that's how I used it

               

              If the test archive exports/imports packages put into a shrinkwrap generated bundle, you have two bundles exporting the same package.

              If the test archive does not export/import packages put into a shrinkwrap generated bundle. You have two class loaders for the same package and the test archive cannot integrate with the shrinkwrap generated bundle.

              in my case the test bundle doesn't export the package of the classes used by the generated bundles. Integration with the test bundles wasn't an issue for me as I just used JRE provided types for that, but if you want to use your own types that should still not be an issue as long as interfaces are used that are available in a shared bundle.

               

              I claim that all test bundles must be generated on the client side with shrinkwrap loading assets from the test client's classpath.

              A requirement we often have is that a given package is contained in a single bundle only. How can an ARQ test bundle generate such a bundle?

              If it's is an absolute requirement that only 1 bundle contains a given package, you could store the class files you need in your dynamic bundles as resources in some resource directory in your test bundle so that the classloader will never see them as classfiles.

               

              Bottom line for me is that I don't have a strong preference how this is done, as long as it's possible to do...

                • Actions
              • 4. Re: Shrinkwrap usage in Arquillian tests
                thomas.diesler
                thomas.diesler Sep 6, 2010 8:20 AM (in response to bosschaert)

                As the outcome of this discussion I'd like to see a design proposal for dynamically generated test bundles that generally works for both the embedded and remote scenario. Remote OSGi testing is important for our AS7 integration goals. Lets discuss this further in one of our next calls.

                  • Actions