camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel Transport and CXF : where to convert response Date headers
Date Mon, 07 Sep 2015 10:48:36 GMT

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]

Claus Ibsen
----------------- @davsclaus
Camel in Action 2nd edition:

View raw message