search

centiservice / mats3

Mats3: Message-based Asynchronous Transactional Staged Stateless Services
https://mats3.io/
Other
63 stars 7 forks source link

Record for DTOs: Handle use of Java 14 records in DTOs #79

Closed stolsvik closed 1 year ago

stolsvik commented 1 year ago

Currently, this fails for MatsSerializerJson with the following obvious problem:

Caused by: io.mats3.serial.json.MatsSerializerJson$CannotCreateEmptyInstanceException: 
     Missing no-args constructor on class [SimpleEndpoint$DataTO].
    at io.mats3.serial.json.MatsSerializerJson.newInstance(MatsSerializerJson.java:392)
    at io.mats3.impl.jms.JmsMatsFactory.assertOkToInstantiateClass(JmsMatsFactory.java:670)

So, we'll probably have to introspect the class, using reflection (since we're on Java 8), to check if the class is a record. If so, I assume we'll just have to let it through.

One thing I do not know how to handle, is if you "strip down" the class, as is suggested when using DTO classes. I.e. the client side does not need all parameters, or the server has included a new parameter: Must we then make constructors to match?

  1. The client of an endpoint removes a field in a ReplyDTO from the endpoint (because he won't use it). The replied-with JSON will now contain a field that the constructor does not have.
  2. The endpoint itself adds a new field to the ReplyDTO. The same happens: When the client gets the reply, the JSON has an extra field.
  3. The endpoint removes a field from the ReplyDTO. Now the client side will get a reply JSON that lacks a field that it record representation has.
stolsvik commented 1 year ago

Jackson handles this just fine, but the test for instantiation did not. This is now fixed.