-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Unresolved element found in Spring DefaultListableBeanFactory #511
Comments
I tried to reproduce using this, without success; after adding some tweaks to the reflection config, here's the log:
Maybe I'm missing something from the |
Sorry, you were missing some additional JSON config for the reflection access. Try again now. And build with |
@dsyer I was able to reproduce your error. The error is caused by an unresolved element, i.e., it is most likely an error that was pushed to runtime by using
Unfortunatelly we cannot print the actual unresolved element currently since we rely on the Graal deoptimization mechanism when pushing the resolution errors to runtime, and Graal doesn't keep track of which elements are missing, it deoptimizes anyway. However, an |
Useful tip thanks, indeed |
When I compile without the |
The actual missing class is We call Digging further I run this small test:
After I compile and run it using the same
Indeed
Looking at the
However, this doesn't help us much as we actually fail during bytecode parsing, before any constant folding is run. |
That is weird. So it's a "feature" of Hotspot? Class.forName("org.springframework.beans.factory.support.DefaultListableBeanFactory") succeeds but Class.forName("org.springframework.beans.factory.support.DefaultListableBeanFactory$DependencyObjectProvider").getEnclosingClass()) fails. Anything we can do about it? |
That's the behavior on HotSpot, I guess you can call it a feature. I don't think there is anything that we can do about it in SVM. We need to load the enclosing type and build the entire type hierarchy eagerly. The only solution that I can see is refactoring the code in a way that avoids this issue. |
Worked around in Spring (https://jira.spring.io/browse/SPR-17014). This issue can be closed if no-one else has anything to say. |
Latest efforts to make a non-trivial Spring application work with native-image are now failing at runtime with this:
It could be that there is still something we can workaround or configure here, but the error isn't telling me enough to know one way or the other. To reproduce build the "jetty" branch of this project and use a graalVM build from master (to work around #497), then attempt to build a native image as in the README, but from the
FuncApplication
instead ofMicroApplication
.The text was updated successfully, but these errors were encountered: