camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Camel Transport and CXF : where to convert response Date headers
Date Mon, 07 Sep 2015 11:05:47 GMT

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 <sberyozkin@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
>>
>>
>
>
>


Mime
View raw message