commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: commons-modeler and case sensitivity of property names
Date Wed, 29 Jun 2005 00:55:03 GMT
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
> > javax.management.AttributeNotFoundException
> > ("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()
 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".

NB: I'm not a commons-modeller maintainer.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message