United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6713777 developer diagnosability of errors in uncompliant mxbean interfaces
JDK-6713777 : developer diagnosability of errors in uncompliant mxbean interfaces

Details
Type:
Enhancement
Submit Date:
2008-06-12
Status:
Closed
Updated Date:
2010-07-29
Project Name:
JDK
Resolved Date:
2008-09-23
Component:
core-svc
OS:
generic
Sub-Component:
javax.management
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.0
Fixed Versions:
6u10 (b31)

Related Reports
Backport:

Sub Tasks

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

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.
                                     
2008-06-12
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.
                                     
2008-06-19



Hardware and Software, Engineered to Work Together