Thanks for the report. Could you extract a small reproducer?

In 6.0, the method is called successfully via SpEL, but in 6.2 the same expression does not return a value, and Web Flow tries the overloaded method signature with a RequestControl parameter, and fails if that doesn't exist.

It does work with parenthesis, i.e. "existingReportActions.evaluateExistingReport()".

This changed in 6.2.0-M1. I cannot reproduce it in 6.1.x.

I have not yet narrowed it down to a specific change, but suspect it is expected, and we may just have to document it as an upgrade note.

I'm currently investigating whether we can support the previous use case in Spring Web Flow, but in the interim I can provide my initial findings here.

Basically, there are two different SpEL features that come into play here.

• property reference
• method reference

existingReportActions.evaluateExistingReport is a property reference that is supported by a registered PropertyAccessor.

existingReportActions.evaluateExistingReport() and existingReportActions.evaluateExistingReport(#requestContext) are both method references.

Thus, adding the () to existingReportActions.evaluateExistingReport converts it to a method reference which is handled by org.springframework.expression.spel.ast.MethodReference instead of org.springframework.expression.spel.ast.PropertyOrFieldReference.

Without the (), a registered PropertyAccessor is used to invoke the property accessor method.

If the org.springframework.expression.spel.support.ReflectivePropertyAccessor is used (which appears to be the case prior to Spring Framework 6.2), the invocation works.

However, if the org.springframework.webflow.expression.spel.ActionPropertyAccessor is used (which appears to be the case starting with Spring Framework 6.2 M1), the invocation fails since the method does not declare a RequestContext argument which is required by org.springframework.webflow.action.MultiAction.doExecute(RequestContext).

I believe the change in behavior (switch from ReflectivePropertyAccessor to ActionPropertyAccessor) is due to the following improvements for PropertyAccessor sorting.

• spring-projects/spring-framework@4b0a048
• spring-projects/spring-framework@d912770

In other words, I believe the behavior with Spring Framework 6.2 is the expected behavior in terms of SpEL contracts, and I believe those fixes/improvements in SpEL highlight something that maybe never should have worked in Spring Web Flow with the current implementations of ActionPropertyAccessor and MultiAction.

I will attempt to confirm that last statement and report back here.

In other words, I believe the behavior with Spring Framework 6.2 is the expected behavior in terms of SpEL contracts, and I believe those fixes/improvements in SpEL highlight something that maybe never should have worked in Spring Web Flow with the current implementations of ActionPropertyAccessor and MultiAction.

I will attempt to confirm that last statement and report back here.

I confirmed that.

Cause of the Error

The current implementation of ActionPropertyAccessor does not align with the requirements of MultiAction.

• ActionPropertyAccessor claims it supports any Action method, disregarding the formal parameter list of the named method.
• MultiAction requires that the Action method accepts a single RequestContext argument.

Thus, ActionPropertyAccessor incorrectly claims that it supports an Action method that accepts zero arguments, when it in fact should not. The result is that MultiAction fails to invoke the method since it does not accept the single RequestContext argument, resulting in the NoSuchMethodException.

Explanation

Prior to Spring Framework 6.2, SpEL incorrectly sorted the applicable PropertyAccessor implementations, giving the ReflectivePropertyAccessor priority over the ActionPropertyAccessor.

The effect of that is that an expression such as existingReportActions.evaluateExistingReport was handled by ReflectivePropertyAccessor which always invokes the evaluateExistingReport() method without any arguments (like a JavaBeans "getter" method).

Beginning with Spring Framework 6.2, SpEL correctly sorts the applicable PropertyAccessor implementations, by taking into account their getSpecificTargetClasses() methods. This gives priority to the ActionPropertyAccessor, effectively overriding the ReflectivePropertyAccessor.

The effect of that is that an expression such as existingReportActions.evaluateExistingReport is now handled by ActionPropertyAccessor since existingReportActions is in instance of Action. An AnnotatedAction is created which tracks the Action target and method name: existingReportActions and evaluateExistingReport in this scenario. MultiAction.doExecute(RequestContext) then throws an exception, because MethodKey.resolveMethod() fails to resolve the nonexistent evaluateExistingReport(RequestContext) method.

PropertyAccessor Execution Order

When evaluating the existingReportActions.evaluateExistingReport SpEL expression...

With Spring Framework 6.1.x, the registered property accessors are evaluated in this order:

• ReflectivePropertyAccessor
• FlowVariablePropertyAccessor
• BeanFactoryPropertyAccessor
• ActionPropertyAccessor

With Spring Framework 6.2, the registered property accessors are evaluated in this order:

• ActionPropertyAccessor
• ReflectivePropertyAccessor
• FlowVariablePropertyAccessor
• BeanFactoryPropertyAccessor

In summary, ActionPropertyAccessor is now correctly queried before ReflectivePropertyAccessor with Spring Framework 6.2.

Proposed Fix

The following change to ActionPropertyAccessor allows the reported use case to work.

@Override
public boolean canRead(EvaluationContext context, Object target, String name) {
	// Ensure the target is an Action.
	if (!(target instanceof Action)) {
		return false;
	}
	// Ensure the method adheres to the signature required by:
	// Action: execute(RequestContext)
	// or
	// MultiAction: <method name>(RequestContext)
	Method method = ReflectionUtils.findMethod(target.getClass(), name, RequestContext.class);
	return (method != null);
}

Superseded by #1819.