You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2022/11/14 14:43:52 UTC

[GitHub] [shardingsphere] linghengqian commented on issue #21347: Make ShardingSphere Proxy in GraalVM Native Image form available

linghengqian commented on issue #21347:
URL: https://github.com/apache/shardingsphere/issues/21347#issuecomment-1313864347

   > - It looks like https://github.com/oracle/graalvm-reachability-metadata/issues/50 explains the issues related to `Log4j2`.  Pending https://issues.apache.org/jira/browse/LOG4J2-2649 .  This seems to require us to force-pull the Log4j2 version in the native profile to `3.0.0-SNAPSHOT`.  Should I say using SNAPSHOT is a weird behavior?
   > 
   > - It just looks like log4j2's `3.0.0-SNAPSHOT` completely removes stuff related to `java.lang.invoke.LambdaMetafactory`, the graalvm team almost doesn't want to support such usage at all, which involves `SecurityManager`.  I assume that I should be able to find a simple operation in the native profile of the shardingsphere to specify the version of all the passed log4j2 dependencies to `3.0.0-SNAPSHOT`, and also remove the log4j1 from the upstream dependencies, and finally https://github.com/oracle/graalvm-reachability-metadata/issues/50 can be reopened and the metadata of log4j2 can be added. However, I am quite depressed how ShardingSphere CI Log can see a hamcrest related class when building GraalVM Native Image  warning, the test library is not in the final product.
   
   - Hopefully https://github.com/oracle/graalvm-reachability-metadata/pull/108 will remove the warning related to Log4j2.


-- 
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-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org