[native-image] Rerun initialized logger?

[dnovitski]

Hi,

Got a question about class initialisation and best practices.

First a little background information:

• Using Micronaut framework for building a simple web app
• Using logback as logger framework

Our team uses logback.xml to configure logback and need this to be external to the application. Currently, Micronaut uses netty as the http server core, and Micronaut defines the io.netty package to be class initialised at build time.

A lot of netty classes use static field class initialisation to the SL4J LoggerFactory to get a Logger, which in turn static initialises logback, which in turn reads the logback.xml and this means the configuration following from logback.xml from the build time is baked into the native initial heap.

This means following standard practices there is no way to have the native application re-load the logback.xml file on startup at runtime.

It is in my opinion a good idea to (mostly) class init netty at build-time, however this complicates the logger situation when it is desired to reconfigure logback at runtime.

As a work-around, I can do something like this:

public class Application {
    public static void main(String[] args) {
        LogInitialiser.reinit();
        Micronaut.run(Application.class);
    }
}

The LogInitialiser.reinit would get the current ILoggerFactory instance, cast it to LoggerContext and reconfigure it by reading the logback.xml file from disk.

I have done this and it works. But this now means additional line of code (LogInitialiser.reinit()) is needed to the original application in order to make it work. Is it possible to reconfigure certain classes at runtime (even though they were built-time initialised already) by passing flags to the native-image command line so that the original application can work without modification?

Are there any alternative solutions to this problem? Or is the work-around currently the only way?

[thomaswue]

Yes, you can have fine-grained control over class initialization time via "--initialize-at-run-time" and "--initialize-at-build-time" as described at https://github.com/oracle/graal/blob/master/substratevm/CLASS-INITIALIZATION.md.

[dnovitski]

Sorry if I was not clear, but neither options really fit.

If I set the logback to be initialised at runtime, then native-image will complain that netty wants to use the logging framework at build time.

If I set logback to be initialised at build time, then the logback.xml will be baked into the native initial heap.

[thomaswue]

OK, I see. I think one possibility is to have more of Netty also initialized at run time. Maybe @cstancu has more insights into this.

[dnovitski]

Initialising Netty at runtime will most likely 'fix' this issue. However:

• Micronaut currently has a native-image.properties to set io.netty package to be initialised at build time (this would mean upstreamining changes which they would need to be willing to accept)
• It makes sense to initialise netty at build time. It saves significant startup time this way

[vjovanov]

--initialize-at-run-time can be applied to individual classes although the whole package was initialized at build time. Here is an example.

Do you know how many classes in netty need to be switched? Also, note that this would be a backward-incompatible change as if someone else stores instances of this class in the heap they will get a broken build.

[enderwsp]

so ,is there any clear [practical principle] to fix conflictions bettween runTime & buildTime,exclude 'ImageInfo.inImageBuildtimeCode()'