Its an undefined issue due to the fact that jmx is fundamentally a local only api. There are ZERO restrictions or requirements on any type showing up in the management interface. The jmx remoting spec says nothing about how objects that cannot be marshalled over a given transport should be dealt with as far as I can see. Whether incompatible objects are ignored, translated to null or marshalled with a custom object replacement layer is outside of the scope of the jmx specs. Its an implementation detail of the jmx implementation apparently. Look to see what the behavior of the jdk5 jmx remoting layer is with regard to non-serializable attributes.
There is a javax.management.remote.generic.ObjectWrapping interface that can be used to customize how generic connectors behave, but its not clear that this is really for customization of the transport serialization. Its more about how to control the scope of object marshalling with the correct class loader.
Thank very much for the answer.
I´m implementing a Interceptor class to org.jboss.jmx.connector.invoker.InvokerAdaptorService so that I can apply your considerations about Non-serializable fields.
This interceptor will replace Non-serializable object for a serializable version, return a null value or not show Non-serializable fields in a remote client at all.
IMO if you are trying to download a Serializable attribute over the wire getting a NonSerializableException should be the appropriate exception for that.
Why would you try to return a NonSerializable object over the wire?