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