Bug 871413

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.

Ondřej Chaloupka <ochaloup> updated the status of jira JBPAPP-10282 to Closed

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.