Wrong ClassLoader is used for message deserialization when devtools are active

[deje07]

Experienced with version 3.0.10 (probably all versions starting from 3.0).

When Spring Boot devtools are active, messages should be deserialized using the RestartClassLoader, but they are using AppClassLoader by default.

This will cause that message handlers for specific message types will not be found, since handlers are loaded via RestartClassLoader, and their parameter's class loader will be the same, so they will never be compatible with the same class loaded into AppClassLoader.

Both the SimpleMessageConverter (which is the default in Spring Boot) and the SerializerMessageConverter are affected.

Expected behavior

Message deserialization should work also with devtools enabled, by default. The ClassLoader to be used should be obtained via org.springframework.util.ClassUtils.getDefaultClassLoader() or equivalent.

Sample

I can provide a sample if required, but it is pretty straightforward what happens:

• in SimpleMessageConverter the method createObjectInputStream will create the ObjectInputStream with no regard to other class loaders. Previously (before 3.0) it used beanClassLoader obtained via ClassUtils.getDefaultClassLoader().
• in SerializerMessageConverter, when the DefaultDeserializer is used, the converter obtains the class loader from the DefaultDeserializer.classLoader property, which is null by default, which means current class loader will be used and not the proper one.

The commit that breaks the behavior seems to be 1a1b1f6, where RMI support gets removed.