consider use case:
we deploy wildfly 8.2, includes many dependencies implicitly including in classloader app server itself. examples include things httpclient. illustrate in example, we'll call this: libaryx-v1.jar.
and deploy multiple ears same install, provided multiple teams within our organization, on different release , budgetary cycles.
teama.ear needs libraryx-v1.jar , tested , certified version.
teamb.ear needs libraryx-v2.jar, in particular new features meet teams requirements not included in other version.
how deploy both of these ears wildfly?
if teama had budget test , certified using librayx-v2.jar, obvious solution upgrade module within wildfly.
when add libraryx-v2.jar teamb.ear, following exception:
java.lang.linkageerror: loader constraint violation: when resolving method "org.apache.example.<init>(lorg/whatever/sharedclass;)v" class loader (instance of org/jboss/modules/moduleclassloader) of current class, com/company/teamb/exampleservice, , class loader (instance of org/jboss/modules/moduleclassloader) method's defining class, org/apache/example, have different class objects type org/whatever/sharedclass used in signature
the problem arise when interchange objects between deployments. way prefer package required libraries , not refer wildfly modules since these may change in future versions of server. in case should package libraryx-v1.jar in teama.ear libraryx-v2.jar in teamb.ear. @ point clean , compatible future releases of wildfly, if upgrade (or reason) downgrade module.
if need exchange objects of libraryx between 2 deployments not easy because different classloaders have loaded different classes. if easy libraryx present in 1 version simple deploy library , refer ears. in case think there way build custom library "interchange classes", deploy , refer it. afterwards take information of interchange object , create new instance of libraryx-object it. need fixed contract application communication.
Comments
Post a Comment