Hi Audrius
Audrius Meskauskas wrote:
Hi, Nicolas,
>Are you sure this is the correct behaviour? The class of the stream
(which contains the members that couldn't be unserialized and were the
cause of the bug) is loaded in RMI with the resolveClass method of the
gnu.java.rmi.server.RMIObjectInputStream. This method calls the
java.rmi.server.RMIClassLoader.loadClass() which uses a specific class
loader. Shouldn't the fields be loaded by this class loader instead of
the application's class loader (which is actually the thread's context
class loader)?
The thread context class loader need not be always the applications
class loader, this is just the default value. To load remote classes
in the ObjectInputStream methods, the mentioned RMI-specific class
loader should probably be set as the thread context class loader.
That was my conclusion :). In fact I was asking for your opinion. (and
any RMI expert on the list)
This must be done before that thread calls methods of the
ObjectInputStream. This another future fix would be additional to the
recently applied patch, actualy solving another bug (remote class
loading problems).
Yes, it would be additional.
I'm no expert on RMI and was asking if you thought my conlusion was
right. Maybe it's no sense to change the thread's class loader to
correct this issue, or maybe this is the correct behaviour.
Regards
Audrius
Cheers,
Nicolas
