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 <sberyoz...@gmail.com> 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] https://issues.apache.org/jira/browse/CAMEL-9091 > > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2nd edition: http://www.manning.com/ibsen2
