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).