Logging events during native-image build

[Sanne Grinovero]

I see a number of extensions are "silencing" their log categories during the native-image build;
at first this seems like a reasonable idea because otherwise such log messages get interleaved with the GraalVM build progress information, which is a little confusing.

For an example of how such filters looks like, see:

 - https://github.com/quarkusio/quarkus/blob/7abe8ae58dc/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/graal/DisableLoggingFeature.java#L14-L47

Some minor inconveniences with this approach:

 - high maintenance costs, it's labor intensive to keep the filters up to date for all extensions.

 - each extension adding its own "DisableLoggingFeature" is adding yet-another-line to the logs as each GraalVM Feature also gets logged, so to warn about their activation.

So far this could be acceptable, but just noticed a more serious issue as well: as you might know, we perform a significant amount of processing during the compilation - the "augmentation phase".

During this processing we may also log important information; for example Hibernate ORM logs deprecation warnings, suggests migration paths, and warns about potential issues with the domain model.

I don't want to add filters for such events; would it rather be possible to rework how Logging works during the GraalVM build, so to append all messages into an internal buffer and then log them in a somewhat more structured section at the end of the build?

I'd hope this could be a core feature, so to also save us from maintaining all the ad-hoc rules that have been added to the source tree.

Thanks,

Sanne

[David Lloyd]

I don't know if GraalVM gives us a hook to know when things are finishing up, and it definitely will be using a separate process for the build, but it would probably be possible to log everything to a file during build and then replay the file at the end. Do you think that'd be sufficient?

--

- DML • he/him

[Sanne Grinovero]

Good point about the need for a GraalVM hook - I don't know for sure but I see there's various "post" events we could experiment with. org.graalvm.nativeimage.hosted.Feature#onAnalysisExit has a promising name.

Regarding the idea to log to a file and then replay it - sure that sounds great to me in principle.

Thanks,

Sanne

 

--

- DML • he/him