When converting existing mbeans into mxbeans, and when having developers write "fat" struct-like mxbean attributes and/or method parameters we have come across issues in being able to diagnose where the non-compliance of a given mxbean interface actually comes from, the exception messages that show up at runtime indicate the mxbean interface the field of the interface, and the type of the offence, without narrowing down the containment path to the specific field that offends.

It would be considerably appreciated if the mxbean compliance parsing could, in its recursive parsing structure, catch the thrown OpenDataExceptions and / or InvalidObjectExceptions , wrapping the exceptions with a caused-by path that indicates the names of the fields as they are unwound from the stack.

Another suggestion is that the JMX netbeans plug-in have an mxbean compliance function that will parse an mxbean interface class and indicate whether or not it, and its contents, are mxbean compliant (both for the server side and the proxy side).