-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invoke init/destroy/SpEL methods via public declaring type whenever possible #33216
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Milestone
Comments
sbrannen
added
in: core
Issues in core modules (aop, beans, core, context, expression)
status: waiting-for-internal-feedback
An issue that needs input from a member or another Spring Team
labels
Jul 14, 2024
A failing test case and proof of concept can be viewed in the following feature branch. main...sbrannen:spring-framework:issues/gh-33216-spel-invoke-method-via-public-type Note, however, that |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
sbrannen
removed
the
status: waiting-for-internal-feedback
An issue that needs input from a member or another Spring Team
label
Aug 19, 2024
sbrannen
added a commit
to sbrannen/spring-framework
that referenced
this issue
Aug 19, 2024
sbrannen
changed the title
Always invoke method via public declaring type in SpEL
Always invoke methods via public declaring type in SpEL
Aug 19, 2024
sbrannen
added a commit
to sbrannen/spring-framework
that referenced
this issue
Aug 21, 2024
sbrannen
changed the title
Always invoke methods via public declaring type in SpEL
Always invoke init/destroy/SpEL methods via public declaring type
Aug 22, 2024
sbrannen
changed the title
Always invoke init/destroy/SpEL methods via public declaring type
Invoke init/destroy/SpEL methods via public declaring type whenever possible
Aug 22, 2024
sbrannen
added a commit
that referenced
this issue
Aug 27, 2024
Commit 47f88e1 introduced support for invoking init/destroy/SpEL methods via public types whenever possible. To achieve that, getInterfaceMethodIfPossible() was modified so that it only returned interface methods from public interfaces; however, we have learned that third parties relied on the previous behavior which found any interface method (even in non-public interfaces). In light of the above, this commit partially reverts commit 47f88e1 in order to reinstate getInterfaceMethodIfPossible() in non-deprecated form with its previous behavior. See gh-33216
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Overview
The original scope of this issue was limited to method invocations in SpEL expressions (see below); however, after further investigation we have decided to apply the same enhancement for
init
anddestroy
methods inspring-beans
.For reflective method invocation in the Spring Expression Language (SpEL), we currently use
ClassUtils.getInterfaceMethodIfPossible(...)
to attempt to invoke the method via an interface, based on the rationale stated in the Javadoc for that utility.This works well for methods which are actually defined in an interface, but it does not work for methods defined in a superclass.
For example, in a SpEL expression it is currently impossible to invoke
toString()
on a non-public type in a different module. This can be seen when attempting to invoketoString()
on an unmodifiable list created byCollections.unmodifiableList(...)
. Doing so results in an exception similar to the following.Users can address this by adding an appropriate
--add-opens
declaration, such as--add-opens java.base/java.util=ALL-UNNAMED
.However, it would be nice if applications did not have to add such an
--add-opens
declaration for such use cases in SpEL.For compiled expressions, we added support in #29857 to invoke the method via a public declaring type, since that is an actual requirement for compiled Java code. So, we should consider doing the same for methods invoked via reflection.
Related Issues
The text was updated successfully, but these errors were encountered: