Issue1232

classification
Title: Inherited java bean properties not recognized correctly
Type: behaviour Severity: normal
Components: Core Versions: 2.5b1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: cgroves, garyh
Priority: Keywords: patch

Created on 2009-01-12.15:35:12 by garyh, last changed 2009-01-16.09:21:41 by cgroves.

Files
File name Uploaded Description Edit Remove
jython_bean_props.patch garyh, 2009-01-12.15:35:10 patch for PyJavaType.init()
beanprops_test.tar.gz garyh, 2009-01-12.15:53:59 Sample java bean property test case
Messages
msg4033 (view) Author: Gary Helmling (garyh) Date: 2009-01-12.15:35:10
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.
msg4034 (view) Author: Gary Helmling (garyh) Date: 2009-01-12.15:53:59
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.
msg4049 (view) Author: Charlie Groves (cgroves) Date: 2009-01-16.09:21:40
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.
History
Date User Action Args
2009-01-16 09:21:41cgrovessetstatus: open -> closed
resolution: fixed
messages: + msg4049
nosy: + cgroves
2009-01-12 15:53:59garyhsetfiles: + beanprops_test.tar.gz
messages: + msg4034
2009-01-12 15:35:12garyhcreate