Description of problem: If you are using Arquillian AS7.1.1 adaptor to connect/start an EAP 6.0.1 instance, after you apply workaround (bug #871413), you might get a following exception if you're using jmx-protocol, which is the default: java.lang.NoClassDefFoundError: org/jboss/as/osgi/deployment/OSGiDeploymentAttachment at org.jboss.as.arquillian.service.ArquillianConfig.loadClass(ArquillianConfig.java:118) at org.jboss.as.arquillian.service.ArquillianService$ExtendedTestClassLoader.loadTestClass(ArquillianService.java:259) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:125) at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:108) at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034) at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Version-Release number of selected component (if applicable): Arquillian AS 7.1.1.Final + EAP 6.0.1 How reproducible: Always. Steps to Reproduce: 1. Have an arquillian tests using jmx protocol with EAP 6.0.1 Actual results: It fails with an exception. Expected results: It works. Additional info: Works with Servlet protocol.
Note: Workaround here does not work in case that you deploy RAR deployment. You need JMX protocol for that.
Marek, can you remove JMX protocol from -with-tools BOM?
Pete Muir <pmuir.uk> made a comment on jira JDF-231 Karel, how do we do this? https://github.com/jboss-jdf/jboss-bom/blob/master/jboss-javaee-6.0-with-tools/pom.xml - it's not in the BOM, it's coming in transitively.
Karel Piwko <kpiwko> made a comment on jira JDF-231 After short research it seams that <exclusions> are not propagated from dependencyManagament neither if a BOM is imported or inherited. So, if we want achieve that, we would need to remove JMX from both AS7 adaptor and ARQ BOM. This is out of scope of JDF. JDF can provide a documentation that JMX protocol should not be used at best effort. Note, this means we can't completely exclude neither in WFK.
Pete Muir <pmuir.uk> made a comment on jira JDF-231 Thanks for looking at this. We already use the servlet adaptor already but we've lost the comments about why we have to explicitly specify it.
I won't remove the jmx protocol from jboss-javaee-6.0-with-tools BOM as it would pull different version anyway from dependency hierarchy.
Edited doc text to explicitly say that newer EAP than 6.0.1 are affected too.
Migrated to Jira
Rodney Russ <rruss> updated the status of jira WFK2-131 to Closed