Provide built-in GraalVM Reachability Metadata on Seata Client 2.1.0+

[linghengqian]

Why you need it?

Is your feature request related to a problem? Please describe in details

• Provide built-in GraalVM Reachability Metadata on Seata Client 2.1.0+. The GraalVM Reachability Metadata required by Seata Client was in place on Seata Client 1.8.1 but was removed from Seata Client 2.0.0. I created https://github.com/linghengqian/seata-client-graalvm-native-test to test the Seata Client org.apache.seata:seata-all:2.1.0-SNAPSHOT on the master branch. To run the unit tests involved in this git under the GraalVM Native Image, just execute the following command. Verified under Ubuntu 22.04.4 LTS with Docker Engine and SDKMAN!.

sdk install java 22.0.1-graalce
sdk use java 22.0.1-graalce
sudo apt-get install build-essential zlib1g-dev -y

git clone [email protected]:apache/incubator-seata.git
cd ./incubator-seata/
git reset --hard 1c0a442842801413e4dc8e663c452ed18fc1dc1b
./mvnw -Prelease-seata -Dmaven.test.skip=true clean install -T1C
cd ../

git clone [email protected]:linghengqian/seata-client-graalvm-native-test.git
cd ./seata-client-graalvm-native-test/
./mvnw -PnativeTestInJunit -T1C -e clean test

• Currently, in order to use Seata Client in GraalVM Native Image, downstream projects need to add GraalVM Reachability Metadata of org.apache.seata:seata-all:2.1.0-SNAPSHOT and com.github.ben-manes.caffeine:caffeine:2.9.3 by themselves. In order to use testcontainers-java to run the Docker Container of Seata Server in unit tests, com.github.docker-java:docker-java-api:3.3.6 is also required. Reference https://github.com/linghengqian/seata-client-graalvm-native-test/tree/master/src/test/resources/META-INF/native-image .
• Since I am not sure how Seata completes the integration test of Seata Client, it would be great if Seata could build in this part of GRM's JSON file, or submit a PR with unit tests and the corresponding GRM JSON file to the GRM central repository https://github.com/oracle/graalvm-reachability-metadata. This will help simplify downstream maintenance work. If Seata side has no intention to maintain GRM content dynamically like https://github.com/apache/shardingsphere/tree/570e4934910955a2dba0a8ee416b6b05e790a830/infra/reachability-metadata/src/main/resources/META-INF/native-image , I will close the current issue to avoid maintenance costs on the Seata side.

How it could be?

A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.

• This may mean the addition of 2 Maven Profiles and 2 Maven modules, one module is responsible for defining nativeTest by bypassing mockito, and the other module is responsible for storing the automatically generated or manually modified GRM JSON. But to be honest, considering that a single Maven module can only have a single globally unique instance of Seata Client at the same time, I am not sure how to write unit tests on the Seata side. See #6614 .

Other related information

Add any other context or screenshots about the feature request here.

• Affected by https://github.com/apache/shardingsphere/issues/29052 and the slow PR review of https://github.com/oracle/graalvm-reachability-metadata, ShardingSpehre maintains the GRM of some third-party modules in order to maintain nativeTest under GraalVM Native Image. That is https://github.com/apache/shardingsphere/tree/570e4934910955a2dba0a8ee416b6b05e790a830/infra/reachability-metadata/src/main/resources/META-INF/native-image . If the GRM of Seata Client can be provided by Seata or submitted to https://github.com/oracle/graalvm-reachability-metadata , it will obviously help downstream projects reduce the workload of maintaining GRM.