make it mutually compatible

I think it's easier to maintain another package than to maintain compatibility.

1. The old package can be deleted at any time
2. Use the same package and rename it in the future. (If not renamed, the package name is inconsistent with the internal serialization protocol.)

make it mutually compatible

I think it's easier to maintain another package than to maintain compatibility.

1. The old package can be deleted at any time
2. Use the same package and rename it in the future. (If not renamed, the package name is inconsistent with the internal serialization protocol.)

I don't think so, because these two things are the same thing, there's no need to distinguish them, and compatibility is not an issue. Fastjson and fastjson2 are differentiated because early fastjson2 had incompatibility problems with fastjson, so they were distinguished. However, fury and fory don't have this problem at all - it's just like io.seata being changed to org.apache.seata. It should maintain backward compatibility. You can have fury directly reference fory's implementation, so both are directly compatible, because whenever fury serialization is called, it will actually use fory serialization.

I don't think so, because these two things are the same thing

If I follow your idea, I will first load org.apache.fory.Fory, and if successful, run it according to Fory. If the class cannot be found, try to load org.apache.fury.Fury.

No more new modules, still in the original modules seata-serializer-fury.

Is this OK?

I don't think so, because these two things are the same thing

If I follow your idea, I will first load org.apache.fory.Fory, and if successful, run it according to Fory. If the class cannot be found, try to load org.apache.fury.Fury.

No more new modules, still in the original modules seata-serializer-fury.

Is this OK?

I don't think this is necessary, because fory is just fury. As long as there's no fory dependency, just prompt the user to upgrade the dependency to fory, and describe the upgrade from fury to fory in the changelog so users can switch dependencies.

I don't think this is necessary, because fory is just fury.

OK.

describe the upgrade from fury to fory in the changelog so users can switch dependencies.

Will this package always be called seata-serializer-fury?

I don't think this is necessary, because fory is just fury.

OK.

describe the upgrade from fury to fory in the changelog so users can switch dependencies.

Will this package always be called seata-serializer-fury?

I think we should keep the seata-serializer-fury module, then have seata-serializer-fury depend on the seata-serializer-fory module, move the code logic from fury to the fory module, and add functionality to the fury module to check whether the fory dependency exists.

I think we should keep the seata-serializer-fury module, then have seata-serializer-fury depend on the seata-serializer-fory module

This is fine for now, but it will be confusing after fury is removed.

I think we should keep the seata-serializer-fury module, then have seata-serializer-fury depend on the seata-serializer-fory module

This is fine for now, but it will be confusing after fury is removed.

The Fury serialization feature is only available in recent versions, so there probably aren’t many users. Also, it’s just a matter of changing a dependency, so I don’t think it will have much impact.

the necessary security test cases

I read the test code of other serialization frameworks, and except for Hessian, the tests are basically the same.

Could you give some examples or explain it in detail?

the necessary security test cases

I read the test code of other serialization frameworks, and except for Hessian, the tests are basically the same.

Could you give some examples or explain it in detail?

https://github.com/apache/incubator-seata/pull/7501/files

The serialization framework should support a whitelist. Most security vulnerabilities are caused by unsafe deserialization. Serialization outside the whitelist should throw exceptions. When adding a whitelist, it is necessary to ensure that the overall transaction function is normal.

https://github.com/apache/incubator-seata/pull/7501/files

The serialization framework should support a whitelist.

OK, let me study it. And then add the security test cases.

In the seata-serializer-fury module, make it compatible with fory. In addition, add a module: seata-serializer-fory.

@funky-eyes What do you think of this solution?