ESB 4.9 and Classloading...

[david.escandell]

I am having issues getting classloading to be application scoped.  I am using JBoss ESB 4.9 server and I want to use apache commons lang 2.4.  The jboss esb sar uses 2.3.  I should be able to include the correct version of the jar in my .esb file and leave the sar alone. 

I have gone through a couple of different ways - first altering the deployment.xml file to use

	<loader-repository>
		com.famc.esb:loader=simple-scoped
		<loader-repository-config>java2ParentDelegaton=false</loader-repository-config>
	</loader-repository>

then, instead, adding a jboss-classloading.xml file with the following contents

<classloading xmlns="urn:jboss:classloading:1.0"

domain="ImagingESBServices.esb"

import-all="true"

export-all="NON_EMPTY"

version="0.0.0"

parent-first="false"

parentDomain="ImagingESBServices.esb"

/>

Neither worked.  Do I have something wrong with the syntax?  Which is the appropriate way to resolve this?

Thanks for your help,

David Escandell

[tcunning]

David,

If you're only using the JBoss ESB server, the easiest fix might be to download the ESB source, change ESB to use commons-lang 2.4, and then build the ESB server (cd product; ant clean artifacts).

[david.escandell]

It certainly works to replace commons-lang 2.3 in the server with commons-lang 2.4.  Unfortunately, this is just a band aid fix.  I'd like to find a solution that will work when we run into this problem with other jars.

Right now I am checking ESB Server 4.10 to see if there is any difference.  Should I expect anything different there?

[tcunning]

This thread seems to be a similar issue :

http://community.jboss.org/message/499413

Maybe you could check out what they do in the most recent version of RiftSaw?       It seems like they had the same issue.

The only reason I mention that the easy solution is to swap in commons-lang 2.4 is that I recently upgraded commons-lang in ESB from 2.3 to 2.4, there were no issues, and that change will be in the next release of JBoss ESB.     You're absolutely right that you may run into this problem with other JARs though, but if you have a limited number of JARs in your archive, you might be able to get away with it.

[david.escandell]

So, It looks like I did have the right syntax in the deploment.xml file.  After poring through the console output, I found that only a root deployment can scope the classloader as I am trying to do.  Since the .esb deployment is loaded by the jbossesb.sar, the sar becomes the root deployment. 

What this means, then is that all esb's that I deploy will share the same classloader as the sar.  Is this inescapable?  This seems deficient.  Wars each have their own classloader.  I suppose they are each treated as root deployments.  Is that correct?  However, since esb files are not standard j2ee, they will not be considered root deployments and as such, cannot scope the classloaders individually.

How are other people dealing with this issue?  It seems enough to drive one to Mule or something.

[tcunning]

David :

Try this

http://community.jboss.org/thread/105825?tstart=0

If that doesn't work for you, is there any way you could whip us up a small .esb archive maybe that has an action that exercises one of the methods from commons-lang 2.4 that you need that aren't available in 2.3?       I can try to take a look at it and/or file a JIRA.

[david.escandell]

I'll work on this today and let you know.  Thanks so much for your help.

[david.escandell]

I've gotten it to work.  Thanks Tom, for all your help.

In the end, I used a jboss 5.1.0 AS and installed jboss esb 4.9 into it.  This allowed me to uthe jboss-classloading.xml file according to many of the posts I have seen here.  Once this was in place, I started finding lots of errors.  These errors all related to jar files in my .esb that conflicted with those that came with the server.  I either removed them or changed the scope to"provided" in my pom.  Once I got rid of all the offendjars, things began to work correctly.

So now I have a scoped classloader.

That was painful to figure out ;-)