Native build failed after 3.x.x upgrade, using panache mongodb (maybe releated to ManagedExecuter and narayana) #35215
Comments
|
/cc @FroMage (panache), @evanchooly (mongodb), @geoand (jib), @loicmathieu (mongodb,panache) |
geoand
added
area/narayana
|
I would start by checking the dependency tree to make sure you have a |
|
Checking the dependency tree reveals that no JMS API jar is being pulled in, so it indeed looks like a missing dependency. On the other hand Digging into this it looks like the reflection registration is triggered by This doesn't look like a native-image issue to me, more like a configuration issue, either on the application side or the Quarkus side. One needs to inspect the dependency tree starting from HTH |
|
FWIW, @gsmet I also think that the following diff helps a bit more in figuring out what lead to the said classes to be registered for reflection (although still not clear, it at least gives a class name you can work with). diff --git a/core/deployment/src/main/java/io/quarkus/deployment/builditem/nativeimage/ReflectiveHierarchyBuildItem.java b/core/deployment/src/main/java/io/quarkus/deployment/builditem/nativeimage/ReflectiveHierarchyBuildItem.java
index c75ec59494e..c09d11cdc69 100644
--- a/core/deployment/src/main/java/io/quarkus/deployment/builditem/nativeimage/ReflectiveHierarchyBuildItem.java
+++ b/core/deployment/src/main/java/io/quarkus/deployment/builditem/nativeimage/ReflectiveHierarchyBuildItem.java
@@ -141,7 +141,7 @@ public Predicate<MethodInfo> getIgnoreMethodPredicate() {
}
public boolean hasSource() {
- return source != null;
+ return source != null && source != UNKNOWN_SOURCE;
}
public boolean isSerialization() {This results in the following output for the given example: |
|
I have made another reproducer with only forking quarkus-quickstarts/mongodb-panache-quickstart. Here it is https://github.com/ayhanap/quarkus-quickstarts-issue-35215 Just added a single commit, which basically just indirectly links a class using To reproduce:
Here is the logs from my run. It's same as original, starting with warnings about jakarta.jms classes. I think because it sees |
|
Looks like in both cases, we have an entity that should indeed be registered for reflection, but it has fields annotated with |
|
BTW, at last I upgraded to 3.x.x by refactoring any ManagedExecutor reference from related Entities. But this stays as a little constraint. |
|
@FroMage maybe there can be legitimate use case of fields with What disturb me more is a field inside an entity that is an application scoped bean with injection in it, this is a stange design. |
It is very strange, but it's also very strange that we register for reflection (for bson, I assume) things that will be ignored by it. |
|
There is a combination of multiple issues. For the initial reproducer
For the second reproducer
|
Describe the bug
Native build fails with missing classes/libs related to narayana after upgrading to 3.2.2.Final (from 2.x.x)
Expected behavior
Native build should successfully complete. (works fine with 2.16.9.Final)
Actual behavior
Native build fails with the following log
How to Reproduce?
Here is a reproducer:
https://github.com/ayhanap/quarkus-3.x.x.native-build-error/tree/main
Output of
uname -aorverDarwin Ayhans-MBP.home 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64
Output of
java -versionopenjdk version "17.0.5" 2022-10-18
GraalVM version (if different from Java)
Running Quarkus native-image plugin on GraalVM 22.3.1 Java 17 CE (Java Version 17.0.6+10-jvmci-22.3-b13)
Quarkus version or git rev
3.2.2.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Additional information
I've recently upgraded my project to use Quarkus 3.x.x. But although project works nicely, there is a strange native build error related to narayana which didn't make any sense. Tried to check plugin versions and all seems ok.
Spent hours to make a minimal reproducer because it is very inconsistent but seems to be related to
ManagedExecutor. Works ok if you just comment outManagedExecutor.The text was updated successfully, but these errors were encountered: