0 Replies Latest reply on Jun 12, 2019 1:48 PM by jfisherdev

    Guava and jcl-over-slf4j in wildfly-jms-client-bom

    jfisherdev

      I recently upgraded from WildFly 9.0.2.Final to WildFly 16.0.0.Final.

       

      I have been using the jboss-client.jar in standalone client apps, but am in the process of switching to using the wildfly-ejb-client-bom and wildfly-jms-client-bom dependencies.

       

      One of the main reasons for this is I discovered some classpath conflicts due to the introduction of some new dependencies for the JMS client on more commonly used libraries--commons-beanutils, commons-collections, and commons-logging to name a few. Most of the issues were from the client apps including much older versions of these libraries. Updating the versions accordingly fixed the issue and allowed these to continue using jboss-client.jar for now, but I am moving away from using it so applications can properly manage potential conflicts and what versions they use as needed.

       

      There are two dependencies I am seeking clarification on why they are there:

      • com.google.guava:guava
      • org.slf4j:jcl-over-slf4j
        • org.slf4j:slf4j-api is a related dependency

       

      I did some comparison with the 2.6.3 version of the org.apache.activemq:artemis-jms-client and org.apache.activemq:artemis-hqclient-protocol artifacts [I see this is not the exact same as the version in the bom, which is 2.6.3.jbossorg-00014 for some reason]. I understand this is not the exact same, but it helped me understand that the commons-beanutils and commons-collections dependencies were coming from the artemis artifacts, and that the jcl-over-slf4j is taking the place of the commons-logging dependency these have, which I guess is one of the items I am curious about. I could not find an obvious explanation for the Guava dependency.

       

      Any information on this would be appreciated.