**Log4j's Support Issues with GraalVM**

[EkkoWH]

Description

[A clear and concise description of what the bug is.]

Configuration

Version: [2.25.0]

Operating system: [Windows Or linux]

JDK: [17]

Logs

Logging system failed to initialize using configuration from 'classpath:log4j2-demo.xml'
java.lang.IllegalStateException: Could not initialize Log4J2 logging from classpath:log4j2-demo.xml
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.loadConfiguration(Log4J2LoggingSystem.java:273)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.load(Log4J2LoggingSystem.java:242)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.loadConfiguration(Log4J2LoggingSystem.java:236)
        at org.springframework.boot.logging.AbstractLoggingSystem.initializeWithSpecificConfig(AbstractLoggingSystem.java:67)
        at org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:58)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.initialize(Log4J2LoggingSystem.java:223)
        at org.springframework.boot.context.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:335)
        at org.springframework.boot.context.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:298)
        at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:246)
        at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:223)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:185)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:178)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:156)
        at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:138)
        at org.springframework.boot.context.event.EventPublishingRunListener.multicastInitialEvent(EventPublishingRunListener.java:136)
        at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:81)
        at org.springframework.boot.SpringApplicationRunListeners.lambda$environmentPrepared$2(SpringApplicationRunListeners.java:64)
        at java.base@21.0.5/java.lang.Iterable.forEach(Iterable.java:75)
        at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:118)
        at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:112)
        at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:63)
        at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:353)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:313)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1361)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1350)
        at io.example.showcase.MainApplication.main(MainApplication.java:19)
Caused by: java.net.ProtocolException: Protocol resource has not been enabled as an allowed protocol
        at org.apache.logging.log4j.core.net.UrlConnectionFactory.createConnection(UrlConnectionFactory.java:79)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.getConfigurationSource(Log4J2LoggingSystem.java:292)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.load(Log4J2LoggingSystem.java:279)
        at org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.loadConfiguration(Log4J2LoggingSystem.java:264)
        ... 27 more

Reproduction

Any Spring Boot application that uses Log4j2 and is then compiled into a native image.

spring-projects/spring-boot#37152 (comment)

I didn’t find a solution in the Log4j documentation. Coincidentally, I came across someone raising a similar issue here, but unfortunately, it hasn't received any response. So I’d like to bring it up again.

In GraalVM, the jar protocol is transformed into the resource protocol. However, in org.apache.logging.log4j.core.net.UrlConnectionFactory, the default allowed protocols only include "https, file, jar", and not resource. As a result, an application that works fine in its JAR form stops working after being compiled into a native-image. Manually setting the environment variable log4j2.Configuration.allowedProtocols=resource does solve the issue.

That said, I’m not sure whether this is the right approach. Does this mean Log4j2 can’t be used out of the box with GraalVM? I'm also uncertain whether this is a support issue on Log4j2’s side or Spring Boot’s integration with Log4j. I look forward to your thoughts on this!

[ppkarwasz]

Hi @EkkoWH,

I didn’t find a solution in the Log4j documentation. Coincidentally, I came across someone raising a similar issue here, but unfortunately, it hasn't received any response. So I’d like to bring it up again.

Could you share a link to the other issue mentioning the resource protocol?

In GraalVM, the jar protocol is transformed into the resource protocol. However, in org.apache.logging.log4j.core.net.UrlConnectionFactory, the default allowed protocols only include "https, file, jar", and not resource. As a result, an application that works fine in its JAR form stops working after being compiled into a native-image. Manually setting the environment variable log4j2.Configuration.allowedProtocols=resource resolves the issue.

Thanks for identifying the root cause! You are right, the issue occurs because resource isn't included in the log4j2.configurationAllowedProtocols property.

As an alternative solution, you can create a log4j2.component.properties file in the root of your project’s classpath with the following content:

log4j2.configurationAllowedProtocols = file, https, jar, resource

This will allow you to avoid passing the log4j2.configurationAllowedProtocols system property when running your executable.

That said, I’m not sure whether this is the right approach. Does this mean Log4j2 can’t be used out of the box with GraalVM? I'm also uncertain whether this is a support issue on Log4j2’s side or Spring Boot’s integration with Log4j.

This is primarily an integration issue between Log4j Core and Spring Boot. Log4j Core treats classpath resources differently and does not apply the log4j2.configurationAllowedProtocols property to them, which is why the log4j-core and log4j-core-jtl profiles in our GraalVM integration tests work out-of-the-box without additional configuration.

However, the Log4j2LoggingSystem in Spring Boot treats classpath resources like any other resource, applying the log4j2.configurationAllowedProtocols check. For more details, refer to issue #3794.

I'll fix this issue on our end, by adding resource to the default list of allowed protocols.

Log4j API Backends Supported "Out-of-the-Box" with GraalVM:

In my (not so impartial 😉) opinion, among the logging frameworks supported by the Log4j API, Log4j Core provides the most seamless "out-of-the-box" experience with GraalVM:

• JUL (java.util.logging): To use java.util.logging, you need to:

  • Add the configuration file location to resource-config.json.
  • Include all classes used in the configuration file in reflect-config.json.

• Logback: To use Logback, you need to:

  • Add the configuration file location to resource-config.json.
  • Use the external oracle/graalvm-reachability-metadata repository (enabled by default), where the Spring Boot team maintains a reflect-config.json for Logback.

• Log4j Core: With Log4j Core (or the SimpleLogger) logging backend, you don't need any extra configuration:

  • As long as your configuration files are in the default log4j2<contextName>.<extension> location, they will be automatically included in the GraalVM image.
  • The reflect-config.json metadata is embedded in the log4j-core JAR, so you'll always have the correct metadata for the version you're using.

[EkkoWH]

@ppkarwasz
Hello, thank you so much for your warm and thoughtful response!

Could you share a link to the other issue mentioning the resource protocol?

I think I might not have expressed myself clearly earlier（It might have been because I used machine translation.
） — the person who previously raised this issue did so in the context of Spring Boot, and unfortunately, it went unanswered. Here is the link to that issue:
spring-projects/spring-boot#37152 (comment)

Regarding your suggestion about using log4j2.component.properties — you're absolutely right. I revisited the relevant source code today and confirmed that configuring it this way indeed works, and it conveniently eliminates the need to set environment variables manually.

I truly appreciate that you're planning to fix this issue! This means that whether we run the application as a JAR or as a native executable, we won’t need any extra configuration — which is fantastic!

In my (not so impartial 😉) opinion, among the logging frameworks supported by the Log4j API, Log4j Core provides the most seamless "out-of-the-box" experience with GraalVM:

Finally, I want to clarify that I’m not denying the excellent experience Log4j provides — it’s genuinely great! We've tried other logging frameworks in the past, but Log4j has always been our favorite. I just felt that needing extra configuration when switching from a JAR to a native image somewhat diminished the “out-of-the-box” experience. But of course, that doesn't change how much we appreciate Log4j!

I was simply unsure whether my current approach was the right one, which is why I wanted to ask here and learn from your insights.

Thank you again for your clarification!