JBOSS 6 Class Loading

[thammoud]

Hello,

Our ear file contains all of our dependent jar files under lib/ of the ear. Come of the jars conflict with those from JBOSS and we need complete isolation. The issue we faced with ActiveMQ rar getting a ClassNotFoundException during our domain object serialization. Is there a way for us to export our classes (domain only)? How do you suggest we work around this. Most of the documentation seems to be for the older JBOSS version. Thanks for all your help.

Tarek Hammoud

[alesj]

Is there a way for us to export our classes (domain only)?

What exactly do you want to expose? Or why?

I don't have enough info to really see what you're after or trying to do.

[thammoud]

Ales,

Perhaps I tried to suggest soution without fully understanding the fundemantal problem. ActiveMQ is being used as our messaging system withing JBOSS 6.0. For whatever reason, a ClassNotFoundException is being thrown by their code when trying to deserialize any of our domain classes. This issue does NOT exist in JBOSS 4.x. I assumed it is a class loader isolation issue (They do not see our classes) and thus the original question.

[alesj]

Well, "CNFE is being thrown" doesn't tell me anything. :-)

And JBoss4.x is completely different CL layer; although we do pretty much mock what was done there / then.

Try to provide more info and we'll see what we can do.

[thammoud]

Our ear file is made up of EJB's, MBeans and support jar files (apache commons, etc) in the /lib of the ear file. We use ActiveMQ for our messaging layer and that is installed as a rar under the server/deploy directory. In our application, we are sending/receiving JMS messages between the various subsystems of the application. The payload of these messages are object messages that we create. Think domain specific subscription and result objects. Whenever ActiveMQ tries to deserialize one of our classes, the messaging systems is throwing ClassNotFoundException. This means that for whatever reason, the classloader that loaded the activemq rar file, is not sharing our domain classes that are found in the ear file.

We need to understand as to why that is the case. I appreciate your prompt replies. Keep up the great work. Thank you.

[alesj]

It looks like a classic case of isolation.

It all works while ActiveMQ simply works on top of JMS spec API classes,

but once it needs exact impl classes it breaks, as it doesn't see your classes.

Perhaps put .rar in the same CL domain as your .ear.

Should be easy with jboss-classloading.xml -- same domain name for both (with DefaultDomain as parent).

But this is just me guessing. :-)

[diptiv]

Tarek,

Did you resolve this issue. I'm having a hard time trying to isolate my war from the jars in jboss and I can't see to get it to work.

Any help / pointers is appreciated.

Thanks,

Dipti

[thammoud]

Dipti,

No we have not found a solution. I do have an update to what we are seeing and it is indeed very strange. We have "proper" isolation in our ear file. The application communicates with the server using ActiveMQ using object messages and works initially. After a while, the server starts throwing CNFE for our classes. No hot deployment. Nothing. Makes absolutely no sense as thousands of messages have been exchanged initially without any issues. It is difficult to duplicate but can be replicated. I started looking at the class loader code but switched tasks as the priority of the move to JBOSS 6 was lowered.

Sorry for not being much help.

Tarek

[jaikiran]

Tarek Hammoud wrote:

The application communicates with the server using ActiveMQ using object messages and works initially. After a while, the server starts throwing CNFE for our classes. No hot deployment. Nothing. Makes absolutely no sense as thousands of messages have been exchanged initially without any issues.

If that's the case then make sure that there aren't any issues like OutOfMemoryError or such before you starting seeing these CNFE problems.

[thammoud]

Jaikiran,

Lots of memory is available (Multiple gigs). My initial thoughts was to perhaps see if any class unloading is taking place and somehow that is affecting the class loading. I will get back to debugging the problem to see if I can come up with anything.

Tarek

[diptiv]

Hi Tarek,

Can you please give me an example of how you achieved "proper" isolation?

Here's what I've:

jboss-classloading.xml:

-----

<?xml version="1.0" encoding="UTF-8"?>

<classloading

xmlns="urn:jboss:classloading:1.0"

domain="myapp-war"

parent-first="false"

parent-domain="DefaultDomain"

>

</classloading>

jboss-app.xml

------------------------

<jboss-app>

<loader-repository>
  sabrix:loader=myapp-war
  <loader-repository-config>
   java2ParentDelegation=false
  </loader-repository-config>
</loader-repository>
</jboss-app>

------------

jboss-web.xml

<class-loading java2ClassLoadingCompliance="false">

  <loader-repository>
   sabrix:archive=myapp-war
   <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
  </loader-repository>

</class-loading>

Is there something that I'm missing? Or have I done it incorrect?

I've spent past 4 days and still not solved this issue.

Any help is appreciated.

Thanks,

Dipti

[thammoud]

As Ales suggested before, this is a case of isolation. Debugging this over the weekend, I was able to determine that when activemq (by design) is dispatching the messages it is using thread pools. In some cases, the threads that are created inherit the activemq rar class loader context (legit) thus creating this issue. When it is using our ear context, all works fine. Given that I have little or no control as to how the activemq threads are created, this problem can only be solved by packaging the activemq.rar and our ear into the same class loader.

My question is what is the best way to do this. The active mq rar is exploded under the deploy directory and our ear is in that same directory. What is the recommended way of telling jboss6 that a particular exploded rar is to be loaded into class loader foobar? Thanks