Description
Simplify Java DSL access to the data mapping payload builders (ObjectMappingPayloadBuilder and MarshallingPayloadBuilder).
At the moment, for JSON payload object mapping the user needs to instantiate the class with new in the body() method:
.body(new ObjectMappingPayloadBuilder(new TodoEntry(uuid, "${todoName}", "${todoDescription}"), objectMapper))
Or the test uses a static import of the JsonSupport marshal method (org.citrusframework.json.dsl.JsonSupport#marshal(Object, ObjectMapper)):
import static org.citrusframework.json.dsl.JsonSupport.marshal;
.body(marshal(new TodoEntry(uuid, "${todoName}", "${todoDescription}"), objectMapper))
For XML marshalling the user may instantiate the class:
.body(new MarshallingPayloadBuilder(new TodoEntry(uuid, "${todoName}", "${todoDescription}"), marshaller))
Or use the static import import static org.citrusframework.xml.message.builder.MarshallingPayloadBuilder.Builder.marshal;.
This is inconsistent and users need to know a lot of the implementation details.
Missing XmlSupport static marshal methods
org.citrusframework.xml.dsl.XmlSupport does not have the same static marshal entry methods as org.citrusframework.json.dsl.JsonSupport. For consistency reasons, XmlSupport should provide equivalent static marshal methods so that users have a uniform API regardless of the data format.
Expected Behavior
Add object mapping/marshalling options to the org.citrusframework.dsl.TestActionSupport interface, similar to how it is done with processors. The user should have a single point of entry to all Java DSL capabilities without needing to know implementation details.
We need to find a good entry to the API for building payloads with payload builder options. One approach is to incorporate the mapping/marshalling payload builder options into the processor API. As a result the user may just import the TestActionSupport interface and use:
.body(builder().json().marshal(new TodoEntry(uuid, "${todoName}", "${todoDescription}"), objectMapper))
or
.body(processor().json().marshal(new TodoEntry(uuid, "${todoName}", "${todoDescription}"), objectMapper))
Additional Context
JSON and XML marshalling is only one option to begin with. Other payload builder implementations such as GroovyScriptPayloadBuilder or BinaryPayloadBuilder might follow.
Description
Simplify Java DSL access to the data mapping payload builders (
ObjectMappingPayloadBuilderandMarshallingPayloadBuilder).At the moment, for JSON payload object mapping the user needs to instantiate the class with
newin thebody()method:Or the test uses a static import of the
JsonSupportmarshal method (org.citrusframework.json.dsl.JsonSupport#marshal(Object, ObjectMapper)):For XML marshalling the user may instantiate the class:
Or use the static import
import static org.citrusframework.xml.message.builder.MarshallingPayloadBuilder.Builder.marshal;.This is inconsistent and users need to know a lot of the implementation details.
Missing XmlSupport static marshal methods
org.citrusframework.xml.dsl.XmlSupportdoes not have the same static marshal entry methods asorg.citrusframework.json.dsl.JsonSupport. For consistency reasons,XmlSupportshould provide equivalent staticmarshalmethods so that users have a uniform API regardless of the data format.Expected Behavior
Add object mapping/marshalling options to the
org.citrusframework.dsl.TestActionSupportinterface, similar to how it is done with processors. The user should have a single point of entry to all Java DSL capabilities without needing to know implementation details.We need to find a good entry to the API for building payloads with payload builder options. One approach is to incorporate the mapping/marshalling payload builder options into the processor API. As a result the user may just import the
TestActionSupportinterface and use:or
Additional Context
JSON and XML marshalling is only one option to begin with. Other payload builder implementations such as
GroovyScriptPayloadBuilderorBinaryPayloadBuildermight follow.