You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2015/08/20 11:06:11 UTC
Camel Transport and CXF : where to convert response Date headers
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
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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
>>
>>
>
>
>
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Claus Ibsen <cl...@gmail.com>.
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 <sb...@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
>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition: http://www.manning.com/ibsen2
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
Claus, others - do you think it is a reasonable patch ? As I said - it
is now not only about a possible CXF link, and it can be applied such
that a local Date/Locale conversion is disabled by default if there's
any real concern about it.
Just seeing some JIRA updates and would rather have this patch applied
for 2.16.0 (and branches)...
Thanks, Sergey
On 02/09/15 17:27, Sergey Beryozkin wrote:
> The patch is attached and the comments are here:
>
> https://issues.apache.org/jira/browse/CAMEL-9105?focusedCommentId=14727571&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14727571
>
>
>
> Date and also Locale are converted locally by default (I know there are
> external tests that check Locale conversions to Http-centric format
> hence I copied the trivial conversion from CXF too)
>
> The local conversion is enabled by default (see proposed options related
> to it).
>
> Hope everyone will be happy with this update which will be applied once
> reviewed
>
> Sergey
> On 28/08/15 17:49, Sergey Beryozkin wrote:
>> Hi Raúl
>>
>> Great, thanks for the help, JIRA issue got updated...
>>
>> Cheers, Sergey
>> On 28/08/15 17:43, Raul Kripalani wrote:
>>> Sergey,
>>>
>>> Done.
>>>
>>> Cheers,
>>>
>>> *Raúl Kripalani*
>>> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
>>> Integration specialist
>>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>>> http://blog.raulkr.net | twitter: @raulvk
>>>
>>> On Fri, Aug 28, 2015 at 5:11 PM, Sergey Beryozkin <sb...@gmail.com>
>>> wrote:
>>>
>>>> Sorry can someone please add a new component to JIRA,
>>>> camel-http-common ? I
>>>> had to list camel-http in CAMEL-9105
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771072.html
>>>>
>>>>
>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>
>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
The patch is attached and the comments are here:
https://issues.apache.org/jira/browse/CAMEL-9105?focusedCommentId=14727571&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14727571
Date and also Locale are converted locally by default (I know there are
external tests that check Locale conversions to Http-centric format
hence I copied the trivial conversion from CXF too)
The local conversion is enabled by default (see proposed options related
to it).
Hope everyone will be happy with this update which will be applied once
reviewed
Sergey
On 28/08/15 17:49, Sergey Beryozkin wrote:
> Hi Raúl
>
> Great, thanks for the help, JIRA issue got updated...
>
> Cheers, Sergey
> On 28/08/15 17:43, Raul Kripalani wrote:
>> Sergey,
>>
>> Done.
>>
>> Cheers,
>>
>> *Raúl Kripalani*
>> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
>> Integration specialist
>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>> http://blog.raulkr.net | twitter: @raulvk
>>
>> On Fri, Aug 28, 2015 at 5:11 PM, Sergey Beryozkin <sb...@gmail.com>
>> wrote:
>>
>>> Sorry can someone please add a new component to JIRA,
>>> camel-http-common ? I
>>> had to list camel-http in CAMEL-9105
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771072.html
>>>
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Raúl
Great, thanks for the help, JIRA issue got updated...
Cheers, Sergey
On 28/08/15 17:43, Raul Kripalani wrote:
> Sergey,
>
> Done.
>
> Cheers,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Fri, Aug 28, 2015 at 5:11 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
>
>> Sorry can someone please add a new component to JIRA, camel-http-common ? I
>> had to list camel-http in CAMEL-9105
>>
>> Thanks
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771072.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Raul Kripalani <ra...@evosent.com>.
Sergey,
Done.
Cheers,
*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
On Fri, Aug 28, 2015 at 5:11 PM, Sergey Beryozkin <sb...@gmail.com>
wrote:
> Sorry can someone please add a new component to JIRA, camel-http-common ? I
> had to list camel-http in CAMEL-9105
>
> Thanks
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771072.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: Camel Transport and CXF : where to convert response Date
headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Sorry can someone please add a new component to JIRA, camel-http-common ? I
had to list camel-http in CAMEL-9105
Thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771072.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Camel Transport and CXF : where to convert response Date
headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
I've created
https://issues.apache.org/jira/browse/CAMEL-9105.
Thinking more about it, DefaultHttpDestination is the best place to get Date
(and Locale) conversions handled, as noted though the existing code where
global TypeConverters are used would still work.
I'll create a patch next week and then hopefully it will be accepted and
CAMEL-9091 will be invalidated.
Sergey
--
View this message in context: http://camel.465427.n5.nabble.com/Re-2-3-git-commit-CAMEL-7856-camel-cxf-producer-HttpAPI-should-not-send-the-message-body-when-using-d-tp5756960p5771071.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
> 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/