Skip to content
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

DefaultParameterNameDiscoverer should automatically adapt to Graal constraints [SPR-17005] #21543

spring-projects-issues opened this issue Jul 4, 2018 · 1 comment
in: core in: web type: enhancement


Copy link

@spring-projects-issues spring-projects-issues commented Jul 4, 2018

Dave Syer opened SPR-17005 and commented

ParameterNameDiscoverer is used in a number of places in Spring, not least of which is in the core DI features. AbstractAutowireCapableBeanFactory exposes a setter and a getter, but it's not available in any public interfaces that are easy to access, so it seems like you have to resort to downcasting:

((AbstractAutowireCapableBeanFactory) context.getDefaultListableBeanFactory())

MVC and Webflux also use parameter name discovery for controller methods. This can be avoided if users explicitly add annotations, or simply don't use the flexible method signature features.

The default parameter name discoverer uses reflection and also ASM, and both of these strategies is problematic or unavailable in native images (c.f. GraalVM). It seems like the AbstractAutowireCapableBeanFactory actually works fine with a NoopParameterNameDiscoverer (that just returns null), unless it has to do autowire by name (which is pretty uncommon I should think).

Issue Links:

  • #21529 Initial GraalVM native images (Substrate VM) support ("is depended on by")
  • #21530 Support platforms where Class is not Serializable in SerializableTypeWrapper
  • #21673 Detect GraalVM with system property in SerializableTypeWrapper

Referenced from: commits e8034f2

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 18, 2018

Sébastien Deleuze commented

Resolved by using no ParameterNameDiscoverer with Graal native images via org.graalvm.nativeimage.imagecode system property (which is considered as a public API) as advised by GraalVM team, see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core in: web type: enhancement
None yet

No branches or pull requests

2 participants