4 Replies Latest reply on Feb 5, 2014 12:54 PM by Scot P. Floess

    I've gotten the examples working...now trying to use Arquillian to test an existing EJB project to no avail

    Scot P. Floess Newbie

      I've been able to use the examples provided with great success   This includes using JBoss EAP 6.1 - works like a charm.

       

      However, when attempting to now leverage Arquillian within my existing JEE project(s) I am having mixed results...

       

      For starters I put the appropriate configuration in my parent pom (the pom.xml attachment contains parts of my parent pom denoting what I've done but is not the complete pom.xml)...

       

      I then tried a simple test against some of my EJBs in one of my child sub-projects and noted that the container (EAP 6.1) started but nothing deployed.  Of course, I presumed I either messed up my parent pom...or I did something else wrong...

       

      So, I made a "new" child sub-project that inherited the parent pom and copied the code out of the area I was working with the Arquillian examples to test to see if it worked...  And it did...

       

      So leveraging the parent pom works fine   I added this to the BasketTest just for fun:

       

          @Deployment

          public static JavaArchive createDeployment() {

              JavaArchive retVal = ShrinkWrap.create(JavaArchive.class, "test.jar")

                  .addClasses(Basket.class, OrderRepository.class, SingletonOrderRepository.class)

                  .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");

       

              System.out.println ("\n*****\n" + retVal.toString(true) + "\n******\n");

       

              return retVal;

          }

       

      When the tests run, I see the deploy happen as well as the System.out.println above:

       

      *****

      test.jar:

      /META-INF/

      /META-INF/beans.xml

      /org/

      /org/arquillian/

      /org/arquillian/example/

      /org/arquillian/example/SingletonOrderRepository.class

      /org/arquillian/example/Basket.class

      /org/arquillian/example/OrderRepository.class

      ******

       

      14:08:04,639 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/sfloess/Tools/jboss-eap-6.1-arquillian/standalone/data/content/41/06d7b776caae94b290486c1b8fa8b8e7ff4e29/content

      14:08:04,643 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "test.jar" (runtime-name: "test.jar")

      14:08:04,747 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment test.jar

      14:08:04,757 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named SingletonOrderRepository in deployment unit deployment "test.jar" are as follows:

       

              java:global/test/SingletonOrderRepository!org.arquillian.example.OrderRepository

              java:app/test/SingletonOrderRepository!org.arquillian.example.OrderRepository

              java:module/SingletonOrderRepository!org.arquillian.example.OrderRepository

              java:global/test/SingletonOrderRepository

              java:app/test/SingletonOrderRepository

              java:module/SingletonOrderRepository

       

      I am running maven as such:

       

      mvn -P JBoss-EAP-6.1 -DjbossHome=[path to EAP 6.1] clean install test

       

      Please note, the value I do use for jbossHome does point to my EAP 6.1 dir

       

      I then decided to grab the pom from my EJB sub-project and copy it to the new arquillian sub-project to see if that's the culprit.  Sure enough, the container starts but nothing is deployed.  In fact, I never see the output either (meaning the createDeployment is not being called).  Again, I use the aforementioned maven command line...

       

      Oddly, I thought I'd omit the JBoss-EAP-6.1 profile to see what happens...  Interestingly enough I do see the System.out's happen - so I know Arquillian is working...but of course it fails because I didn't specify the container:  org.arquillian.example.BasketTest: DeploymentScenario contains a target (_DEFAULT_) not matching any defined Container in the registry.(..)

       

      So what I see is when I enable my JBoss-EAP-6.1 profile something breaks in such a way that Arquillian doesn't run the test (note the Deployment annotated method is not called).

       

      I'm betting there is some dependency mess getting in the way on my end (in my pom) but I'm not sure what it is or how to better diagnose/fix...

       

      Any and all help is appreciated!!!!

        • 1. Re: I've gotten the examples working...now trying to use Arquillian to test an existing EJB project to no avail
          Karel Piwko Master

          Hi Scot,

           

          I believe that your problem is caused by having arquillian.launch property. This property is used to distinguish in between <groups> in arquillian.xml, hence in your case is is completely useless and might confuse Arquillian as you have no groups. Arquillian by default selects container based on what's on classpath, hence if you omit profile, you don't have jboss-as-arquillian-managed on CP and hence no Container in registry. You can safely delete your surefire config.

          Debugging note: You get much more info if you specify -Darquillian.debug=true. Arquillian will print out its lifecycle so you will know exactly where it got stuck. You can paste it here and I can further investigate whats wrong.

           

          And final note, you adding ShrinkWrap Resolver into your project, although you are not using it in your tests as far I a see from your code snippets, correct dependency is (version will be managed by BOM you've added to <dependencyManagement> section:

           

          <dependency>
            <groupId>org.jboss.shrinkwrap.resolver</groupId>
            <artifactId>shrinkwrap-resolver-depchain</artifactId>
            <scope>test</scope>
            <type>pom</type>
          </dependency>

           

          HTH,

           

          Karel

          1 of 1 people found this helpful
          • 2. Re: I've gotten the examples working...now trying to use Arquillian to test an existing EJB project to no avail
            Scot P. Floess Newbie

            Karel,

             

            Thank you so much for the help...

             

            All good suggestions...and alas, I watered down exactly what I'm doing...

             

            A few notes on why I've done a few things...and responding to your points:

             

            - arquillian.launch property:  I actually do want to have this and can explain why...  I'd like to be able to denote multiple profiles:  one so developers can test locally with their own local EAP 6.1 JBoss installation and one where we have a remote instance.   The remote instance will be used by Jenkins and live near it.  I didn't want to force our remote developers to use the remote instance, so I've denoted a remote and a local profiles and tied those profiles to different arquillian containers within the arquillian.xml file.  However, noted and good point

             

            - Shrinkwrap resolver:  another good point.  Unfortunately, our project is currently divided into a number of sub-projects which generate different artifacts:  a common project, an ejb project, a war project, etc.  For the war project, it has maven artifact dependencies on the EJB project but the code is not shared directly.  In fact, in the war project it's denoted as a "provides" scope as those artifacts are actually deployed within an EAR separate to the WAR.  As I was attempting to test with Arquillian, both the ejb and war projects were failing in ways that confused me (mostly due to my newness to using Arquillian).  To test, I created a new sub-project and wanted to go after artifacts as built in the war and ejb projects.  The classes I need are accessible using the Maven.resolver().logPomFromFile(...).resolve(...).withTransitivity().asFile().   I only stumbled upon that when classes weren't being found   Again I created this additional sub-project as I had no idea what was not working in the ejb and war projects.  Also, when we do start testing our war sub-project, we'll need access with this mechanism.

             

            - arquillian.debug=true:  that one I didn't know about (perhaps I read it and in my haste payed no attention) - but awesome!  Very very useful indeed!

             

            On a good note, I did figure out what's not working and it's exactly as I suspected:  a dependency issue when related to enabling a profile   We have some older dependencies denoted in our poms - this one is specifically causing my issue:

                       <dependency>

                         <groupId>jboss</groupId>

                         <artifactId>jboss-common</artifactId>

                         <version>4.2.3.GA</version>

                         <scope>provided</scope>

                     </dependency> 

             

            The correct (new) version is:

                       <dependency>

                         <groupId>org.jboss.logging</groupId>

                         <artifactId>jboss-logging</artifactId>

                         <version>3.1.2.GA-redhat-1</version>

                         <scope>provided</scope>

                     </dependency>    

             

            What I did to discover the culprit is this:  I took the examples (Basket, SingletonOrderRepository, OrderRepository and BasketTest) and made a sub-project using the pom from my ejb sub-project.  I started working from top to bottom of our dependencies commenting out each and rerunning the tests.  Turns out this dependency was being used as we are utilizing the JBoss logging class.

             

            I likely need to review our poms to ensure we are using the correct versions of libraries for EAP 6.1.

             

            Again, thank you for the reply and the insightful comments!  Very very much appreciated!

             

            • 3. Re: I've gotten the examples working...now trying to use Arquillian to test an existing EJB project to no avail
              Karel Piwko Master

              Scot,

               

              I'm happy that you resolved your issue, at least partially. Setup is unfortunately often complicated. I have few more notes:

               

              - arquillian.launch property:  I actually do want to have this and can explain why...  I'd like to be able to denote multiple profiles:  one so developers can test locally with their own local EAP 6.1 JBoss installation and one where we have a remote instance.   The remote instance will be used by Jenkins and live near it.  I didn't want to force our remote developers to use the remote instance, so I've denoted a remote and a local profiles and tied those profiles to different arquillian containers within the arquillian.xml file.  However, noted and good point

              Makes sense and can be used that way. Just make sure that you always define arquillian.launch - especially in IDE. If there is no match, Arquillian will apply the latest container configuration from arquillian.xml to current container which might not be for actual container on classpath. This causes very weird issues.

               

              - Shrinkwrap resolver:  another good point.  Unfortunately, our project is currently divided into a number of sub-projects which generate different artifacts:  a common project, an ejb project, a war project, etc.  For the war project, it has maven artifact dependencies on the EJB project but the code is not shared directly.  In fact, in the war project it's denoted as a "provides" scope as those artifacts are actually deployed within an EAR separate to the WAR.  As I was attempting to test with Arquillian, both the ejb and war projects were failing in ways that confused me (mostly due to my newness to using Arquillian).  To test, I created a new sub-project and wanted to go after artifacts as built in the war and ejb projects.  The classes I need are accessible using the Maven.resolver().logPomFromFile(...).resolve(...).withTransitivity().asFile().   I only stumbled upon that when classes weren't being found   Again I created this additional sub-project as I had no idea what was not working in the ejb and war projects.  Also, when we do start testing our war sub-project, we'll need access with this mechanism.

               

              You can try MavenImporter feature. Although it is experimental, it supports WAR and JAR building from pom.xml file (EAR in development). It is ideal if you want to package full application for your tests and you have a defining pom.xml. Documentation at ShrinkWrap Resolver GitHub page.

               

              I likely need to review our poms to ensure we are using the correct versions of libraries for EAP 6.1.


              There is already EAP 6.2. Anyway, I recommend to follow this guide: https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html-single/Development_Gui…

              You should not define any dependency version in your pom file, they should all come from BOM file. -with-tools BOM contains certified versions of Arquillian/ShrinkWrap. There might be additional Arquillian goodies in JBoss WFK.

              1 of 1 people found this helpful
              • 4. Re: I've gotten the examples working...now trying to use Arquillian to test an existing EJB project to no avail
                Scot P. Floess Newbie

                Karel,

                 

                Making note of MavenImporter - thanks!

                 

                The en-US/JBoss_* link you mention - that's where I discovered the logger dependency - absolutely great point   To be honest when saying that I should review/fix our poms - I really meant looking at that doc

                 

                Regarding the bom - I definitely want to go that route and use it...  Oddly there must be something wrong with our pom(s) or I've done something wrong, but I found a few annotations weren't available - notably @SecurityDomain (org.jboss.ejb3.annotation.SecurityDomain).  However, earlier I didn't know what was causing my issues