PropertyPathFactoryBean requires a bean setter in version 3.1.0.RELEASE. It didn't in 3.0.6.RELEASE [SPR-8949]

[spring-projects-issues]

David Boden opened SPR-8949 and commented

The org.springframework.beans.factory.config.PropertyPathFactoryBean class seems to have got more strict in 3.1.0.RELEASE. I have an object with an "options" field and a "getOptions()" method but no corresponsing "setOptions()" method. Fair enough, it isn't a bean :)

However, I just wanted to log the fact that the behaviour has recently changed and maybe to help someone else out who's seeing the same error.

A reasonable workaround is to switch to the MethodInvokingFactoryBean and specify "getOptions" as the method name. Unfortunatly, this isn't quite as elegant as I would hope because I have 2 levels of beans to navigate. The original spring config was:

<bean id="applicationIdFromCommandLine"
    class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
    <property name="targetObject" ref="core.commandLineProcessor" />
    <property name="propertyPath" value="options.applicationId" />
</bean>

Note the "options.applicationId" meaning "the applicationId property inside the options bean". I've got it working by using:

<bean id="applicationIdFromCommandLine"
    class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
    <property name="targetObject">
        <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
            <property name="targetObject" ref="core.commandLineProcessor" />
            <property name="targetMethod" value="getOptions" />
        </bean>
    </property>
    <property name="targetMethod" value="getApplicationId" />
</bean>

Could someone in the know please make a judgement about whether it's appropriate to relax the demand for the setter? If we want to keep it strict then fine, I'll move everything over to MethodInvokingFactoryBean.

Stack trace:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'core.CommandLineOptions': FactoryBean threw exception on object creation; nested exception is org.springframework.beans.NotReadablePropertyException: Invalid property 'options' of bean class [com.fxcash.fxcore.application.impl.option.CoreCommandLineArgumentProcessorImpl]: Bean property 'options' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:149)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:109)
at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1441)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:305)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
... 48 more
Caused by: org.springframework.beans.NotReadablePropertyException: Invalid property 'options' of bean class [com.fxcash.fxcore.application.impl.option.CoreCommandLineArgumentProcessorImpl]: Bean property 'options' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?
at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:729)
at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:721)
at org.springframework.beans.factory.config.PropertyPathFactoryBean.getObject(PropertyPathFactoryBean.java:208)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:142)
... 53 more

---

Issue Links:

• Overhaul non-void JavaBean write method support [SPR-10029] #14663 Overhaul non-void JavaBean write method support

1 votes, 2 watchers

[spring-projects-issues]

Chris Beams commented

Hi David,

I'm unable to reproduce this issue as it's been reported.

Take a look at this test case where I attempted to do so:

https://gist.github.com/1726795

What are you doing differently?

Is there any chance that your getOptions method in question is non-public? I do get the NotReadablePropertyException in that case. However, it does not appear that this is a change across the 3.0.6/3.1.0 boundary.

If you can demonstrate/reproduce this, please re-open.

Feel free to submit that reproduction per the instructions at https://github.com/SpringSource/spring-framework-issues#readme

Also note that we plan to release 3.1.1 within the next several days, so if you can reproduce and you're quick about it, we may still be able to get the fix in!

Thanks,

Chris

[spring-projects-issues]

Donnchadh O Donnabhain commented

I'm seeing something similar in a JSP with Spring 3.1.0:

@400000004f3173ee0be382ac Caused by: org.springframework.beans.NotReadablePropertyException: Invalid property 'publication.masterPublication' of bean class [... .PublicationEdit]: Bean property 'publication.masterPublication' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?
@400000004f3173ee0be3924c 	at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:729)
@400000004f3173ee0be39634 	at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:721)
@400000004f3173ee0be39e04 	at org.springframework.validation.AbstractPropertyBindingResult.getActualFieldValue(AbstractPropertyBindingResult.java:99)
@400000004f3173ee0be3a1ec 	at org.springframework.validation.AbstractBindingResult.getFieldValue(AbstractBindingResult.java:226)
@400000004f3173ee0be3c12c 	at org.springframework.web.servlet.support.BindStatus.<init>(BindStatus.java:120)
@400000004f3173ee0be3c514 	at org.springframework.web.servlet.tags.BindTag.doStartTagInternal(BindTag.java:119)
@400000004f3173ee0be3c514 	at org.springframework.web.servlet.tags.RequestContextAwareTag.doStartTag(RequestContextAwareTag.java:79)
@400000004f3173ee0be3c8fc 	at org.apache.jsp.jsp. ... Settings_jsp._jspService(... Settings_jsp.java:879)

The getter do exist, but no setters. The return type of getPublication() is covariant.
This didn't happen with Spring 3.0.6 .

[spring-projects-issues]

Chris Beams commented

Donnchadh,

Thanks - I'm going to be working shortly on some of our JavaBeans introspection code that may well be related to this problem. The covariance issue means that there may be some issues that we're not addressing closely enough around bridge methods.

