Description of problem: We need a new Arquillian AS7 Adaptor for forward compatibility with EAP 6.0.1. Currently, there is a remote-jmx protocol incompatibilities, which are not fixed yet. Version-Release number of selected component (if applicable): Arquillian AS7 adaptor 7.1.1.Final, certified to be compatible with EAP 6.0.0 How reproducible: Always. Steps to Reproduce: 1. Use Arquillian AS7 adaptor 7.1.1 with EAP 6.0.1 to run your tests. Actual results: Arquillian hangs. Expected results: Arquillian deploys the application Additional info: Workaround is to manually update the dependencies in your project.
Sande Gilda <sgilda> made a comment on jira JBPAPP-10272 Paul, Vladimir, or Shelly: Do we need a new build of the jboss-eap-6.0.1.ER3-maven-repository to test this fix?
It seems that the main problem is incompatibility of org.jboss.remoting3:jboss-remoting. Arquillian AS 7.1.1 uses 3.2.3.GA. EAP6 6.0.1.ER2 uses 3.2.8.SP1 EAP6 6.0.1.ER3 uses 3.2.13.GA, which is incompatible with 3.2.3.GA Therefore, we need to update the jboss-remoting. Note, org.jboss.remoting3:remoting-jmx is not the faulty artifact, therefore both jmx and servlet 3.0 protocols are affected.
Paul Gier <pgier> made a comment on jira JBPAPP-10272 The bom update has been merged and rebuilt for EAP (JBPAPP-10284). And the quickstarts have been updated to use this new bom. Is there anything else that needs to be done for this?
Sande Gilda <sgilda> made a comment on jira JBPAPP-10272 I need to grab the latest Maven repo zip and test. I will comment here with the results.
Sande Gilda <sgilda> made a comment on jira JBPAPP-10272 I downloaded the latest ER3 Quickstarts and Maven repository and successfully ran the Arquillian tests for the following quickstarts. bean-validation ejb-in-war hibernate4 kitchensink kitchensink-ear kitchensink-html5-mobile kitchensink-jsp tasks tasks-jsf tasks-rs wsat-simple wsba-coordinator-completion-simple wsba-participant-completion-simple I would say this issue is resolved.
Paul Gier <pgier> updated the status of jira JBPAPP-10272 to Resolved
Ondřej Chaloupka <ochaloup> updated the status of jira JBPAPP-10282 to Closed
Ondřej Chaloupka <ochaloup> made a comment on jira JBPAPP-10282 Tests are working after the change of the remoting version. Closing this issue.
Misty Stanley-Jones <misty> updated the status of jira JBPAPP-10282 to Reopened
Misty Stanley-Jones <misty> updated the status of jira JBPAPP-10282 to Resolved
Vladimir Rastseluev <vrastsel> updated the status of jira JBPAPP-10272 to Reopened
Vladimir Rastseluev <vrastsel> made a comment on jira JBPAPP-10272 After discussing with Sande, I decided to reopen issue, because tests in managed container failed too. So, please do investigate both cases. To reproduce: export JBOSS_HOME=/path-to-EAP6.0.1ER3-server-installation run tests in managed container: mvn clean test -Parq-jbossas-managed
Rafael Benevides <benevides> made a comment on jira JBPAPP-10272 I added {code} <dependency> <groupId>org.jboss.remoting3</groupId> <artifactId>jboss-remoting</artifactId> <version>3.2.12.GA</version> </dependency> {code} in *dependencyManagement* section on ejb-in-war/pom.xml and it worked. It seems that something from *3.2.12.GA* to *3.2.12.GA-redhat-1* broke the tests.
Sande Gilda <sgilda> made a comment on jira JBPAPP-10272 Thanks for the clarification James. Let me know what you find out.
Karel Piwko <kpiwko> made a comment on jira JBPAPP-10272 It might not only be source changes, which are really limitied according to diff decompiled jars. It rather seems that transitive dependencies of jboss-remoting might play significant role: Community: <xnio.version>3.0.7.GA</xnio.version> <logging.version>3.1.0.GA</logging.version> <logging-tools.version>1.0.3.Final</logging-tools.version> <logmanager.version>1.2.0.GA</logmanager.version> <junit.version>4.8.2</junit.version> <byteman-version>2.0.0</byteman-version> Enterprise: xnio 3.0.7.GA-redhat1 logging 3.1.2.GA-redhat-1 logging-tools-1.0.3.Final-redhat-2 logmanager 1.3.2.Final-redhat-1 junit 4.10-redhat-1 byteman 2.0.1-redhat-1 My tip: logmanager
James Perkins <jperkins> made a comment on jira JBPAPP-10272 Definitely shouldn't have anything to do with the logmanager and really remoting shouldn't be bringing in any of those dependencies. I have confirmed something is bringing in an older version of remoting (org.jboss.remoting3:jboss-remoting=org.jboss.remoting3:jboss-remoting:jar:3.2.3.GA:test). I'm working on figuring out what's bringing it in now.
Sande Gilda <sgilda> made a comment on jira JBPAPP-10272 Thanks James. It looks like you're getting close. :-)
Pete Muir <pmuir.uk> made a comment on jira JBPAPP-10272 Thanks for investigating James and Cheng. There is no productized version of arquillian, we instead certify the community bits, and manage versions via the BOMs. Looking at Rafael's orginal workaround, you'll see that using 3.2.12.GA does work, but using 3.2.12.GA-redhat-1 does *not* work, which is very odd. Have either of you been able to verify this?
Paul Gier <pgier> made a comment on jira JBPAPP-10272 Using dependency management to force either 3.2.12.GA or 3.2.12.GA-redhat-1 works for me. The problem seems to be that several transitive deps bring in version 3.2.3.GA. The 3.2.3.GA version is closer (less transitive steps) to the current build in the dependency tree so it takes priority. {noformat} [INFO] \- org.jboss.as:jboss-as-arquillian-container-managed:jar:7.1.1.Final:test [INFO] +- org.jboss.remoting3:jboss-remoting:jar:3.2.3.GA:test [INFO] +- org.jboss.remotingjmx:remoting-jmx:jar:1.0.4.Final-redhat-1:test [INFO] | +- (org.jboss.remoting3:jboss-remoting:jar:3.2.12.GA-redhat-1:test - omitted for conflict with 3.2.3.GA) {noformat} I guess the right fix is to add the 3.2.12 version to dependencyManagement as rafabene did, or add it to the dependencyManagement in the jdf boms.
Paul Gier <pgier> made a comment on jira JBPAPP-10272 The reason this doesn't happen using arquillian-container-remote is because a-c-r does not have a direct dependency on jboss-remoting, so the 3.2.12.GA version ends up higher priority than the 3.2.3.GA version in the dep tree. Since relying on the transitive dependency version is unreliable in both cases, it is probably best to add depMgmt to the boms, just to make sure the correct version is always used.
Created attachment 652541 [details] -with-tools BOM file which contains the fix until 6.0.1.ER5 is out Attaching a <dependencyManagement> BOM which fixes the issue.
<!-- Specific version to make remoting compatible with EAP 6.0.1 --> <dependency> <groupId>org.jboss.remotingjmx</groupId> <artifactId>remoting-jmx</artifactId> <version>1.0.4.Final-redhat-1</version> </dependency> <dependency> <groupId>org.jboss.remoting3</groupId> <artifactId>jboss-remoting</artifactId> <version>3.2.13.GA-redhat-1</version> </dependency>
Marek, we need to update the -with-tools BOM file to handle that the very same way as we did for EAP 6.0.1.
OK, I looked at our 1.0.4.Final-redhat-1 and it is already there, so from BOM point of view we are done.
James, can you please try using 1.0.4-redhat-1 with-tools BOM from the attached zip and let us know whether it helps?
Created attachment 704810 [details] JBoss BOMs from WFK 2.2.0.ER1 Attaching a zip file with BOMs. Note, we changed groupId from org.jboss.boms to com.redhat.jboss.wfk.boms there. Version is 1.0.4-redhat-1.
Marking as verified in ER2. All test case QE has are able to run with the BOM file without any workaround being applied.
just for later reference WFK 2.2.0.ER2 changed the groupId back to org.jboss.bom and version for that change is 1.0.4.Final-redhat-wfk-1
Closed as CURRENTRELEASE, part of WFK 2.2.0 distributables.