Issue1232

Jython's java bean property handling seems to be overly restrictive when
the property accessors are split over a class hierarchy.

Consider the java class structure:

public class Parent {
    protected int id;

    public Parent() {}

    public int getId() { return this.id; }
}

public class Child extends Parent {
    public Child() {}

    public void setId(int newid) { this.id = newid; }
}


In this case, obtaining an instance of Child and reading the "id"
property ("print child.id"), will return the error:
    AttributeError: write-only attr: id

With Beta 0, this only occurred with
python.security.respectJavaAccessibility=false.  With Beta 1, this now
occurs regards of the java accessiblity setting.

I've traced this down to the org.python.core.PyJavaType.init() method,
in the first for loop through the class methods.  I see two issues:

1) when respectJavaAccessiblity=false, we call
Class.getDeclaredMethods(), so never see the parent getter in the case
above when building the properties.
2) when respectJavaAccessiblity=true, we immediate continue the loop if
"!declaredOnMember(baseClass, meth)", so again never see the inherited
getter.

The attached patch addresses this by:
* when respectJavaAccessibility=false, including the hierarchy
superclass getDeclaredMethods() in the processing
* limiting the "declaredOnMember(baseClass, meth)" conditional handling
to the PyReflectedFunction setup, so event and bean property setup still
examines inherited methods

Not sure if this is the right approach, or the performance impact of
recursing up the hierarchy for respectJavaAccessibility=false.  If there
are any thoughts on potential problems, or ways of improving the patch,
please let me know.

Here is a simple test script based on the example class structure.

Extract the archive to a dir on your classpath, then run the
beanprops/proptest.py script.

Thanks for the patch and test; it made fixing this quite easy.  I've
committed a fix for this to trunk in r5936, though I used a different
approach than the one in the patch.

Using the full set of methods from the super class as you did would
change the available bean property if a subclass defined a setter with a
different type than the superclass.  I believe the subclass' version
should be used regardless, so the committed version checks for
PyBeanProperties with the same name in superclasses when adding a
PyBeanProperty.  If it finds one, and the subclass is missing a getter
or setter for that name, it's filled in.  The methods array isn't
changed at all.

In any case, your test passes now and has been added to our regression
test, so this shouldn't break again.