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.
The link to [1] https://issues.apache.org/jira/browse/CAMEL-9091 was left out...
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
-- Sergey Beryozkin Talend Community Coders http://coders.talend.com/
