Revise documentation for SpEL PropertyAccessor and IndexAccessor APIs regarding ordering
#33862
Assignees
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: documentation
A documentation task
Milestone
Comments
sbrannen
added
type: documentation
sbrannen
added a commit
to sbrannen/spring-webflow
that referenced
this issue
Nov 9, 2024
Prior to this commit, if a Spring Expression Language (SpEL) expression did not include parentheses for a MultiAction method that does not accept a RequestContext argument, the flow would pass on Spring Framework versions prior to 6.2, but the same flow would fail on Spring Framework 6.2 M1 or later. The following is such an expression and is effectively a property reference which must be handled by a registered PropertyAccessor: "reportActions.evaluateReport". The reason for the change in behavior is that Spring Framework 6.2 M1 includes a bug fix for ordering SpEL PropertyAccessors. That bug fix correctly results in Spring Web Flow's ActionPropertyAccessor being evaluated before SpEL's ReflectivePropertyAccessor. Consequently, an expression such as "reportActions.evaluateReport" is now handled by ActionPropertyAccessor which indirectly requires that the action method accept a RequestContext argument. When the method does not accept a RequestContext argument, the flow fails with a NoSuchMethodException. To address that, this commit revises the implementation of canRead(...) in ActionPropertyAccessor so that it only returns `true` if the action method accepts a RequestContext argument. When ActionPropertyAccessor's canRead(...) method returns `false`, the generic ReflectivePropertyAccessor will be used instead, which restores the pre-6.2 behavior for such expressions. The test suite passes for the following Spring Framework versions. - ./gradlew -PspringFrameworkVersion=6.0.23 --rerun-tasks clean check - ./gradlew -PspringFrameworkVersion=6.1.14 --rerun-tasks clean check - ./gradlew -PspringFrameworkVersion=6.2.0-RC3 --rerun-tasks clean check See spring-projects/spring-framework#33861 See spring-projects/spring-framework#33862 Closes spring-projectsgh-1802
bclozel
pushed a commit
that referenced
this issue
Nov 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
This is a follow-up to #33861 to ensure that the Javadoc for
TargetedAccessor,PropertyAccessor, andIndexAccessornow clearly aligns with the underlying ordering algorithm.Related Issues
PropertyAccessorordering for supertype and generic matches does not adhere to contract #33861The text was updated successfully, but these errors were encountered: