Yeah I see your point. BTW the same shortcoming is also given for the case where binding is XML and not Json, which's the JAXB dataformat being currently supported. So I guess in cases likes yours we need to differentiate the DataFormats for the incomming/outgoing playloads, let’s say something like:
"json-in" "json-out" "xml-in" "xml-out" @Claus how to you see this? Does this make sense to you? Babak sohrab wrote > Thanks for the explanation, Babak. > > I think I see a flaw with this which will break anytime someone uses a > custom DataFormat in REST DSL. > > Say I define a custom JacksonDataFormat in the registry (quite a > common thing to do especially if you want to enable/disable config on > ObjectMapper) and point to it in RestConfiguration.jsonDataFormat. > > As you said if it's not the default "json-jackson", those two lines > will return the same object which will then get configured twice, with > "outJson" config blowing away any config "json" made previously. > > I just replicated this with a small example where REST DSL will reject > incoming request if it doesn't have the response structure(!). Should > I raise this in JIRA? > > On Mon, Sep 29, 2014 at 8:33 PM, Babak Vahdat [via Camel] > < > [email protected] > > wrote: >> Hi, >> >> The "json" and "outJson" variables you mentioned will *not* resolve to >> the >> same Java object (because of Camel Injector being invoked here behind the >> scenes while resolving), well almost always ... depending if e.g. an >> object >> under the name "json-jackson" is already bound to the Camel registery >> which >> isn't really typical. The following code snippet should make both cases >> clear to you: >> >> CamelContext context = new DefaultCamelContext(); >> >> DataFormat first = context.resolveDataFormat("json-jackson"); >> DataFormat second = context.resolveDataFormat("json-jackson"); >> >> System.out.println(first != second); // true >> >> JndiRegistry registry = new JndiRegistry(); >> registry.bind("json-jackson", new >> org.apache.camel.component.jackson.JacksonDataFormat()); >> ((DefaultCamelContext) context).setRegistry(registry); >> >> DataFormat third = context.resolveDataFormat("json-jackson"); >> DataFormat fourth = context.resolveDataFormat("json-jackson"); >> >> System.out.println(third == fourth); // true >> >> System.out.println(third != first); // true >> System.out.println(fourth != first); // true >> >> If interested, looking into the different implementations of Camel’s >> DataFormatResolver should clarify this to you, specially the >> DefaultDataFormatResolver one. >> >> Babak >> >> sohrab wrote >> I was just looking through the latest code for >> org.apache.camel.model.rest.RestBindingDefinition and I am not quite sure >> how this works so I'd appreciate if someone can explain it to me. >> >> createProcessor() method looks up both JSON data formats using the same >> name: >> >> DataFormat json = context.resolveDataFormat(name); >> DataFormat outJson = context.resolveDataFormat(name); >> >> And further down, it sets the properties for "json" and then "outJson". >> Now >> I am wondering if that name resolves to the same DataFormat object >> (especially when you have RestConfiguration.jsonDataFormat set), what >> stops >> setting "outJson" properties, such as unmarshalType, not overriding the >> properties we just set for "json"? >> >> >> >> ________________________________ >> If you reply to this email, your message will be added to the discussion >> below: >> http://camel.465427.n5.nabble.com/RestBindingProcessor-JSON-Data-Format-Config-tp5757103p5757186.html >> To unsubscribe from RestBindingProcessor JSON Data Format Config, click >> here. >> NAML -- View this message in context: http://camel.465427.n5.nabble.com/RestBindingProcessor-JSON-Data-Format-Config-tp5757103p5757201.html Sent from the Camel - Users mailing list archive at Nabble.com.
