Small correction: not having native json support in java (is this 2021? :D) in might be best to still use Jackson, but in a more native way where we don’t work with annotations for the generated classes
Sebastian > Am 21.04.2021 um 10:36 schrieb Sebastian Rühl > <[email protected]>: > > Talking about Jackson, this can be soon be replaced with our native generated > implementation. > In Golang xml/json is already ported, in java only xml for now. > When I’m done with that we have full control over the serialization which > then is language agnostic and dictated by what is defined in mspec. > (e.g. if mspec defines that the element is byte[] or byte then it will be > generated as such (hex) across every language. For debugging purposes you can > look at my box rendering which contains every representation [hex, natural, > possible string on hex dump]. At the moment I haven’t ported it to java yet) > > Sebastian > >> Am 21.04.2021 um 10:27 schrieb Łukasz Dywicki <[email protected]>: >> >> Looking at very core of the issue with byte type representation (at >> least in XML suits) I believe it was affected by mapping to/from Java. >> Jackson has its own ways handling such payloads. >> We really should map suites according to mspec and keep values in tests >> according to their "canonical" representation. Without pinning it to any >> particular language. >> As far I remember we currently map byte[] payloads to hex strings, but >> sometimes such representation is helpful also for digits. Earlier we had >> base64 for byte arrays which did make it pretty hard to debug tests. If >> we could map single bytes to hex that also would be great cause turning >> it into digit by Jackson is not very helpful. >> >> Best, >> Łukasz >
