Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Subject: Re: Camel Transport and CXF : where to convert response Date headers
To: dev@camel.apache.org
References: <4C1FB9DC-7056-4165-A96D-F693E3E3C7D0@apache.org>
 <etPan.5422c62a.6b8b4567.10f@localhost>
 <46647C99-EB30-44CF-AFFE-F2B66813F7F3@apache.org>
 <5422CB70.7000203@gmail.com> <etPan.542357f7.6b8b4567.10e@localhost>
 <1411854681913-5757113.post@n5.nabble.com>
 <etPan.54276c18.6b8b4567.29e@dhcp-17-73.nay.redhat.com>
 <54B946A7.80206@gmail.com> <55D59883.1010705@gmail.com>
 <CAGB5yNkFo-1O=M4Du1jnUeZrsBv5ZUkj=28+n4B1P7r2oA+zEg@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <55ED6F8B.1090601@gmail.com>
Date: Mon, 7 Sep 2015 12:05:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
 <CAGB5yNkFo-1O=M4Du1jnUeZrsBv5ZUkj=28+n4B1P7r2oA+zEg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


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