Would you be willing to put together a reproduction project for this? It would help greatly, as I'm afraid I won't be able to look into this unless I can reproduce it.

As you're probably already aware, you can follow the instructions at https://github.com/SpringSource/spring-framework-issues#readme for a very simple approach to creating and submitting a standalone- or web-based reproduction project.

Please reopen this issue and mention the pull request for the repro project if you do create one.

We're planning to ship 3.1.1 very shortly - I'd love to get the fix for this in if possible!

[spring-projects-issues]

Donnchadh O Donnabhain commented

Yes, it would be great to get a fix for this into 3.1.1 . Unfortunately it's not consistently reproducible. I think this stems from the fact that the call to clz.getMethods() in java.beans.Introspector.getPublicDeclaredMethods(Class clz) returns the array of methods in no particular order.

So far I have been unable to reproduce the above error today with the exact same build, the only difference being that the webapp has since been restarted. I will continue to investigate and try to create a minimal testcase but it seems to be a difficult one to reproduce.

[spring-projects-issues]

Donnchadh O Donnabhain commented

On further investigation, this seems simpler than I first thought. It doesn't appear to be related to covariant return types. The PropertyDescriptor isn't being included in ExtendedBeanInfo .

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

import org.junit.Test;
import org.springframework.beans.BeanWrapperImpl;

public class SPR8949Test {
    public static class A {
        public boolean isMasterPublication() {
            return false;
        }
    }
    
    public static class B extends A {
        @Override
        public boolean isMasterPublication() {
            return true;
        }
    }
    
    @Test
    public void testSPR8949() {
        // This assertion succeeds
        assertFalse(((Boolean)(new BeanWrapperImpl(new A()).getPropertyValue("masterPublication"))).booleanValue());
        // This assertion fails
        assertTrue(((Boolean)(new BeanWrapperImpl(new B()).getPropertyValue("masterPublication"))).booleanValue());
    }
}

I will now create a standalone project as you suggested above.

[spring-projects-issues]

Chris Beams commented

don't sweat the repro project - if this test demonstrates it, that's all I'll need.

[spring-projects-issues]

Chris Beams commented

Verified that the unit test does in fact fail for me locally. I'll take it from here, thanks.

[spring-projects-issues]

Chris Beams commented

Fixed. Thanks David and Donnchadh.

We'll be releasing 3.1.1 very soon, so would appreciate any feedback on this if you can test it out. A snapshot will be available shortly at https://build.springsource.org/browse/SPR-B31X.

commit f1ecd1ca2a73158bd88dc5059ecbf0c24154f61d (HEAD, springsource/3.1.x, 3.1.x)
Author: Chris Beams <cbeams@vmware.com>
Date:   Thu Feb 9 11:55:33 2012 +0100

    Detect overridden boolean getters in ExtendedBeanInfo
    
    Prior to this commit, and due to idiosyncracies of
    java.beans.Introspector, overridden boolean getter methods were not
    detected by Spring's ExtendedBeanInfo, which relied on too-strict
    Method equality checks when selecting read and write methods.
    
    Now ExtendedBeanInfo uses Spring's ClassUtils#getMostSpecificMethod
    against the methods returned from java.beans.Introspector in order
    to ensure that subsequent equality checks are reasonable to make.
    
    Issue: SPR-8949

[spring-projects-issues]

David Boden commented

Sorry to say that this issue is not fixed under Spring 3.1.1.RELEASE and Java 7. It's working fine under Java 6 (just to be clear, I'm not sure if it was ever broken under Java 6; I don't remember which JRE I initially tested against; apologies). It's definitely failing under Java 7.

[spring-projects-issues]

David Boden commented

(specifically, we've tested under JDK 1.7 update 4, which is currently the latest Java runtime)

[spring-projects-issues]

Chris Beams commented

Hi David,

Please open a separate issue specific to JDK 7, and mention this issue in your description. We'll go from there. It's best not to reopen this, as the commit did fix the original issue (against JDK 6 at least), and the fixVersion is already released. Thanks!

[spring-projects-issues]

David Boden commented

Makes sense Chris; thanks, I've raised #14050.

[spring-projects-issues]

Chris Beams commented

A general note to watchers of ExtendedBeanInfo-related issues: #14663 is a major refactoring of ExtendedBeanInfo and overall support for non-void returning setter methods.

If you have submitted a reproduction project with this issue, we have run it through its paces against these new changes, but we would like to ask you to do the same against your actual applications.

Please consider updating your dev or test builds to work against 3.1.4.BUILD-SNAPSHOT and/or 3.2.0.BUILD-SNAPSHOT to verify, and we would appreciate any feedback, even if it's to let us know that all is well. So that we can consolidate feedback, please add your comments to #14663, and mention the original issue(s) that you were watching.

Thanks!

Note also that testing against 3.1.4 is preferable to 3.2.0 because ExtendedBeanInfo is always in the code path in the latter, while in 3.2.0 we've optimized things such that ExtendedBeanInfo is only in play for bean classes that have one or more non-void returning setter methods.