Would the person who raised this issue like to propose what kind of clarification they would want to see?
Standard Java deserialization uses the java.io.ObjectInputStream.readObject() method.
The default behaviour of ObjectInputStream.readObject() is described in the javadoc for ObjectInputStream.resolveClass() here. This states that the class loader loader is determined as follows:
if there is a method on the current thread's stack whose declaring class was defined by a user-defined class loader (and was not a generated [class] to implement reflective invocations), then loader is [the] class loader corresponding to the closest such method to the currently executing frame; otherwise, loader is null
However some JMS providers appear to override this behaviour, perhaps to use the context class loader if using the class loader provided by default cannot load the class.
Trying the context class loader is more flexible, though it still relies on the context class loader being configured appropriately, which is not under direct application control in a MDB or message listener where the thread is created by the JMS provider or application server. In addition, the first of the four examples given above suggest that even when messages are consumed synchronously using a application thread, the deserialization may still be performed in a separate JMS provider thread. So requiring the deserialization to try the context class loader may not always solve the problem.
The submitted proposes a new method getObject(ClassLoader classLoader) on java.jms.ObjectMessage. This would be simple to implement and not impact on existing JMS providers or applications, so seems a good candidate for consideration.
I'll raise this topic with the expert group. Tagging appropriately.