You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2019/07/02 07:23:00 UTC
[jira] [Updated] (LOG4J2-2604) Generate reflect-config.json for
GraalVM during annotation processing
[ https://issues.apache.org/jira/browse/LOG4J2-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Remko Popma updated LOG4J2-2604:
--------------------------------
Description:
See [https://github.com/oracle/graal/issues/1209] and [https://github.com/oracle/graal/issues/808]
Currently log4j2 cannot be used in GraalVM native images because it uses reflection.
Graal SubstrateVM can [deal with reflection|https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md] when it’s clear to the AOT compiler what classes, methods and fields are reflected on. The log4j plugin mechanism is too dynamic for the automatic reflection analysis.
This can be solved by providing a {{reflect-config.json}} configuration file, which may be embedded in the jar under {{META-INF/native-image/some/path/}}.
The annotation processor is the natural place to generate this configuration file, so that applications that provide custom Log4j components will have the necessary {{META-INF/org/apache/logging/log4j/core/config/plugins/reflect-config.json}} to accompany their {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in their jar.
It may be convenient to provide a (separate?) tool for generating a {{reflect-config.json}} configuration file from the {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in any jar. The main usage of this tool is to be invoked by the Log4j annotation processor, so applications that have this annotation processor configured correctly _don't need to do anything_: their jar will automatically contain the configuration needed for enable reflective access in a GraalVM native image. (Separating the tool from the annotation processor just gives extra flexibility.)
was:
See [https://github.com/oracle/graal/issues/1209] and [https://github.com/oracle/graal/issues/808]
Currently log4j2 cannot be used in GraalVM native images because it uses reflection.
Graal SubstrateVM can [deal with reflection|https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md] when it’s clear to the AOT compiler what classes, methods and fields are reflected on. The log4j plugin mechanism is too dynamic for the automatic reflection analysis.
This can be solved by providing a {{reflect-config.json}} configuration file, which may be embedded in the jar under {{META-INF/native-image/some/path/}}.
The annotation processor is the natural place to generate this configuration file, so that applications that provide custom Log4j components will have the necessary {{META-INF/org/apache/logging/log4j/core/config/plugins/reflect-config.json}} to accompany their {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in their jar.
It may be convenient to provide a (separate?) tool for generating a {{reflect-config.json}} configuration file from the {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in any jar.
> Generate reflect-config.json for GraalVM during annotation processing
> ---------------------------------------------------------------------
>
> Key: LOG4J2-2604
> URL: https://issues.apache.org/jira/browse/LOG4J2-2604
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configurators
> Reporter: Remko Popma
> Priority: Major
>
> See [https://github.com/oracle/graal/issues/1209] and [https://github.com/oracle/graal/issues/808]
> Currently log4j2 cannot be used in GraalVM native images because it uses reflection.
> Graal SubstrateVM can [deal with reflection|https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md] when it’s clear to the AOT compiler what classes, methods and fields are reflected on. The log4j plugin mechanism is too dynamic for the automatic reflection analysis.
> This can be solved by providing a {{reflect-config.json}} configuration file, which may be embedded in the jar under {{META-INF/native-image/some/path/}}.
> The annotation processor is the natural place to generate this configuration file, so that applications that provide custom Log4j components will have the necessary {{META-INF/org/apache/logging/log4j/core/config/plugins/reflect-config.json}} to accompany their {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in their jar.
> It may be convenient to provide a (separate?) tool for generating a {{reflect-config.json}} configuration file from the {{META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat}} file in any jar. The main usage of this tool is to be invoked by the Log4j annotation processor, so applications that have this annotation processor configured correctly _don't need to do anything_: their jar will automatically contain the configuration needed for enable reflective access in a GraalVM native image. (Separating the tool from the annotation processor just gives extra flexibility.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)