JDK-6713777 : developer diagnosability of errors in uncompliant mxbean interfaces
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 1.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-06-12
  • Updated: 2010-07-29
  • Resolved: 2008-09-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10 b31Fixed 7Fixed
Description
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).
Comments
EVALUATION We should also include a note in the exception message when a string in @ConstructorProperties differs only in case from the the name of a property. This can cause much head-scratching because of the tricky JavaBeans rules concerning properties with names like getXYZ(), for example getURLPath(). The name of this property is URLPath and not uRLPath as you might naively expect.
19-06-2008
EVALUATION It should be possible by examining the chain of exceptions in the stack trace to determine exactly what types are involved in the problem. For example, if BdelloidMXBean defines an attribute of type Rotifer and the class Rotifer has a property of type java.io.File, then the messages in the exception change should include BdelloidMXBean, Rotifer, File, and ideally the name of the methods in File that cause the problem (in this case, e.g. File getParentFile()). Currently the exceptions mention BdelloidMXBean and Rotifer but not File, so if Rotifer has many other properties it can be hard to figure out which one is causing the problem.
12-06-2008