Class loading conflict

[objectiser]

Hi

I have a sar that includes xmlbeans 2.3.0 - which works fine in AS 5.1. However when I installed ESB4.6, which has version 2.2.0 of this jar in its esb-deployer, I get schema version problems.

What is the best way to isolate my sar from being affected by jar versions in other non-dependent deployments?

Regards
Gary

[jaikiran]

See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=159343

[alesj]

You need to "mimic" this isolation code

 String domain = getJMXName(deployment, unit) + ",extension=LoaderRepository";
 classLoadingMetaData = new ClassLoadingMetaData();
 classLoadingMetaData.setName(unit.getName());
 classLoadingMetaData.setDomain(domain);
 classLoadingMetaData.setExportAll(ExportAll.NON_EMPTY);
 classLoadingMetaData.setImportAll(true);
 classLoadingMetaData.setVersion(Version.DEFAULT_VERSION);
 classLoadingMetaData.setJ2seClassLoadingCompliance(false);

taken from http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/deployer/src/main/java/org/jboss/webbeans/integration/deployer/metadata/WebBeansClassloadingDeployer.java
in your jboss-classloading.xml.

Where you should put this file into esb.deployer and your deployment,
so that both are isolated and don't see over-lapping classes.

[objectiser]

Hi,

Tried that approach, but now I have a problem in that the ESB is complaining about classes not being found. The jboss-classloading.xml is placed in the esb.deployer, so I assume that isolation is now causing the jbossesb.sar to not resolve classes that it previously referenced from the esb.deployer.

So I assume to overcome this, I would need a jboss-classloading.xml in the jbossesb.sar?

The jbossesb.sar has a deployment.xml but it does not have a dependency on the deployer - if it did, would this overcome the problem? or do all deployment units that depend upon the ESB need to have its own jboss-classloading.xml? i.e. any .esb distribution?

The other problem with this approach is that it requires me to modify the ESB distribution. Is there no mechanism to just enable my sar to indicate that it wants to have only its own libs, and the jboss AS libs on its classpath?

Regards
Gary

[alesj]

What about if you add parentDomain="DefaultDomain" to the esb.deployer's jboss-classloading.xml?

[objectiser]

No, still no luck - just to check, the jboss-classloading.xml in esb.deployer is:

<classloading domain="jboss.esb:service=EsbDeployer,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="EsbDeployer"
import-all="true" export-all="NON_EMPTY" version="0.0.0"
j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >


and it causes exceptions like:

