Micronaut app fails with 20.3.0 Release but works with same version compiled from source code #2991
Comments
|
Regarding building GraalVM:
You can use |
|
From the stacktrace: So that ends up initializing Graal.js through the |
|
@ilopmar why does this app have log4j on the classpath and not logback? |
|
@eregon Thanks for the information regarding to build GraalVM. I'll take a closer look at do some tests. Can you please explain why the output of the build is different? @graemerocher I added this to make Elasticsearch logging work on the JVM and this to make it work as native-image. |
|
@ilopmar but the question is why? Why not use logback? |
|
@graemerocher Because it didn't work when I created the test app sometime ago. Maybe I can try this approach I did for Liquibase https://micronaut-projects.github.io/micronaut-liquibase/latest/guide/index.html#_logging In any case, none of this explains why the Graal.js is triggered and why the builds are not the same, which I think is the really important part because I would like to create the builds as close as possible as the GraalVM team does. |
|
@eregon I think the issue migth be because I'm not building Adding Regarding the rest of the options for building I think I'm already doing what I want with: or for building the extra agents. To be honest there is a lot of libs, modules and names and I'm a little bit lost with this. I'd appreaciate any help on this to confirm that those build commands are the right ones.
What do you mean with this? Why I don't want a native image for Can you please also explain what are "bash launchers"? |
|
@graemerocher I've tried adding |
Yes
The build job is actually this one: graal/vm/ci_common/common.hocon Lines 325 to 338 in c5ff5a5 After all the hocon expansion this is the result: https://gist.github.com/gilles-duboscq/7828de2147bc3e9a436b08980ea700b0
Yes, you can use the command mentioned by Benoit to automatically download the right one. Regarding your issue with "bash launchers" are the launcher script that get generated instead of a native-image if you prevent some launchers from being built as native-images using |
|
My guess is Now It seems a bit surprising that log4j reaches into ScriptEngine's like this, maybe there is some configuration to disable that behavior? |
|
Thank you @gilles-duboscq @eregon and @loicottet for the detailed explanations. I really appreciate it! I think I'm missing some config or environment variable defined because the instructions you have provided don't work for me: Then I've realized that maybe it's because of python, so I've defined this: But now it fails with other error message: Any hints on how to fix this? @loicottet the workaround of adding |
|
I'm sorry, I've realized that Again, thank you very much! |
|
Given It looks like you already had JS cloned at |
|
Yeah, I already fixed it. It looks like I had a really old clone of |
|
I've found another issue. With the workaround provided I can build the native image, but then some javascript code is still there when running the app. To reproduce this new problem:
|
|
The whole situation is caused by the fact that services declared by modules are automatically included in the reflection configuration since 20.3 (see 678354c). In particular, |
|
|
|
@loicottet |
|
@d-kozak can you help with this? This looks like further service loader shenanigans. |
|
Hello. I apologize for taking so long to reply. @ilopmar ServiceLoaderFeatureExcludeServiceProviders is the recommended option for your use case now. I'm currently looking into how we could handle this internally. In the future, it might not be necessary, but for now please go with the flag. @sdeleuze Could you please provide me with a reproducer so that I can debug why the option is not working for you? |
|
@d-kozak Sure, run |
|
@sdeleuze I've experimented with this issue and noticed that this error is not related to the Regarding how to fix it from the client-side, at least temporarily: Useful links: |
|
Ok thanks for your feedback I will see what we could do for the short term option. |
|
Hi @d-kozak |
|
An update of HomeFinder is about to be merged, which seems to work as a 'fix' both for the Micronaut and Spring issue. I'll let you know once it is merged, so you can give it a try yourself. However, it is not a proper solution in the sense that it only erases a symptom instead of fixing the core issue, which is essentially a combination of three things:
For 1) - This is a third-party library issue, which is unfortunately outside of the scope of the Native Image team to fix. To sum it up, a quickfix will be merged soon. It should allow the GraalJSEngineFactory to be safely initialized at build time, which should consequently allow the log4j to be initialized assuming it will not actually use graaljs to evaluate some javascript code. Full exclusion of that library from native image build unless given flag is set is a work in progress. |
|
Hi @d-kozak - did the quickfix get merged and if so, in what version? Thank you |
|
Hello @AndersClausen, The quickfix was merged last week - 1b92af4 so it should be available in 21.1 and I also made a backport request for the next 20.3 release. I've also been looking into whether |
|
@d-kozak Any chance that |
|
By now, with Truffle Unchained, I believe this issue should no longer occur. If you still have issues, please reopen with a reproducer. |
Describe the issue
We've been continuously testing the
release/graal-vm/20.3branch for the last couple of weeks to make sure everything would work with Micronaut. All our test applications passed the build this morning at 7am using latest Micronaut snapshot and that mentioned release branch.This morning I've switched to use the 20.3.0 version released yesterday and our Elasticsearch test application has started to fail to build the native image. It fails for both JDK 8 and 11.
I've been doing some tests locally and I've discovered that we were using and old version to build GraalVM:
build 25.252-b09-jvmci-20.2-b01vsbuild 25.272-b10-jvmci-20.3-b06. The latter is the one from 20.3.0 release.I though that was the problem so I've compiled again GraalVM branch
release/graal-vm/20.3using that new java version, but I'm able to build the native image. Switching the jvm to 20.3.0 Release make it fail again.So, I have a few questions:
Can you please confirm that the 20.3.0 release was created from this commit c5ff5a5.
This is what we do on CI. I've disabled pretty much everything because I'm only interested in
native-imageand I want the build to be as fast as possible.For local sometimes I use the following, which creates the agent and the diagnostics-agent:
Can you please share which options do you use to compile the release? I would like to use the same to have repeateble builds. Please keep in mind that I would like to disable all the things I don't need.
One final thing. I'm downloading the java releases to build GraalVM from https://github.com/graalvm/graal-jvmci-8/releases/ for Java 8 and https://github.com/graalvm/labs-openjdk-11/releases/ for Java 11. Are those the right versions I need to download?
Steps to reproduce the issue
git clone https://github.com/micronaut-graal-tests/micronaut-elasticsearch-graalcd micronaut-elasticsearch-graalgit checkout 2.1.x./build-native-image.shNow Instead of using GraalVM 20.3.0 release, compile GraalVM from source code using
release/graal-vm/20.3branch and this java version.Describe GraalVM and your environment:
More details
Error using 20.3.0 Release.
The text was updated successfully, but these errors were encountered: