I’m experiencing an issue with my Quarkus 3 application when I update from Quarkus 2. It builds and runs successfully on my local machine, but when deployed to a Kubernetes pod I get a RuntimeException. I only get this error after I updated to quarkus 3. With quarkus 2 the deployment still works and quarkus runs on the kubernetes pod. It fails with the following error:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:61)
at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:32)
Caused by: java.lang.ExceptionInInitializerError
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:70)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
at io.quarkus.runner.GeneratedMain.main(Unknown Source)
... 6 more
Caused by: java.lang.RuntimeException: Failed to start quarkus
at io.quarkus.runner.ApplicationImpl.<clinit>(Unknown Source)
... 15 more
Caused by: java.lang.IllegalAccessError: class jakarta.validation.Validation$ProviderSpecificBootstrapImpl tried to access private method 'void jakarta.validation.Validation$GenericBootstrapImpl.<init>()' (jakarta.validation.Validation$ProviderSpecificBootstrapImpl and jakarta.validation.Validation$GenericBootstrapImpl are in unnamed module of loader io.quarkus.bootstrap.runner.RunnerClassLoader @73c6c3b2), (Type jakarta.validation.Validation$ProviderSpecificBootstrapImpl (loader: io.quarkus.bootstrap.runner.RunnerClassLoader @73c6c3b2) is not a nest member of type jakarta.validation.Validation (loader: io.quarkus.bootstrap.runner.RunnerClassLoader @73c6c3b2): current type is not listed as a nest member, Type jakarta.validation.Validation$GenericBootstrapImpl (loader: io.quarkus.bootstrap.runner.RunnerClassLoader @73c6c3b2) is not a nest member of type jakarta.validation.Validation (loader: io.quarkus.bootstrap.runner.RunnerClassLoader @73c6c3b2): current type is not listed as a nest member)
at jakarta.validation.Validation$ProviderSpecificBootstrapImpl.configure(Validation.java:209)
at io.quarkus.hibernate.validator.runtime.HibernateValidatorRecorder$2.created(HibernateValidatorRecorder.java:64)
at io.quarkus.arc.runtime.ArcRecorder.initBeanContainer(ArcRecorder.java:79)
at io.quarkus.deployment.steps.ArcProcessor$generateResources844392269.deploy_0(Unknown Source)
at io.quarkus.deployment.steps.ArcProcessor$generateResources844392269.deploy(Unknown Source)
... 16 more
Here is some information of my pom.xml
:
<properties>
<jakarta.jakartaee-api.version>10.0.0</jakarta.jakartaee-api.version>
<jakarta.resource-api.version>2.1.0</jakarta.resource-api.version>
<jakarta.ws.rs-api.version>3.1.0</jakarta.ws.rs-api.version>
<maven.compiler.release>17</maven.compiler.release>
<quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
<quarkus.platform.version>3.1.0.Final</quarkus.platform.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>${quarkus.platform.artifact-id}</artifactId>
<version>${quarkus.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>all</artifactId>
<version>3.1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>jakarta.resource</groupId>
<artifactId>jakarta.resource-api</artifactId>
<version>${jakarta.resource-api.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-hibernate-validator</artifactId>
</dependency>
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>${jakarta.jakartaee-api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>${jakarta.ws.rs-api.version}</version>
</dependency>
</dependencies>
The application builds and runs without issues on my local machine. The error only occurs when running in a Kubernetes pod.
The Dockerfile.jvm
in my quarkus project contains the following image:
registry.access.redhat.com/ubi8/openjdk-17:1.20
.
I use gitlab and a gitlab-ci.yml to build the docker image via the image buildah/buildah
:
buildah bud --format docker -f src/main/docker/Dockerfile.jvm
.
I’m using the latest version of Quarkus 3.1.0.Final as you can see in my pom.xml.
I’ve tried the following troubleshooting steps:
- Verified that all dependencies have matching versions (no version conflicts are detected by intellij). I have both jakarta.validation-api and quarkus-hibernate-validator dependencies with matching versions.
- Performed a clean build and redeployment.
Since I’m new to the Kubernetes world, I don’t know what could be causing this discrepancy between local and pod environments, and how can I resolve this IllegalAccessError?
Any insights or suggestions would be greatly appreciated.
Please let me know if I need to provide more information because I don’t know what other information could be crucial to solve this problem.
I simply took out the jakarta.jakartaee-api
dependency. It then didn’t have this error anymore. Seemed like there were conflicts which we could neither resolve nor detect locally.