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 git@github.com:apache/incubator-seata.git
cd ./incubator-seata/
git reset --hard 1c0a442842801413e4dc8e663c452ed18fc1dc1b
./mvnw -Prelease-seata -Dmaven.test.skip=true clean install -T1C
cd ../

git clone git@github.com: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 Seata Multi-Client Optimization #6614 .

Other related information

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

• Affected by Improve GraalVM Reachability Metadata and corresponding nativeTest related unit tests shardingsphere#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.

[wangliang181230]

See #5234

Due to my recent busy work schedule, I don't have time to resolve a large number of conflicts. If someone could continue to maintain this PR, or create a new PR, that would be a great thing.

[linghengqian]

See #5234

Due to my recent busy work schedule, I don't have time to resolve a large number of conflicts. If someone could continue to maintain this PR, or create a new PR, that would be a great thing.

• Thanks for the clarification. I actually never used Spring Framework's own annotations to register GRM, because using Java API instead of JSON to define GRM part violates the portability promise made by OracleLabs on the GraalVM CE side, and I'm afraid I can't help much in the refactoring of the relevant PR.

[funky-eyes]

See #5234
Due to my recent busy work schedule, I don't have time to resolve a large number of conflicts. If someone could continue to maintain this PR, or create a new PR, that would be a great thing.

• Thanks for the clarification. I actually never used Spring Framework's own annotations to register GRM, because using Java API instead of JSON to define GRM part violates the portability promise made by OracleLabs on the GraalVM CE side, and I'm afraid I can't help much in the refactoring of the relevant PR.

I suggest that you can use tracing agent to achieve your goal. Currently we don't have manpower to invest in this feature. If any other community member is interested in this feature and could provide related PRs, I would appreciate it a lot!