You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Excluding an auto-configuration class, such as GroovyTemplateAutoConfiguration via application properties, causes property binding to fail when building and launching GraalVM native images. The basic setup should be as follows (I can certainly put together a reproducer, if it helps to clarify the scenario):
Ensure the application contains the dependency groovy-templates-4.0.12.jar to satisfy the conditions required by GroovyTemplateAutoConfiguration, and then:
./gradlew nativeCompile
Launch the native image to see:
2023-05-31 08:04:47 WARN o.s.b.w.s.c.ServletWebServerApplicationContext -
Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'welcomePageHandlerMapping': Instantiation of supplied bean failed
2023-05-31 08:04:47 ERROR o.s.b.d.LoggingFailureAnalysisReporter -
***************************
APPLICATION FAILED TO START
***************************
Description:
Failed to bind properties under 'spring.groovy.template' to
org.springframework.boot.autoconfigure.groovy.template.GroovyTemplateAvailabilityProvider$GroovyTemplateAvailabilityProperties:
Reason: java.lang.NoSuchMethodException:
org.springframework.boot.autoconfigure.groovy.template.GroovyTemplateAvailabilityProvider$GroovyTemplateAvailabilityProperties.<init>()
Action:
Update your application's configuration
Analysis
GroovyTemplateAutoConfiguration is tagged with @ImportRuntimeHints({GroovyTemplateRuntimeHints.class}). Excluding the class will also deactivate the runtime hint registration process.
This is a bit of a tricky scenario where in the general sense, the app wants to use and have access to the functionality offered by a dependency, i.e. groovy-templates-4.0.12.jar, and yet does not need or want to activate the Spring Boot auto-configuration that detects that library.
The following construct does not exclude the auto-configuration class, when attached to the application's entrypoint:
After including the above, the AOT generated sources continue to include bean definitions found and processed by GroovyTemplateAutoConfiguration.
Removing the exclusion rules altogether and starting clean with just the noted dependency causes other issues when building and launching GraalVM native images, i.e.:
Error creating bean with name 'groovyMarkupConfigurer': No signature of method: org.codehaus.groovy.control.customizers.ASTTransformationCustomizer$_setAnnotationParameters_closure1.doCall() is applicable for argument types: (SimpleImmutableEntry) values: [extensions=groovy.text.markup.MarkupTemplateTypeCheckingExtension]
Possible solutions: findAll(), findAll(), isCase(java.lang.Object), isCase(java.lang.Object)
...and many other similar errors, all groovy-related. There is no other way to skip the generation of the groovyMarkupConfigurer bean, other than to perhaps reconstruct it again, mute it and allow spring-bean-overriding.
If you'd like to see a reproducer, please let me know.
The text was updated successfully, but these errors were encountered:
The TemplateAvailabilityProvider implementations are loaded via spring.factories and called through the error infrastructure. This happens irrespective of whether the view technology's auto-configuration was used. If the auto-configuration has been excluded, this also removes the import of the runtime hints that are necessary for the template availability provider to work in a native image.
It looks like we need to decouple the import of the runtime hints from the auto-configurations. Do you have any spring.groovy.template.* properties? I am wondering if such properties are necessary to trigger the problem.
Thank you Andy! I appreciate the reference to the docs and the known limitations. (On a related Groovy note and perhaps for future passer-bys, anybody running Spring Boot and native-images with the thymeleaf-layout-dialect, a codebase written in Groovy, will run into similar and much more severe issues)
After a bit of trial and error, research and beating a bunch of other stuff into submission, I was able to get this working:
So no bug there. Apologies for the false alarm. I did also look around and the only setting I could find was spring.groovy.template.enabled=false. I can try to remove this and run the build again, if it helps with diagnostics.
Certainly, I would agree that decoupling the runtime hint registration from the auto-configurations would be best to avoid side-effects such as this.
wilkinsona
changed the title
Excluding auto-configuration class causes property binding to fail for native images
Excluding auto-configuration class the relates to a TemplateAvailabilityProvider causes property binding to fail for native images
Jun 23, 2023
wilkinsona
changed the title
Excluding auto-configuration class the relates to a TemplateAvailabilityProvider causes property binding to fail for native images
Excluding auto-configuration class that relates to a TemplateAvailabilityProvider causes property binding to fail for native images
Jun 23, 2023
Uh oh!
There was an error while loading. Please reload this page.
Environment
Problem
Excluding an auto-configuration class, such as
GroovyTemplateAutoConfiguration
via application properties, causes property binding to fail when building and launching GraalVM native images. The basic setup should be as follows (I can certainly put together a reproducer, if it helps to clarify the scenario):application.yml
file, define:groovy-templates-4.0.12.jar
to satisfy the conditions required byGroovyTemplateAutoConfiguration
, and then:Launch the native image to see:
Analysis
GroovyTemplateAutoConfiguration
is tagged with@ImportRuntimeHints({GroovyTemplateRuntimeHints.class})
. Excluding the class will also deactivate the runtime hint registration process.This is a bit of a tricky scenario where in the general sense, the app wants to use and have access to the functionality offered by a dependency, i.e.
groovy-templates-4.0.12.jar
, and yet does not need or want to activate the Spring Boot auto-configuration that detects that library.The following construct does not exclude the auto-configuration class, when attached to the application's entrypoint:
After including the above, the AOT generated sources continue to include bean definitions found and processed by
GroovyTemplateAutoConfiguration
....and many other similar errors, all groovy-related. There is no other way to skip the generation of the
groovyMarkupConfigurer
bean, other than to perhaps reconstruct it again, mute it and allow spring-bean-overriding.If you'd like to see a reproducer, please let me know.
The text was updated successfully, but these errors were encountered: