Support to use application-fury in resteasy

[zhfeng]

This will support to use application/fury as a mediatype and de(serialize) objects over the HTTP connections.

see testFuryBar() method.

[zhfeng]

@chaokunyang can you take a look at the native test failure. It seems that Bar and ThirdPartyBar has the same record

int f1, string f2

In JVM mode, it is deserialized into Bar but in native mode, it is into ThirdPartyBar.

2024-11-13 07:54:17,672 ERROR [org.jbo.res.res.i18n] (executor-thread-1) RESTEASY002005: Failed executing GET /fury/test: org.jboss.resteasy.spi.InternalServerErrorException: RESTEASY003020: Bad arguments passed to public io.quarkiverse.fury.it.Bar io.quarkiverse.fury.it.FuryResources.testBar(io.quarkiverse.fury.it.Bar)  ( io.quarkiverse.fury.it.ThirdPartyBar ThirdPartyBar[f1=1, f2=hello bar] )

[zhfeng]

@chaokunyang if there two class have the same fields, like

class A {
    int a;
    String b;
}

class B {
    int a;
    String b;
}

It should be serialze into the same bytes, right? during deserilzing, how `fury` can detect which class type should be used?

[chaokunyang]

Fury generated codec is cached into a global map, maybe they have a conflict. When creating ThreadSafeFury, we could a different name by FuryBuilder#withName to avoid cache conflict.

[chaokunyang]

Maybe We could Set name to timestamp for tests

[zhfeng]

Hmm, another found that Bar and ThirdPartyBar looks like use the very similar custom Serializer. BarSerializer and ThridPartyBarSerializer. Is that a problem?

public class BarSerializer extends Serializer<Bar> {
    public BarSerializer(Fury fury, Class<Bar> type) {
        super(fury, type);
    }

    @Override
    public void write(MemoryBuffer buffer, Bar value) {
        buffer.writeVarInt32(value.f1());
        fury.writeJavaString(buffer, value.f2());
    }

    @Override
    public Bar read(MemoryBuffer buffer) {
        return new Bar(buffer.readVarInt32(), fury.readJavaString(buffer));
    }
}

[chaokunyang]

Why not add @Inject here

[zhfeng]

Ha, it shoudl work. Let me try.

[zhfeng]

No, it does not work. Because resteasy will init the providers at static_init time where the bean container is not running. We have to retrieve BaseFury at runtime. see

• Remove the SerializerProducer because resteasy init the providers at … #29

[chaokunyang]

Hmm, another found that Bar and ThirdPartyBar looks like use the very similar custom Serializer. BarSerializer and ThridPartyBarSerializer. Is that a problem?

They are all caused by cache conflict, I fixed it in #27

[zhfeng]

OK, I will check with your fix. Thanks a lot!

[zhfeng]

Sorry @chaokunyang - your fix looks not working!

[chaokunyang]

We can't write code like this, the serialization and deserialization should have same class registration order. If you register Bar here, it allocate an ID x for Bar, but the server allocate id x for ThirdPartyBar. This is why it fails. You could update like this:

@FurySerialization(classId=200)
class Bar {
...
}
fury.register(Bar.class, 200);

[zhfeng]

Yeah, that's the root cause. Thanks a lot @chaokunyang ! Should we need a NOTE in the documentation or refer to the Apache Fury docs?

[chaokunyang]

Yeah, would you like submit a pr?

[zhfeng]

You mean a PR for Fury?