commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Re: commons-modeler and case sensitivity of property names
Date Wed, 29 Jun 2005 01:53:52 GMT

Simon Kitching wrote:
> On Wed, 2005-06-29 at 12:32 +1200, Simon Kitching wrote:
>>On Tue, 2005-06-28 at 17:21 -0700, Jan Luehe wrote:
>>>Is there a way to have commons-modeler honor the case sensitivity of
>>>Model MBean attribute (property) names?
>>>According to the JMX spec:
>>>  All attribute and operation names derived from these design patterns
>>>  are case-sensitive. For example, this means that the methods "getstate"
>>>  and "setState" define two attributes, one called "state" that is
>>>  read-only, and one called "State" that is write-only.
>>>  While case sensitivity applies directly to component names of
>>>  standard MBeans, it is also applicable to all component names of
>>>  all types of MBeans, standard or dynamic.
>>>In my class that is instrumented as a Model MBean, I have getAbc() and
>>>setAbc() methods, but when I declare "Abc" (instead of "abc") as the
>>>attribute name in the associated mbeans-descriptor.xml, I get a
>>>("Cannot find attribute abc").
>>Can you provide details of where your spec quote can be found? This
>>seems to be in direct contradiction to the JavaBeans specification, and
>>I would be rather surprised to see the two specs in such contradiction.
>>Commons-modeller behaviour would seem to be complying fine with the
>>JavaBeans spec.
> Hmm..actually, my comments apply only when the java.beans.Introspector
> is using reflection + standard naming patterns to deduce what the
> properties of a bean are. When a BeanInfo class or similar mechanism is
> being used to explicitly define the properties I guess that you can have
> properties differing only by case of the initial letter, as the beaninfo
> specifies the getter and setter methods explicitly.
> The JMX spec quote above does seem to be talking about the introspection
> approach though, ie deducing the property names from the available
> getter/setter names. And this definitely does *not* support properties
> differing only by case of initial letter, as can be shown in a test:
> import java.beans.*;
> public class Foo  {
>  public static class MyBean {
>    public void setBar(boolean b) {}
>    public boolean getBar() {return false;}
>    public boolean getbar() {return false;}
>  }
>  public static void main(String[] args)  throws Exception {
>    BeanInfo bi = Introspector.getBeanInfo(MyBean.class);
>    PropertyDescriptor[] props = bi.getPropertyDescriptors();
>    for(PropertyDescriptor pd : props) {
>      System.out.println("name: " + pd.getName());
>      System.out.println("read: " + pd.getReadMethod());
>      System.out.println("write: " + pd.getWriteMethod());
>    }
>  }
> }
> Output:
>  name: bar
>  read: public boolean Foo$MyBean.getbar()

Notice this depends on the order in which the 2 getters are defined.

>  write: public void Foo$MyBean.setBar(boolean)
>  name: class
>  read: public final native java.lang.Class java.lang.Object.getClass()
>  write: null
> ie the standard javabeans introspector reports one property "bar" whose
> getter is "getbar" and whose setter is "setBar".

I found this in the mbeans-descriptor.dtd:

  <!-- The "attribute" element describes a JavaBeans property of an
       MBean. The following attributes are supported:


       getMethod        Name of the property getter method, if it does
                        not follow standard JavaBeans naming patterns.


       setMethod        Name of the property setter method, if it does
                        not follow standard JavaBeans naming patterns.

which confirms our previous assumption about compliance with JavaBeans.

Still, it should be possible to declare (in mbeans-descriptor.xml)
attributes that only differ by case of initial letter (as supported by
the JMX spec), by specifying appropriate getters and setters, but for
some reason, it's not working for me.
I'll take a deeper look at the modeler sources.

Thanks for your help!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message