0 Replies Latest reply on Jan 15, 2013 5:31 PM by amanda427

    Classloader problem after hot deployment of jars

    amanda427 Newbie

      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