[
https://issues.apache.org/jira/browse/LOG4J2-2604?focusedWorklogId=305823&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-305823
]
ASF GitHub Bot logged work on LOG4J2-2604:
------------------------------------------
Author: ASF GitHub Bot
Created on: 03/Sep/19 19:48
Start Date: 03/Sep/19 19:48
Worklog Time Spent: 10m
Work Description: jvz commented on issue #291: [LOG4J2-2604/2649] Change
MethodHandle to Constructor to adapt graalvm
URL: https://github.com/apache/logging-log4j2/pull/291#issuecomment-527610864
Ugh, and the API for MethodHandle is so much nicer than the reflection API
for these sorts of things. Does the JVM optimize calls to `Method.invoke()` to
work the same as `MethodHandle.invoke()`? If that's the case, then we could
avoid using that API. Otherwise, I was looking at using `MethodHandle` far more
in an update to the plugin system for 3.0, and if there's good reason to avoid
that, I'd like to know now rather than later.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 305823)
Time Spent: 1h 10m (was: 1h)
> 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
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 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/native-image/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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
