ppkarwasz commented on issue #3790: URL: https://github.com/apache/logging-log4j2/issues/3790#issuecomment-3023219879
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`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#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: ```properties 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](https://github.com/apache/logging-log4j-samples/tree/main/log4j-samples-graalvm) 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 :wink:) 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](https://github.com/oracle/graalvm-reachability-metadata) repository (enabled by default), where the Spring Boot team maintains a [`reflect-config.json`](https://github.com/oracle/graalvm-reachability-metadata/blob/master/metadata/ch.qos.logback/logback-classic/1.4.9/reflect-config.json) for Logback. * **Log4j Core**: With Log4j Core (or the [SimpleLogger](https://logging.apache.org/log4j/2.x/manual/simple-logger.html)) 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
