1 Reply Latest reply on Dec 12, 2003 11:24 AM by Barry M. Caceres

    Deserialization Broken for java.lang.Class for RMI calls?

    Barry M. Caceres Newbie

      It appears that the ClassLoader that handles deserialization
      of method parameters in RMI calls is failing to properly
      deserialize instances of java.lang.Class. This occurs when I call
      an EJB methods remotely and not during any other serialization or
      deserialization (i.e.: I could not replicate this when serializing
      the object to a ByteArrayOutputStream and then deserializing from
      a ByteArrayInputStream -- I also tried with a FileOutputStream and
      FileInputStream and could not reproduce the behavior).

      I'm not sure if this is the right, forum, but I figure developers will
      forward this on to the right people because they actually care about
      making the software better.

      The bug manifests itself when trying to deserialize java.lang.Integer.TYPE
      which represents the "int" primitive type as a java.lang.Class object.
      (I imagine the bug would also appear if deserializing Float.TYPE,
      Double.TYPE, or any other primitive TYPE constant).

      It appears that the deserialization is attempting to perform a
      Class.forName(String) on "int", which then fails with a message about
      there being no class loaders for class "int".

      The primitive types should be a special case in the
      deserialization method and looked up in a table.

      Like I said, this only occurs when I try to send Integer.TYPE over
      the wire to an EJB remote method call (not during deserialization
      from a ObjectInputStream based on a ByteArrayInputStream or
      FileInputStream)

      Any help with this matter would be great (especially info on how to
      fix it in my local 3.2.1 & 3.2.2 source code).