Hi,
sorry, looks like I forwarded the old message, I send the one recently with
https://issues.apache.org/jira/browse/CAMEL-9105?focusedCommentId=14727571&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14727571
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 <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
