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

fsi0uk1n  于 4个月前  发布在  其他
关注(0)|答案(3)|浏览(65)

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

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 .

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

8iwquhpp

8iwquhpp1#

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.

9w11ddsr

9w11ddsr2#

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.
lsmepo6l

lsmepo6l3#

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!

相关问题