zjsonpatch | This is an implementation of RFC 6902 JSON Patch | JSON Processing library

I did a some googling and little research. I foud following:

1. The missing class com.azure.data.cosmos.internal.directconnectivity.rntbd.RntbdConstants$RntbdContextRequestHeader is a part of azure-cosmosdb-direct, pls see pom.xml, class is located here.
2. azure-cosmosdb-direct is missing from your dependency list. I assume it's incomplete or hidden for some reason(?)
3. Looking at exception stacktrace it's clear that at com.azure.data.cosmos.internal.directconnectivity.rntbd.RntbdContextRequest$Headers.(RntbdContextRequest.java:126) is a place where exceptiom occurs. So that means RntbdContextRequest class actually existsts (it's also is a part of azure-cosmosdb-direct). Therefore you have needed dependency, but it probably has wrong version.

I propose you to look a bit deeper into how azure-cosmosdb-direct dependency is injected in your project and fix its version. Just try to declare it directly in your pom.xml with the latest version.

Hope I helped you.

Looking at the dependency tree, I can see that there is a mix-up of SDK dependencies of version 2 and 3 in your project which is causing the issue.

The dependency entries with groupId starting with com.sap.cloud.s4hana are mostly v2 dependencies and the ones with groupId starting with com.sap.cloud.sdk are v3 dependencies.So, please use this as a reference to convert all v2 dependencies to the corresponding v3 dependencies.

Alternatively, you can also include the sdk-bom dependency (groupId: com.sap.cloud.sdk, artifactId: sdk-bom ) in your pom with a version, so that you can start including other sdk dependencies without explicitly including the version information. This would also ensure that all the sdk dependencies you include would always fall into the a particular version:

Since you're using Jetty you should be adding spring-cloud-starter-contract-stub-runner-jetty - that way the started WireMock will use the proper container.

Basically, the problem is the fact that the data binding is not done by FasterXML but by Spring Expression Context. So adding the jackson-datatype-jsr310 will not help at all. The FasterXML will be only used if the patch value is object or an array. But in your case, the patch value is string type so JsonPatchPatchConverter will try to convert values using purely Spring tools (Spring Expression Context). So what now you are missing is the String to Instant converter for a Spring Framework. I'm quite sure that there are some implementations available and even maybe some are within the Spring libraries, but I will create here a simple one and show how you can register it. Initially, let's create a converter (Not the best implementation, just for proof of concept).