Raised https://issues.apache.org/jira/browse/CAMEL-7880
BTW would the above fix work when there are multiple HTTP resources,
each with their own distinct unmarshalType? i.e. we don't want the one
resource configuration be blown away by the next one. Is this starting
to sound like a VerbDefinition-level config for jsonDataFormat?
On Tue, Sep 30, 2014 at 1:52 AM, Babak Vahdat [via Camel]
<ml-node+s465427n5757205...@n5.nabble.com> wrote:
>
>> Am 29.09.2014 um 17:39 schrieb Claus Ibsen <[hidden email]>:
>>
>> Hi
>>
>> Yeah we should likely improve the code to cater for when people use
>> custom data formats. Surely most needed for json, as jaxb is well just
>> jaxb using camel-jaxb.
>>
>> The naming should likely just be
>>
>> "json"
>> "json-out"
>> "xml"
>> "xml-out"
>>
>> so in is implied, eg so you only use -out if you really need to
>> configure it differently.
>>
>
> Yeah that naming of yours makes definitley much more sense, thanks!
>
> Sohrab, please go ahead and raise a JIRA ticket pointing to this thread in
> Nabble.
>
> Babak
>
> Sent from my iPhone...
>
>> On Mon, Sep 29, 2014 at 4:36 PM, Babak Vahdat
>> <[hidden email]> wrote:
>>> 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]
>>>> <
>>>
>>>> ml-node+s465427n5757186h47@.nabble
>>>
>>>> > 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.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: [hidden email]
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>
>
> ________________________________
> 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-tp5757103p5757205.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-tp5757103p5757213.html
Sent from the Camel - Users mailing list archive at Nabble.com.
