Customizing De/Serialization

[workmanw]

Versions: Open Search 2.19 Java SDK

Describe the issue:

I’m looking for guidance on how best to customize the record serialization and deserialization. I’m also trying to ultimately understand from the maintainers the vision of how JsonP and Jackson will evolve in the SDK so that I can be sure our usage is correct and isn’t broken with the next major upgrade.

---

I have a few pretty common use cases.

1. Snake case serialization (instead of Jackson’s default camel)
2. I need null’s always serialized
3. I need to custom attribute names in my mapping that differ from the model
4. I need a custom deserialize for at least one attribute.

All of those are pretty common Jackson use cases. I don’t think the existing JsonP implementation would be right for them, does that sound fair?

I’m tempted to simply instantiate my customer ObjectMapper when doing my client construction. For example:

val mapper = JacksonJsonpMapper(myCustomObjectMapper)

val awsSdk2Transport = AwsSdk2Transport(
   httpClient,
   host,
   serviceName,
   currentRegion,
   AwsSdk2TransportOptions
     .builder()
     .setMapper(mapper)
     .build()
)

This feels like the right approach, but after looking through all the docs, the guide/json.md and even the issues and PRs, I couldn’t get a clear sense of if this is right or wrong.

My other concern is that I didn’t want my mapper alterations to impact the internals of the SDK. It appears that it mostly uses it’s JsonP implementation and this wouldn’t be the case, but it was still a concern not being spelled out.

---

EDIT: One other solution we have explored is trying to always deserialize source records to a JSON string (from a query) and handle deserialization manually. The old high-level SDK made this much easier because it support XCONTENT configuration options. I had explored doing this with JsonP but felt like I was implementing a brittle solution.

[reta]

Hi @workmanw ,

I could only reply from OpenSearch Java Client perspective, not AWS SDK one.

• the Jsonb and Jackson are just two implementations of JsonpMapper that we provide out of the box (basically you could use any that implements Jakarta Json-P specs)
• using JacksonJsonpMapper with customizations that you need is totally fine - as far as the OpenSearch server side accepts the requests and the client side accepts the responses)

For any AWS SDK related questions, please consult [1] for the right channels.
Thank you.

[1] GitHub - aws/aws-sdk-java-v2: The official AWS SDK for Java - Version 2

[workmanw]

Hey @reta ,

Thanks for the response. Apologies for not clarifying, but I was only asking about the OpenSearch Java SDK, not anything AWS specific (even though I had a code snippet).

I think you answered my question well enough, I really just wanted to make sure that there wasn’t a plan to phase out Jackson from the code base and we wouldn’t get into trouble by relying on custom Jackson serialization in 2.x only to find it was removed in 3.x or 4.x some day.