#1 Use Beans properties for read/write

[Lachlan O'Dea]

It seems likely that most field elements in the
configuration file will be of the form:

<field>
<name>FOO</name>
<class>java.lang.String</class>
<read-method>getFOO</read-method>
<write-method>setFOO</write-method>
</field>

In other words, getFOO and setFOO are usually the read
and write methods for field FOO. I thought it would be
neat if we could take advantage of Java Beans
properties so that the <read-method> and <write-method>
elements could be left out of the configuration file in
this common case.

I have attached a patch that does this. If either
read-method or write-method are not specified in the
configuration, it will use standard Java Beans
introspection to look up a bean property with the same
name as the field. If the property is found, the
appropriate bean setter or getter method is used.

Looking up bean properties by name is a relatively
expensive operation (you have to iterate through all
the properties of the bean), so I've moved the
introspection work previously done in Field.read and
Field.write to Field.loadConfiguration. This has the
added benefit of slightly speeding up calls to read and
write, since the introspection work is only done once.

There are two effects of this. One is that we need to
know the class of the target objects during
Field.loadConfiguration, so this is passed down from
BinderManger. The second is that the target object
passed to read or write must have the class specified
in the configuration. If I understand things correctly,
this should always be the case.

I've done some quick tests and this appears to work.

Note that if read-method and write-method are specified
in the config, then Bean properties are not used and
everything should behave as before (except a tiny bit
faster, as mentioned above).

[Lachlan O'Dea]

Diffs against current CVS.