Consider bridge methods in SpEL properties [SPR-10162]

[spring-projects-issues]

Marian Gallo opened SPR-10162 and commented

I have found a problem with evaluating of object property values used within SpEL expressions in version 3.2. Expressions were working in older versions (have tried 3.0.6, 3.1.3).

I made an analysis and have found a reason. There was done a change in a class org.springframework.expression.spel.support.ReflectivePropertyAccessor in version 3.2. There was added a subcondition !method.isBridge() in method findGetterForProperty(String propertyName, Class<?> clazz, boolean mustBeStatic) which hides desired class getter for a property which shall be used in an expression during evaluation.

I checked that the problematic getter is a bridge method. A class which I would like to access via a property has a deep inheritance tree - but there is no class design irregularity.

Is there a reason why this behaviour was changed?

It is a blocking issue for us to migrate to Spring 3.2.

---

Affects: 3.2 GA

Issue Links:

• ReflectivePropertyAccessor should not consider bridge methods [SPR-9994] #14628 ReflectivePropertyAccessor should not consider bridge methods
• Backport "ReflectivePropertyAccessor should not consider bridge methods" [SPR-9995] #14629 Backport "ReflectivePropertyAccessor should not consider bridge methods"

Referenced from: commits 5ae706e, fce7adc

Backported to: 3.1.4

[spring-projects-issues]

Chris Beams commented

Thanks for the initial analysis, Marian. This change was introduced via commit 107fafb with the resolution of #14628. Phil Webb can comment further.

[spring-projects-issues]

Phil Webb commented

Hi Marain,

Thanks very much for the bug report and the analysis. The original need for the change related to intermittent SpEL failures that could occur due to the the fact that java class reflection returns methods in an undetermined order. If a bridge method happens to occur before a non-bridge method an error can occur (see SWF-1438 for one such bug).

Unfortunately my assumption that bridge and non-bridge methods will always be present in the class turns out to be incorrect. (http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html sample 4 is one example).

[spring-projects-issues]

Marian Gallo commented

Hi Phil,

I will try to prepare it for you. It will be problematic because this code is property of our customer and I'm not able to share it with you directly...

I made some investigation before I have written this issue. I tried to recreate a clear hierarchy similar to the real one but only with one problematic property. It this case it was not possible to reproduce it. The original hierarchy is quite huge and complex. There are a lot of relations across a lot of classes. I think this leads to indirect method bridging.

Best regards,
Marian

[spring-projects-issues]

Phil Webb commented

Hi Marian,

Thanks but I think I have reproduced the issue so there is no need. I should have a fix shortly.

Cheers,
Phil.

[spring-projects-issues]

Phil Webb commented

Marian,

I have just pushed a fix for this issue. Would you be able to try 3.2.1.BUILD-SNAPSHOT [1] and let me know if it fixes the problem for you.

Cheers,
Phil.

[1] http://repo.springsource.org/snapshot/org/springframework/spring-expression/3.2.1.BUILD-SNAPSHOT/

[spring-projects-issues]

Marian Gallo commented

Hi Phil,

it is ok with 3.2.1.BUILD-SNAPHOT.

All our unit tests have passed.

Best regards,
Marian

[spring-projects-issues]

Phil Webb commented

Thanks for testing so quickly!

[spring-projects-issues]

Tomas Huryn commented

The same error for class ReflectiveMethodResolver - bridge methods is not considered.

[spring-projects-issues]

Phil Webb commented

Tomas Huryn,

Could you please raise a new JIRA for ReflectiveMethodResolver. This specific issue is a regression that was introduced in Spring 3.2 but it looks like ReflectiveMethodResolver has always filtered bridge methods. Have you hit a specific problem with ReflectiveMethodResolver or is it just an observation?

Cheers,
Phil.