3 Replies Latest reply on Oct 4, 2012 9:12 PM by john.genoese

    The 1.0.2.Final Testable class: are there any limitations on its use e.g. loading EAR from Filesystem ?

    john.genoese

      Greetings.

       

      In my attempts to use the new Testable class in Arq 1.0.2.Final, I am still getting some behavior that I didn't expect.

       

      Back story:

      Because my integration test deployments are somewhat elaborate, and because there are quite a few tests, each having a @Deployment, I try to save some execution time by writing out the Arquillian-produced EAR to a file on the first @Deployment, and then have each subsequent @Deployment create the archive from the file system instead of rebuilding it from scratch. It works like a charm.

       

      Eventually, I required references to WebServices, also being developed as part of the same project. Rather than create a dependency upon some external environmental condition, I decided to package the web service WAR along with my test war. The test failed, with the following message:

       

       

      Failed tests: ...

       

        arquillianBeforeClass(org.memoriesdreamsandreflections.waipt_procedures.beans.ClientServicesWSBackerIntegrationTest): Multiple WebArchives found in test-procedures-13032.ear. Can not determine which to enrich

       

      Of course, a moment's clear thought revealed that I should not have expected anything else. Then I found out about 1.0.2.Final with its new Testable class, and I was elated. I promptly moved my Arquillian POM version up to 1.0.2.Final, and wrapped my WebArchive creation in a Testable.archiveToTest() method call.

       

      Unexpected behavior:

      The first test to execute works just fine, and executes the web service appropriately. The EAR undeploys as expected. However, the next test fails, with the same message as shown above. This is completely unexpected. To test my theory that the effect of Testable was lasting only for one test, I added the -Dtest= parameter to the Integration test launcher, to explicitly run the test that had failed. It ran without geting the message.

       

      Are there any known limitations on the serial deployability of wars marked with the META-INF/arquillian.ArchiveUnderTest marker file?

       

      Thanks.

        • 1. Re: The 1.0.2.Final Testable class: are there any limitations on its use?
          aslak

          Your reading the EAR from disk pr Test Class @Deployment?

           

          Sounds very strange that the Marked WAR would only be understood the first time..

           

          Could you provide some code that shows how you are doing it, would make it easier to understand why it might happen.

          • 2. Re: The 1.0.2.Final Testable class: are there any limitations on its use?
            john.genoese

            Thank you for responding. I apologize in advance for this inordinately-sized post.

             

            The approach I took in building integration tests for a given App module was

            1. Create an integration test base class to contain the @Deployment method and other commonly needed utilities for composing Integration tests for the module at hand
            2. Create an ArchiveUtil class to wrap the entire procedure of creating the EAR file. This class in constructed in such a way as to include the current PID in the name of the EAR. The class will look for an EAR by that name on the filesystem. If it finds it, it loads it using the wonderful ShrinkWrap::createFromZipFile(). Otherwise it builds the EAR in the normal ShrinkWrap way and writes it out using the wonderful EnterpriseArchive::as( ZipExporter.class ).exportTo().
            3. Have the base class use said ArchiveUtil to return the EAR
            4. Compose all Integration tests extending said base class.

             

            Attached are:

            ArchiveUtil.java : the archive util referenced abwove

            jboss.log: the log output in its entirety

            TestSuite.txt: TestNG output.

            testng-results.xml: documents that one test class passed and the next failed; the rest were skipped.

             

            Here's the EAR written to the filesystem:

             

            [jgenoese@mdr:/tmp/x] [bash:53] Wed Oct 03 11:05:07

            $:jar -tvf ../test-procedures-69275.ear  | grep -v "lib\/"

            72470 Wed Oct 03 10:23:30 EDT 2012 test.war

            41360 Wed Oct 03 10:23:30 EDT 2012 waipt-lockbox-war-0.1.war

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/

               330 Wed Oct 03 10:23:30 EDT 2012 META-INF/jboss-deployment-structure.xml

               620 Wed Oct 03 10:23:30 EDT 2012 META-INF/waimap-ds.xml

             

            Here's the relevant content of test.war:

             

            [jgenoese@mdr:/tmp/x] [bash:67] Wed Oct 03 11:08:32

            $:jar -tvf test.war | grep -v "\/classes"

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/arquillian.ArchiveUnderTest

                 0 Wed Oct 03 10:23:30 EDT 2012 WEB-INF/

               565 Wed Oct 03 10:23:30 EDT 2012 WEB-INF/beans.xml

             

            Here's the relevant content of the war NOT under test:

             

            [jgenoese@mdr:/tmp/x] [bash:69] Wed Oct 03 11:10:58

            $:jar -tvf waipt-lockbox-war-0.1.war |  grep -v "\/classes"      

               343 Wed Oct 03 10:23:30 EDT 2012 index.html

                 0 Wed Oct 03 10:23:30 EDT 2012 WEB-INF/

               286 Wed Oct 03 10:23:30 EDT 2012 WEB-INF/beans.xml

              1086 Wed Oct 03 10:23:30 EDT 2012 WEB-INF/web.xml

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/maven/

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/maven/org.memoriesdreamsandreflections/

                 0 Wed Oct 03 10:23:30 EDT 2012 META-INF/maven/org.memoriesdreamsandreflections/waipt-lockbox-war/

               132 Wed Oct 03 10:23:30 EDT 2012 META-INF/maven/org.memoriesdreamsandreflections/waipt-lockbox-war/pom.properties

              9476 Wed Oct 03 10:23:30 EDT 2012 META-INF/maven/org.memoriesdreamsandreflections/waipt-lockbox-war/pom.xml

               127 Wed Oct 03 10:23:30 EDT 2012 META-INF/MANIFEST.MF

             


            • 3. Re: The 1.0.2.Final Testable class: are there any limitations on its use?
              john.genoese

              Further experimentation yields results that strongly suggest a definite issue with use of Testable, or with its use in Arquillian internals.

               

              When I add the following lines to my ArchiveUtil after retrieving the EAR file from the filesystem, the "can not determine which to enrich" failure no longer occurs.

               

                   WebArchive l_wa = l_ea.getAsType( WebArchive.class, ArchivePaths.create("test.war") );

                   Assert.assertTrue( Testable.isArchiveToTest( l_wa ), "No testable archive" ) ;

               

              Commenting them out causes the failure to reappear.

               

              The attachment "ArchiveUtilExtended.java" is the new source replacing ArchiveUtil.java above.

               

              So my  answer thusfar is as follows:

              1. YES there is a limitation in the use of the Testable class, when deploying a filesystem-based EAR. The cause of the limitation is as yet unknown.

              2. An effective workaround for use of Testable with filesystem-based EARs is to manually invoke Testable::isArchiveToTest() on the testable WAR. This appears to mitigate whatever the issue is. The reason why the workaround is effective is as yet unknown.