[ mx4j-Bugs-935679 ] getAttribute() in RequiredModelMBean doesn't follow specs

Bugs item #935679, was opened at 2004-04-15 10:55
Message generated for change (Comment added) made by btscully
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=935679&group_id=47745

Category: JMX implementation
Group: Release 2.0.1
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Brian Scully (btscully)
Summary: getAttribute() in RequiredModelMBean doesn't follow specs

Initial Comment:
When calling getAttribute on a RequiredModelMBean with 
a descriptor containing a "getMethod" field, the method 
is invoked directly on the target object through 
Reflection, no matter if the method is published or not 
for Monitoring.

However, the JMX 1.2 specs say that the value for the 
field "getMethod" should be :
"Operation name from the operation descriptors to be 
used to retrieve
the value of the attribute from the managed resource."
which means the value should correspond to the name 
of a ModelMBeanOperationInfo object.

Therefore, only operations defined by 
ModelMBeanOperationInfo objects can be used 
for "getMethod" in ModelMBeanAttributeInfo descriptors.

(submitted by [email protected])

----------------------------------------------------------------------

>Comment By: Brian Scully (btscully)
Date: 2004-06-13 18:48

Message:
Logged In: YES 
user_id=234750

This one was pretty buried in the spec - but it seems that
the intention was to require operation descriptors for
getters and setters.  Beyond the attached quote from p.98,
there is the fact that ModelMBeanOperationInfo roles include
operation, getter, and setter.  These together are still a
fairly weak statement - however, are probably sufficient to
solidify the requirement.  It would be my preference that
the spec-writers would put "for modelmbeans exposing
attributes requires exposing getters/setters as operations"
in black & white.

The fix is straightforward, but my concern is how many
users' code this fix will break.  Maybe we could use a
system property or something to force the "broken" behavior.
 I'd like to hear Simon's opinion before going forward on
this one...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=935679&group_id=47745


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504