2

Consider this use case:

We deploy to Wildfly 8.2, which includes many dependencies implicitly including in the classloader by the app server itself. Examples include things like HttpClient. To illustrate this in my example, we'll call this: libaryX-v1.jar.

And we deploy multiple EARs to the same install, which are provided by multiple teams within our organization, which are on different release and budgetary cycles.

TeamA.ear needs libraryX-v1.jar and is fully tested and certified with that version.

TeamB.ear needs libraryX-v2.jar, in particular new features to meet this teams requirements that are not included in any other version.

How do we deploy both of these EARs to Wildfly?

If TeamA had the budget to test and get certified using librayX-v2.jar, then the obvious solution would be to upgrade that module within Wildfly.

When we add libraryX-v2.jar to TeamB.ear, we get the following exception:

java.lang.LinkageError: loader constraint violation: when resolving method "org.apache.Example.<init>(Lorg/whatever/sharedClass;)V" 
the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, com/company/teamB/exampleService, and 
the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/apache/Example, 
have different Class objects for the type org/whatever/sharedClass used in the signature
peterl
  • 1,881
  • 4
  • 21
  • 34

1 Answers1

1

The problem will only arise when you interchange objects between the deployments. The way I prefer is to package all required libraries and to not refer to wildfly modules since these may change in future versions of the server. So in your case you should package libraryX-v1.jar in TeamA.ear as well as libraryX-v2.jar in TeamB.ear. At this point you are clean and compatible with future releases of wildfly, even if they upgrade (or for any reason) downgrade this module.

If you then need to exchange objects of libraryX between those two deployments it is not that easy because the different classloaders have loaded different classes. If it was that easy that libraryX was present in just one version you could simple deploy this library and refer to it from the ears. But in your case I think there is just the way to build a custom library with "interchange classes", deploy it and refer to it. afterwards take the information of the interchange object and create a new instance of a libraryX-object from it. You need a fixed contract for application communication.

shillner
  • 1,806
  • 15
  • 24
  • I agree with your desire to package all required libraries and not refer to wildfly modules, however this doesn't appear to work in Wildfly8.2. Even through the specified versions of each dependent JAR are in the related EARs, Wildfly is using the version from it's core modules instead. Based on [this documentation](https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly#ClassLoadinginWildFly-ClassLoading%26nbsp%3BPrecedence) the libraryX-vX.jar is being loaded as a dependency of a core Wildfly module that is implicitly added. – peterl Jul 15 '15 at 15:43
  • Sure, classes of Wildfly modules will also use the module version of the library, not the one you packaged in the EAR. But how does this affect your setup? Where is the object interchange between the wildfly module and both apps? Which module do you use? Please post a bit more information (code, jboss-deployment-structure.xml, ...) – shillner Jul 15 '15 at 19:12
  • You can see all the implicit dependencies added by the server and exclude ones that may be an issue. https://docs.jboss.org/author/display/WFLY8/Implicit+module+dependencies+for+deployments#Implicitmoduledependenciesfordeployments-Whicharetheimplicitmoduledependencies%3F – James R. Perkins Jul 16 '15 at 15:20