This repository was archived by the owner on Feb 23, 2023. It is now read-only.
This repository was archived by the owner on Feb 23, 2023. It is now read-only.
Too many warnings when image is built #502
Closed
Description
Any spring boot application pretty much generates hundreds of these:
WARNING: Could not register reflection metadata for org.springframework.boot.autoconfigure.data.rest.RepositoryRestMvcAutoConfiguration. Reason: java.lang.NoClassDefFoundError: org/springframework/data/rest/webmvc/config/RepositoryRestConfigurer.
I think it would be useful to tone it down a bit, even if the logs are still emitted.
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
sdeleuze commentedon Feb 24, 2021
Any thoughts @aclement ?
aclement commentedon Feb 24, 2021
I don't think these are all us directly but I think there are things we could do that would have a side effect of reducing them. sure I will take a look.
aclement commentedon Feb 26, 2021
As suspected, not entirely under our control. For a few we can improve our hints but it isn't about tweaking a hint to mention specific members, the only way to fix these is absolutely not include a class in the reflect-config.json file at all, and we can't do that in all cases. Deeper dive:
For Spring not to fail, we have to mention some types in the reflect-config.json, we register them as simply as possible:
This enables Spring to be happy, we aren't configuring reflective access any deeper because we've already determined none of it is relevant (that configuration fails a ConditionalOnClass check, so we know the contents don't matter), so it doesn't matter that spring won't find methods on this type.
Unfortunately, even if you just lightly mention a class like that, GraalVM will validate all the fields/methods/etc. If there is any kind of reference that can't be resolved, the WARNING will come out. This includes references to types via generics. Now
ValidationAutoConfiguration
includes a methodmethodValidationPostProcessor
that uses a type that may not be on the classpathjavax.validation.Validator
). So with our simple reference above in .json, we will get:We cannot get that to stop happening right now (well, we could craft more substitutions...but I'm not sure how many it would be). Even if we fully list the methods we do care about in the .json and skip
methodValidationPostProcessor
in that list, it doesn't affect what GraalVM will check, you'll still get the warning and there is no control on that warning, it is a sysout println (inReflectionDataBuilder.java
in GraalVM).A solution to many of these warnings is coming. When we move to functional registration we won't need to mention these configurations at all (that contain unresolvable types), and the warnings will disappear. I'd say let's tackle the remaining ones when we get to 0.9.2 and functional registration, rather than spend a lot of time now patching Spring when it isn't the long term direction.
aclement commentedon Jul 21, 2021
There are very few of these warnings now with 0.11 but until 0.11 is further along with the AOT infra all done and all samples passing I won't claim success. Right now for commandlinerunner there are 6 of these remaining related to AOP, and 10 for webmvc-tomcat.
aclement commentedon Jul 21, 2021
I rewrote
AOPHints
and nowcommandlinerunner
andwebmvc-tomcat
run with no warnings, but it is pretty certain other samples will trigger warnings once we are able to run them.sdeleuze commentedon Jul 26, 2021
Thanks, let's continue to refine that with other samples, I think we can close this issue since it was about crazy amount of warnings. It seems as expected the behavior is much cleaner now.