camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Camel Transport and CXF : where to convert response Date headers
Date Mon, 07 Sep 2015 11:05:47 GMT


sorry, looks like I forwarded the old message, I send the one recently with

CAMEL-9105 has a patch and CAMEL-9091 I linked to below is already 
closed as a duplicate.

I noted in CAMEL-9105 that the patch converts Date/Locale locally by 
default - this can be restricted to 2.16.0 only if preferred or disabled 
by default - just a matter of changing a default value to 'false' (see 
the patch) everywhere or only on the non-trunk branches.

Have a look please
Cheers, Sergey

On 07/09/15 11:48, Claus Ibsen wrote:
> Hi
> Yeah sure it sounds reasonable to convert java.util.Date headers to a
> HTTP friendly string representation in the general http binding. You
> are imho welcome to work on a patch for that.
> Mind that on master branch there is a camel-http-common module, where
> the binding is.
> On Thu, Aug 20, 2015 at 11:06 AM, Sergey Beryozkin <> wrote:
>> Hi All
>> In CXF the response headers which have java.util.Date values converted at
>> the HTTP transport level into HTTP-friendly representations.
>> When CXF (JAX-RS) endpoints are integrated into Camel routes using Camel
>> Transport, example:
>>     <jaxrs:server id="hello_rest"
>> address="camel://direct:HelloWorldRestServerEndpoint">
>>          <!-- -->
>>      </jaxrs:server>
>>    <camelContext>
>>          <route>
>>              <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
>>              <to uri="direct:HelloWorldRestServerEndpoint"/>
>>          </route>
>>   </camelContext>
>> the response Date headers, if available, get converted to String by the
>> global Camel type converter at the DefaultHttpBinding (camel http common)
>> level.
>> I opened with a patch attached. The idea there is that Date headers coming
>> out of CXF get converted to HTTP format Strings at the Camel to/from CXF
>> integration level.
>> I think there might be a bit of sensitivity associated with such a fix, as
>> one can imagine a non-HTTP consumer that links to CXF via Camel Transport.
>> I.e, the question is what if, when a CXF response header contains a Date
>> instance, the default Date.toString() is desired ?
>> I think it is somewhat unlikely however, assuming the patch [1] gets
>> accepted, the following options are available to CXF services which are
>> linked to with Camel Transport:
>> - do Date.toString() at the CXF level - the simplest option
>> - the patch [1] introduces a Camel exchange property that would let Date
>> headers propagated unchanged back to Camel
>> I think this is reasonable and covers all the variations.
>> However if someone thinks this is not perfect then the alternative is to
>> drop [1] but re-implement a similar solution at DefaultHttpBinding level:
>> - if it is a response header with a Date value then convert it inside
>> DefaultHttpBinding to the HTTP friendly format - it is difficult to imagine
>> why a non-HTTP format would be required at the point of returning Dates to
>> the external HTTP clients.
>> - Add the option to let users delegate Date to String conversions to Camel
>> to the type converters if really needed
>> To summarize I think a patch at [1] offers a flexible solution for users
>> doing a Camel CXF integration with Camel transport.
>> If it is not accepted then I can do a patch against DefaultHttpBinding as
>> suggested above - perhaps that can be useful to non-CXF users too
>> Let me know please
>> Sergey
>> [1]

View raw message