EVALUATION
It turns out that the underlying problem is with the targetObject field. This field can be used to direct an individual attribute or operation towards a different resource from the one defined for the Model MBean as a whole. As such, its value is often a non-serializable object, and in any case it does not make sense to serialize it. Therefore it would make sense to exclude it from the serialization of DescriptorSupport so that RequiredModelMBean.getMBeanInfo() returns a serializable object.
|
|
|
SUGGESTED FIX
Suggested fix is to remove the "targetObject" field from the HashMap that is included in the serial form of a DescriptorSupport. This can be done by making some small changes to the existing writeObject method.
|
|
|
EVALUATION
Nothing in the specification should lead anybody to suppose that a DescriptorSupport will be serializable if it contains a non-serializable object, any more than a HashMap is, for example.
Furthermore there is no way in general to tell whether an object is serializable other than by serializing it. instanceof Serializable tells you nothing since (a) the object might have a writeObject that throws an exception (the recommended way for a subclass to be non-serializable if its parent is serializable), and (b) the object being serialized might itself be serializable but contain an object that is not, which indeed is exactly what we are seeing here with DescriptorSupport.
It appears that the code that is failing here is incorrect and I do not see any clean way of allowing it to work anyway.
|
|
|
SUGGESTED FIX
Fix suggested by the submitter:
javax.managment.modelmbean.DescriptorSupport.writeObject() should validate
the referenced object's are serializable before writing out the serialized form
??
i.e. within the for loop prior to the line:
?????? descriptor.put() line have:
if (!(entry.getValue() instanceof java.io.Serializable)) continue;
|
|
|
WORK AROUND
No workaround - other than not to use javax.management.modelmbean.DescriptorSupport with non-serializable objects
|
|
|