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:



      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.