Hello all, I'm running jboss eap 4.3

I've encountered a problem with the following architecture:

Imagine 3 jars:

Jar A: Generic Fruit base classes, and a class which serializes and deserializes simple Fruit type objects in/out of a database upon requests from clients.

Jar B: Fruit implementations, depends on A Fruit class interfaces to compile.

Jar C: Uses both A and B. Uses A to serialize and deserialize B fruit implementations. When asking A for the deserialized Fruit, uses instanceof to determine the real type of a Fruit object, returned by A.

The implementation structure is like this:

A classes:

abstract class Fruit { doFruitStuff();}

class FruitDataManager {

Fruit getFruit( id ){

//pull CLOB from DB

Fruit fruit = (Fruit)objectInputStream.readObject();

return fruit;}

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

B class:

Strawberry extends Fruit ...

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

C class:

FruitBusinessManager

{

Fruit fruity = new FruitDataManager() .getFruit(111);

if (fruity instanceof Strawberry)

//cast to Strawberry, call Strawberry methods...

}

The setup works fine if jboss is rebooted, or I hot deploy A, B, and C. If I only hot deploy B and C, C's instanceof fails, and we get ClassCastExceptions on Strawberry not being Strawberry anymore.

From classloader logging I have observed that this implementation ends up as sort of circular runtime dependency of A on B, because B classes are loaded in A's processing.

When, in jar A, the FruitDataManager does: ObjectInputStream.readObject() on a B jar fruit implementation class, it loads B classes at that time.

After hot-deployment of just B and C, A does not re-load the new B types, it appears to hold on to a bad/stale reference to the old B class jar deployment.

Any suggestions or ideas to resolve this would be greatly appreciated.

Thanks,

Amanda