CODEWITHSUNDEEP
javajbossclassloaderwildflywildfly-8
peterl
peterl

Reputation: 1931

How do you deploy EARs to Wildfly with Different JAR versions then Wildfly provides?

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

Upvotes: 2

Views: 1358

Answers (1)

shillner
shillner

Reputation: 1846

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.

Upvotes: 2

Related Questions