15:34:00,679 ERROR [AbstractKernelController] Error installing to Instantiated: name=jboss.esb:service=PropertyService state=Described mode=Manual requiredState=Configured
java.lang.ClassNotFoundException: org.jboss.soa.esb.common.JBossESBPropertyService from BaseClassLoader@127d5a0{VFSClassLoaderPolicy@3a0533{name=vfsfile:/.......

[alesj]

What about if you just have this jboss-classloading.xml in your deployment:

<classloading domain="some-name" xmlns="urn:jboss:classloading:1.0" name="some-name"
import-all="true" export-all="NON_EMPTY" version="0.0.0"
j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >

and leave esb.deployer as it is.
Or did you already try this?

[objectiser]

I hadn't tried with all those attributes, so I just tried it with the same result :(

Just to make sure, this is what I have used:

<classloading domain="jboss.bpel:service=BPELEngine,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="BPELEngine"
 import-all="true" export-all="NON_EMPTY" version="0.0.0"
 j2seClassLoadingCompliance="false" parentDomain="DefaultDomain" >
</classloading>

[alesj]

"objectiser" wrote:
I hadn't tried with all those attributes, so I just tried it with the same result :(

So, you're still picking up esb.deployer's classes?

I'll try to re-create this tomorrow, ok?

[objectiser]

Yes, still picking up the xbeans-2.2.0.jar from the esb.deployer lib, instead of my local xmlbeans-2.3.0.jar in my sar's lib folder.

Tomorrow is ok.

Thanks.

[alesj]

You put wrong attribute. ;-)

j2seClassLoadingCompliance --> parent-first

I guess we should validate this xmls.

So, this does the trick for me:

<classloading xmlns="urn:jboss:classloading:1.0"
 domain="some-name"
 name="some-name"
 import-all="true"
 export-all="NON_EMPTY"
 version="0.0.0"
 parent-first="false"
 parentDomain="DefaultDomain"
/>

Simply put this into your deployment/app.

[objectiser]

Yes that worked.

Thanks for your help.

Regards
Gary

[alesj]

"objectiser" wrote:

Thanks for the help so far - just another quick question, as well as the isolation of the riftsaw.sar, I also have an esb module that is dependent upon an interface within the sar.

I tried defining a capability in the sar's classloading.xml, and then define a simple jboss-classloading.xml that defines a 'requirement' on that capability. But this did not help - it now generates the following problem:

Deployment "<UNKNOWN vfsfile:/NotBackedUp/gbrown/testing/riftsaw/jboss-5.1.0.GA/server/default/deploy/riftsaw.esb/>" is in error due to the following reason(s): ** UNRESOLVED ModuleRequirement{BPELEngine [0.0.0,?)} **

I have attached the two jboss-classloading.xml file - could you let me know how I can ensure the riftsar.esb can access a particular interface in the sar.

<classloading domain="jboss.bpel:service=BPELEngine,extension=LoaderRepository" xmlns="urn:jboss:classloading:1.0" name="BPELEngine"
 import-all="true" export-all="NON_EMPTY" version="0.0.0"
 parent-first="false" parentDomain="DefaultDomain" >
 <capabilities>
 <module name="BPELEngine" />
 </capabilities>
</classloading>

<classloading xmlns="urn:jboss:classloading:1.0" domain="DefaultDomain" export-all="ALL" name="RiftSaw" >
 <capabilities>
 <module name="RiftSaw" />
 </capabilities>
 <requirements>
 <module name="BPELEngine" />
 </requirements>
</classloading>

BPELEngine is in separate domain - jboss.bpel:service=BPELEngine,extension=LoaderRepository.
Hence RiftSaw - which is in DefaultDomain - cannot see it.

They should be in the same or hierarchy-accessible domains.
e.g. BPELEngine's domain could be some ancestor of RiftSaw's domain

If this was the other way around it would work, as BPELEngine would find RiftSaw in its parent (== DefaultDomain) domain.

[objectiser]

Hi Ales

Using the same domains in the riftsaw.esb and sar worked fine, but introduced another problem when I deployed some ESB examples that depended upon the action I had defined in the riftsaw.esb, and I don't think it would be a good idea for me to set the domain inside the ESB example to be based on riftsaw, as an ESB service in reality maybe using a number of other thirdparty custom ESB actions - and I assume it cannot be part of multiple domains?

So I thought it best to outline the overall scenario, to see whether there is a good overall solution, rather than presenting the side effects of each individual change as I have currently being doing.

1) The riftsaw.sar, which had the original jar conflict, is not dependent upon JbossESB. It does however have some interfaces that need to be used externally.

2) If the JBossESB integration is being used, then currently there is a single BPEL invoke action that needs to access the interface from the riftsaw.sar

3) Other ESB services - that may need to use the BPELInvoke action. Currently ESB services don't need to do anything specific in their configuration to pick up ESB actions defined in other .esb modules - so either this approach needs to continue, or an approach needs to be used that would enable the ESB example to reference multiple ESB actions potentially defined in different isolation domains.

Hope this gives a clearer outline of the dependencies and what we are wanting to achieve.

Regards
Gary

[alesj]

I can currently think of two solutions.

(1) Still put all ESB examples in the same domain as RiftSaw, with parent being DefaultDomain and perhaps parent-first=true

Don't see why this would be a problem?
Or why would you need multiple domains?
Their parent is DefaultDomain, hence they see all what default stuff sees.

(2) Be "OSGi" exact

Split / extract the conflicting jar into separate deployment, and give it proper jboss-classloading.xml
e.g. readable module name + *proper* version

Do the same with its updated version.

Then simply reference the right exact module,
whereas you don't need to define any separate domains.

It's definitely more work, plus you need to wrap existing external jars,
but this is a known OSGi issue - see SS's huge effort of creating proper repository.