Prompt unable to find class: io/protostuff/runtime/IdStrategy

[Alleninggx]

• [x ] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

Prompt unable to find class: io/protostuff/runtime/IdStrategy
提示无法找到类 io/protostuff/runtime/IdStrategy

2024-03-14 18:37:11.980 WARN 13280 --- [ ] ServiceLoader$InnerEnhancedServiceLoader : Load [io.seata.rm.datasource.undo.parser.ProtostuffUndoLogParser] class fail: io/protostuff/runtime/IdStrategy

full log：

2024-03-14 18:37:11.459  INFO 13280 --- [               ] io.seata.tm.TransactionManagerHolder     : TransactionManager Singleton io.seata.tm.DefaultTransactionManager@29c5683e
2024-03-14 18:37:11.470  INFO 13280 --- [               ] i.seata.tm.api.DefaultGlobalTransaction  : Begin new global transaction [10.0.30.203:8091:72553274548374422]
2024-03-14 18:37:11.502 DEBUG 13280 --- [               ] c.l.m.s.s.mapper.OrgMapper.updateById    : <==    Updates: 1
2024-03-14 18:37:11.503 DEBUG 13280 --- [               ] c.l.m.s.s.mapper.DeptMapper.editBatch    : ==>  Preparing: UPDATE ~~~
2024-03-14 18:37:11.720 DEBUG 13280 --- [               ] c.l.m.s.s.mapper.DeptMapper.editBatch    : ==> Parameters: ~~~
2024-03-14 18:37:11.902  INFO 13280 --- [               ] io.seata.rm.AbstractResourceManager      : branch register success, xid:10.0.30.203:8091:72553274548374422, branchId:72553274548374423, lockKeys:dept:135,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,160
2024-03-14 18:37:11.980  WARN 13280 --- [               ] ServiceLoader$InnerEnhancedServiceLoader : Load [io.seata.rm.datasource.undo.parser.ProtostuffUndoLogParser] class fail: io/protostuff/runtime/IdStrategy
2024-03-14 18:37:12.173 DEBUG 13280 --- [               ] c.l.m.s.s.mapper.DeptMapper.editBatch    : <==    Updates: 1
2024-03-14 18:37:12.173  INFO 13280 --- [               ] i.seata.tm.api.DefaultGlobalTransaction  : transaction 10.0.30.203:8091:72553274548374422 will be commit
2024-03-14 18:37:12.179  INFO 13280 --- [               ] i.seata.tm.api.DefaultGlobalTransaction  : transaction end, xid = 10.0.30.203:8091:72553274548374422
2024-03-14 18:37:12.179  INFO 13280 --- [               ] i.seata.tm.api.DefaultGlobalTransaction  : [10.0.30.203:8091:72553274548374422] commit status: Committed
2024-03-14 18:37:12.957  INFO 13280 --- [h_RMROLE_1_1_32] i.s.c.r.p.c.RmBranchCommitProcessor      : rm client handle branch commit process:BranchCommitRequest{xid='10.0.30.203:8091:72553274548374422', branchId=72553274548374423, branchType=AT, resourceId='jdbc:mysql://MES-MYSQL-SERVER:3306/mes', applicationData='null'}
2024-03-14 18:37:12.958  INFO 13280 --- [h_RMROLE_1_1_32] io.seata.rm.AbstractRMHandler            : Branch committing: 10.0.30.203:8091:72553274548374422 72553274548374423 jdbc:mysql://MES-MYSQL-SERVER:3306/mes null
2024-03-14 18:37:12.959  INFO 13280 --- [h_RMROLE_1_1_32] io.seata.rm.AbstractRMHandler            : Branch commit result: PhaseTwo_Committed

Ⅱ. Ⅲ. Ⅳ. Ⅴ.

ignore

Ⅵ. Environment:

• JDK version(e.g. java -version): openjdk-21.0.2
• Seata client/server version: spring-cloud-starter-alibaba-seata:2023.0.0.0-RC1
• Database version: MySQL (ver. 8.0.28)
• OS(e.g. uname -a): Win11

[funkye]

Please check if you are missing relevant dependencies

[Alleninggx]

Shouldn't this be a dependency that seata includes?

[funkye]

这个只是undolog的一个序列化方式，默认使用的是jackson，启动的时候会尝试将已有的undologparser全部加载，加载不到的说明没有相关依赖，只要你不使用该加载失败的序列化方式就没有任何影响
This is just a serialization method of undolog. The default is jackson. When starting, it will try to load all the existing undologparser. If it cannot be loaded, it means that there is no dependency. As long as you do not use the serialization method of loading failed, it will have no effect.

[Alleninggx]

能否详细说说“不使用该加载失败的序列化方式”
Can you elaborate on “do not use the serialization method of loading failed”

[funkye]

https://seata.apache.org/zh-cn/docs/user/configurations/
如果你没将client.undo.logSerialization 设置成protobuf，那么你不需要关心这个问题，如果你设置成了protobuf，必须手动引入该protobuf的依赖，因为seata不强依赖protobuf，这个序列化方式是可选的，seata只保证默认的序列化对应的依赖被引入
If you don't set client.undo.logSerialization to protobuf, then you don't need to care about this problem. If you set it to protobuf, you must manually introduce the dependency of the protobuf, because seata does not have strong dependency protobuf, this serialization method is optional, seata only guarantees that the default serialization corresponding dependency is introduced

[Alleninggx]

上述问题了解了。
另外，在RPC中，我有使用到dubbo(tri协议)和grpc，是否也可以使用默认序列化方式即可？
I understand the above question.
Also, In RPC, I have used dubbo(tri protocol) and grpc, can I also use the default serialization method?