Sébastien Deleuze created this issue on 11/Jan/23 2:16 PM

Logback XML parsing is hardly usable on native image at runtime, to solve that issue, Spring Boot has implemented logback.xml parsing + generation of Logback model at build time, and this works well.

But from a GraalVM native image static analysis point of view, XML parsing capabilities are reachable from GenericXMLConfigurator#doConfigure(URL). In practice, that means that [675 unused classes at
runtime|https://gist.github.com/sdeleuze/674b63fc9d3c265ff51877db3b8a5e7f] are compiled and shipped in the native image, increasing the footprint (RSS memory) by 2.43M for nothing.

As discussed in https://github.com/spring-projects/spring-boot/issues/33324, the Spring team would like to know if Logback could make it possible to remove such XML parsing capabilities from the reachable code path when unneeded.

This method is reachable from various places, including services loaded by the service loader where we don't have any control, so the way to handle that in an elegant way is not 100% obvious.

Maybe a static boolean property controlled by the detection of a logback configuration file (extracting the logic from DefaultJoranConfigurator#findURLOfDefaultConfigurationFile) could make GenericXMLConfigurator#doConfigure(URL) implementation no op or throwing an
exception when XML configuration files are not present. Combined with the capability of computing some static fields at build time, that could allow us to have the desired behavior and make XML code unreachable without too much impact on Logback infrastructure.

Happy to discuss other options, including first class build-time model generation if there is interest on that topic.

Any thoughts?