6 Replies Latest reply on Jun 8, 2013 12:09 PM by aslak

    Arquillian & JBoss EAP 6.1

    meetoblivion

      Hi all

       

      I'm trying to upgrade my company's app from AS 7.1.1 to the commerce EAP 6.1, since this is our targetted runtime.  On my laptop, I get these exceptions when trying to run tests:

       

      12:31:06,478 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: com.sparta.ee.test.dao.DaoServiceTest.createLicense: java.lang.NoClassDefFoundE

      rror: org/jboss/as/osgi/deployment/OSGiDeploymentAttachment

              at org.jboss.as.arquillian.service.ArquillianConfig.loadClass(ArquillianConfig.java:118) [arquillian-service:]

              at org.jboss.as.arquillian.service.ArquillianService$ExtendedTestClassLoader.loadTestClass(ArquillianService.java:259) [arquillian-service:]

              at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:125) [arquillian-service:]

              at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:108) [arquillian-service:]

              at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:226) [arquillian-service:]

              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09]

              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09]

              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09]

              at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250) [rt.jar:1.7.0_09]

              at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_09]

              at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) [rt.jar:1.7.0_09]

              at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)

              at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)

              at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1058)

              at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:225)

              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]

              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]

              at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]

      Caused by: java.lang.ClassNotFoundException: org.jboss.as.osgi.deployment.OSGiDeploymentAttachment from [Module "deployment.arquillian-service:main" from Service Module Loader

      ]

              at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]

              at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]

              at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]

              ... 23 more

       

      Any idea why it might be missing? The only changes I made was to point to the managed container v 7.2.0.Final (which is what EAP is based on).

       

      Thanks!

        • 1. Re: Arquillian & JBoss EAP 6.1
          meetoblivion

          Ah ha!

          So it turns out in EAP 6.1 the OSGi runtime is gone.  Apparently arquillian is using it over JMX.

           

          So the solution is to use servlet protocol.

           

          However, when I use servlet protocol arquillian wraps a war around my archive, and doesn't keep my jboss-deployment-structure.xml

           

          FML.

          • 2. Re: Arquillian & JBoss EAP 6.1
            aslak

            You using the AS 7.2.0 Adapter?

             

            And yea, the Servlet protocol requires the Deployment to be able to hold a Servlet. So if it's a Jar you deploy, it will wrap it in a War. If it's Ear it will add a War. If it's a War it will only merge it self.

             

            https://docs.jboss.org/author/display/ARQ/Servlet+3.0

            • 3. Re: Arquillian & JBoss EAP 6.1
              meetoblivion

              Right, the problem's that I typically give Arquillian a prebuilt JAR (from maven).  I would expect that any jboss specific needs to work with that JAR should be covered by their frameworks :-)

               

              A while back I created https://issues.jboss.org/browse/ARQ-1256 for this specific issue.  Thinking about it some more, could we use a @Descriptor to perhaps provide the jboss-deployment-structure.xml that the wrapped WAR should include?

              • 4. Re: Arquillian & JBoss EAP 6.1
                aslak

                What are you using jboss-deployment-structure.xml for ?

                • 5. Re: Arquillian & JBoss EAP 6.1
                  meetoblivion

                  Lots of reasons.  We deploy essentially an exploded ear into the AS7 deployment directory.  So we need to link those archives together.  The other thing we do is link into the local modules that AS7 ships with.  So we end up creating a very skinny JAR and WAR by leveraging the app server provided libraries.  For example, we use guava all over the place.  so it just makes sense to use the guava provided by AS7 (even though we could bring in a different version).  If you recall, I had mentioned some time back that we are actually deploying many archives for arquillian - upwards of 15 now in a single test case.  These archives need to be classloaded together.  jboss-deployment-structure.xml does all of that work.

                  • 6. Re: Arquillian & JBoss EAP 6.1
                    aslak

                    Right..

                     

                    So you've attempted to deploy your Jar as a Library within a War. And you had the jboss-deployment-structure.xml in the jar but it wasn't picked up?

                     

                    A bit odd that a sub library can't define it's own structure within a std war. On top of my head that sounds like a bug.

                    I know jar's within a war respect the Manifest Dependencies: attribute.