Open knuspertante opened 2 years ago
/cc @matejvasek, @patriot1burke
Any chance you can put together a sample application that exhibits this behavior?
Hey @geoand,
sorry for the delay. Today I found enough time to implement a sample application.
See: Quarkus Sample Application: Github Issue 23716
Pls use the following maven command to build this application.
mvn clean package -Pnative,lambda
If you comment this line out, the native-build will work
Thanks.
Note that the issue should likely be moved to https://github.com/quarkiverse/quarkus-amazon-services.
@jerboaa I see you had done some GraalVM related work on the DynamoDB extension, so do you mind taking a look?
Thanks
@geoand I'm not really familiar with the amazon web services stack. Last I've looked at this was due to some random class usages which needed to be runtime inited for quarkus native. That's why. Anyway, I'll see what I can do. If anybody beats me to it, be my guest ;-)
@knuspertante Based on this comment: https://github.com/quarkusio/quarkus/issues/14904#issuecomment-1057799863 What happens if you add the dymodb dep to your repro app? Like so: https://github.com/quarkusio/quarkus-quickstarts/blob/main/amazon-dynamodb-quickstart/pom.xml#L55..L58
I haven't tried this myself but it may get you somewhere :)
@geoand So I had a look at this. It seems the core of the problem is a limitation of using dynamodb in jax-rs filters. The conflict seem to come from that a) quarkus initializes everything at build time (in this case the entire resteasy jaxrs stack and related quarkus glue) b) this application uses a JAX-RS-filter which in turn uses amazon dynamodb which needs to initialize some of its classes at image runtime. Hence, there is a fundamental conflict between build time init of quarkus vs. this application's filter, which hooks into the guts of quarkus. The way to make this particular application work would be to runtime-init quarkus wholesale in native mode. Perhaps I'm missing something, though.
I think the best avenue to help @knuspertante would be to get some quarkus JAX-RS filter expert involved who can give some guidance as to how to solve this particular problem some other way.
I don't think I can help with this problem unless quarkus can be made runtime-initialized-compatible in native mode which currently, AFAIK, it isn't.
Thanks for looking into it @jerboaa
Describe the bug
The build runs fine if we only call / inject the TaskService in TaskResource. But if we use the TaskService in a JAX-RS Filter with NameBinding we need to initialize some Classes at run time. Therefore I tried to initialize our classes:
at run time but still the same error. Only if I initialize io.quarkus.runner.ApplicationImpl at run time the native-build runs. But then Quarkus or the JAX-RS application doesn't run.
When building a native-image with
the following stack-trace is printed:
Expected behavior
The native-build will run because TaskService is working in TaskResource but not in JAX-RS filter.
Actual behavior
No response
How to Reproduce?
Reproducer:
Unfortunately I can't share my code.
Output of
uname -a
orver
Darwin MacBook-Pro-21.local 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 arm64
Output of
java -version
openjdk version "17.0.1" 2021-10-19 OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12) OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode)
GraalVM version (if different from Java)
Container-Build
Quarkus version or git rev
2.7.0.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)3.8.1
Additional information
No response