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
