Allow pluggable marshallers

[purplefox]

Generated proxies currently always encode/decode the request/response to/from JSON.

This is nice and interoperable and allows services to be easily called by just sending messages directly on the event bus, but it is not necessarily very efficient.

We should abstract out the marshalling code and allow it to be pluggable. So that, for example an efficient binary encoding can be used (or whatever), if the user prefers that.

[msavy]

I wonder if it might even be possible to make this play nicely with Google's Protocol-Buffers - that would be very exciting because it can generate an optimised binary format for a given input/output (and generate the marshalling/unmarshalling code). Possibly too complicated to implement for the short term. I think this could be big performance win for Vert.x.

See also:

• https://github.com/google/protobuf
• https://developers.google.com/protocol-buffers/
• https://developers.google.com/protocol-buffers/docs/overview

[purplefox]

+1 no reason why any particular marshalling implementation couldn't use google protobufs if it liked

[jebbench]

Has there been any progress on this? I'd like to use Jackson for marshaling my DataObjects but with the exception of the toJson method this seems quite tricky to implement currently.

[vietj]

no progress so far as nobody has contributed or planned to contribute this feature yet

[diliuskh]

Hi. I was able to use service-proxy with kotlin data classes marked with @DataObject using kryo library. There were some workarounds required to pull it off. vertx-codegen requires implementation of JsonObject toJson()(ProxyModel class in codegen checks for this method, so couldn't get rid of it) method for data objects. So the method was moved to common interface with default method implementation that uses io.vertx.core.json.Json.mapper.convertValue internally. The public constructor with JsonObject argument required by DataObjectModel class in codegen and is used in .templ files in vertx-service-proxy. Skipping data object proccessing during compilation solves one problem and adding modified versions of .templ files + customized ProxyHandler and implementation of MessageCodec solves the other.

[diliuskh]

Perhaps adding new annotation with usage something along the lines @ProxySerializable(MyMessageCodec.class) would be a good start and keeping @DataObject as is forbackward compatibility.

[stephanebastian]

Hello, I am interested in this topic and may contribute something once I fully understand what need to be done. Right now, we already have the interface MessageCodec<S, R> to send arbitrary Pojo to/from the event bus. Therefore I am puzzled as to what we need to do:

• Is the goal to modify the code currently generated by the service-proxy to use a MessageCodec ? (Right now we mandate a DataObject class to define a constructor that takes a JsonObject as well as a method toJson())
• Or is the goal to define a different interface than MessageCodec to abstract out the (un)marshalling ?

My opinion at that time is that it would make sens to always use a MessageCodec to send arbitrary Pojo (including DataObject) to/from the event bus. Any take on this ?

[vietj]

@stephanebastian agree we should define properly the goals and non goals of this issue

[vietj]

I think the original goal is performance

[vietj]

I think that the encoding would be done externally, concerning the constructor, I think we would use the empty constructor when it's available otherwise the json constructor with an empty object

[vietj]

perhaps we can look at the event bus interceptors to implement this

[vietj]

perhaps the one thing is to define a target efficient codec for POJO that we can use and see how it can be used

[vietj]

with interceptor : basically the code would just set the object on the message and the interceptor would take care of encoding/decoding it to/from a buffer

[vietj]

btw : what I'm saying are just thoughts out loud :-)

[InfoSec812]

Hmmm.... This has been sitting for a while, but I wanted to add a use case.. For an application I am writing, the user will be uploading large files (Photos/Videos) and I would prefer to use ServiceProxy to keep the code simple to understand and modular. It would be great if we could just pass Buffer as a type to a Service Proxy method. Then the user can implement the decoding of that Buffer however they like.

[eutkin]

Hello. This is an example MessageCodec for an event bus for serializing an array of arguments. But there is one nuance. Event Bus does not provide information about registered user codecs.

ObjectArrayCodec

[eutkin]

https://github.com/eclipse-vertx/vert.x/pull/2966

supporting me, please :)

[slinkydeveloper]

I close as it's solved by new JsonCodecs in vertx-codegen

[pjeziorowski]

Hello, please re-open the issue as JsonCodec does not solve the underlying problem

Also, this one seems like a duplicate / is closely related #8

[mohamnag]

not sure about the JsonCodec but I would also see this option. I would even like to have an option of not serializing the message body at all. This is very useful for local only services to remove any overhead of serialization.