[3.x] Classes that should be initialized at run time got initialized during image building #6284
Comments
romain-grecourt
added
bug
|
see also #6260 |
- Isolate the use of --static with to Linx only. - Add a native-image.properties file in archetypes for all generated project Fixes helidon-io#6284
* Fix native-image build-time initialization - Isolate the use of --static with to Linx only. - Add a native-image.properties file in archetypes for all generated project Fixes #6284 * specify build-args for the build-native-image execution, and ensure it's merged
|
I created a new project with the Helidon CLI: Then, I configured it with MicroProfile JWT and set it up as a resource server. Everything works when running with I tried using the workaround in this issue, but it does not help. <plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>--initialize-at-build-time=com.okta</buildArgs>
</configuration>
</plugin>My You can see my project at https://github.com/oktadev/auth0-java-rest-api-examples. |
|
Today I discovered that everything works with Java 17 but not 19. I'm using SDKMAN: 22.3.r17-grl works, 22.3.r19-grl does not This is unfortunate since the latest versions of Micronaut, Quarkus, and Spring Boot all work with Java 19. |
|
I tried it with 22.3.3.r20-grl today, and it seems to have a different error now: |
|
Hi Matt @mraible, it's interesting that TypeResolver initialization is a problem only for GraalVM 22.x.r19, workaround is |
|
Deleted element exception is even better, it doesn't happen when you try to diagnose it with Index: helidon/src/main/resources/META-INF/native-image/com.okta.rest/helidon/native-image.properties
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>ISO-8859-1
===================================================================
diff --git a/helidon/src/main/resources/META-INF/native-image/com.okta.rest/helidon/native-image.properties b/helidon/src/main/resources/META-INF/native-image/com.okta.rest/helidon/native-image.properties
--- a/helidon/src/main/resources/META-INF/native-image/com.okta.rest/helidon/native-image.properties (revision 1536ded03974fc455762ee4ae3fbf09d4a1d29cb)
+++ b/helidon/src/main/resources/META-INF/native-image/com.okta.rest/helidon/native-image.properties (date 1687348599487)
@@ -1,1 +1,3 @@
-Args=--initialize-at-build-time=com.okta.rest
+Args=--initialize-at-build-time=com.okta.rest \
+ --initialize-at-run-time=io.helidon.openapi.ExpandedTypeDescription \
+ --report-unsupported-elements-at-runtime
\ No newline at end of file
|
Since #5308 building Helidon MP application with native image fails:
helidon init --batch --version 3.1.1 -Dflavor=mp -Dapp-type=quickstart -Dpackage=com.acme cd quickstart-mp mvn package -Pnative-image -DskipTestsFails with:
A work-around is to use
--initialize-at-build-time=com.acme(work-around provided in #6260):We used to have
--initialize-at-build-timeinside thenative-image.propertiesbundled inhelidon-microprofile-cdi.jar; however that is deprecated:See the relevant documentation here:
Should we require users to pass
--initialize-at-build-time=com.acmeOr can we do something that does not require hard-coding the package ?
The class that are failing are initialized by
io.helidon.integrations.graal.mp.nativeimage.extension.WeldFeature:Perhaps we can use RuntimeClassInitialization.java) in
WeldFeatureto ensure that user beans are initialized at build time...The reason why we did not catch this is that we have defined
--initialize-at-build-time=io.helidonin a couple of places and our integration test applications useio.helidon.xxx.If possible we need to avoid using
--initialize-at-build-time=io.helidonand enumerate all packages. (i.e. no wildcard)We should also consider refactoring our tests to use a package that does not start with
io.helidon; E.g.com.acme.The text was updated successfully, but these errors were encountered: