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/01/16 18:13:11 UTC
Few CXFRS patches
Hi All,
Happy New Year,
I've worked on creating few CXFRS patches, Willem has helped with
applying one of them (thanks).
I'd like to ask Willem or someone else who has some experience with
CXFRS to review and apply two more patches (sometime next week would be
great).
The patch at [1] fixes a minor bug where CXFRS does not support CXF
JAX-RS model resources. I'm aware a number of CXF users do use the
external models to turn non-annotated classes into JAX-RS endpoints, so
it is going be useful. Besides, I'd like to use this fix as a base for
doing an initial POC for CXFRS endpoint registering a model only, no
concrete interfaces or implementations (though I guess some default
class would have to be used internally).
The patch at [2] provides for an optional but very important improvement
which will make it much easier for CXF JAX-RS users with the existing
JAX-RS implementations migrate to Camel. It is safe, simple and as I
said, optional. As I explained at [3], this patch will let CXFRS users
route not only the request properties to the next route point but also
an existing service's response if it is possible. Example, the existing
DB query would return some object (thus no need to do it again in a
Camel processor) and then the processor would posty the response to a
queue, log, etc...
Patch to [4] is also available, but I'm thinking it may need a bit more
work, so patches to [1] and [2] is what I'd appreciate someone aplying
next week
Cheers, Sergey
[1] https://issues.apache.org/jira/browse/CAMEL-8245
[2] https://issues.apache.org/jira/browse/CAMEL-8205
[3]
https://issues.apache.org/jira/browse/CAMEL-8205?focusedCommentId=14277177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277177
[4] https://issues.apache.org/jira/browse/CAMEL-8238
Re: Few CXFRS patches
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 17/01/15 10:36, Claus Ibsen wrote:
> On Fri, Jan 16, 2015 at 6:13 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>> Hi All,
>>
>> Happy New Year,
>>
>> I've worked on creating few CXFRS patches, Willem has helped with applying
>> one of them (thanks).
>>
>> I'd like to ask Willem or someone else who has some experience with CXFRS to
>> review and apply two more patches (sometime next week would be great).
>>
>> The patch at [1] fixes a minor bug where CXFRS does not support CXF JAX-RS
>> model resources. I'm aware a number of CXF users do use the external models
>> to turn non-annotated classes into JAX-RS endpoints, so it is going be
>> useful. Besides, I'd like to use this fix as a base for doing an initial POC
>> for CXFRS endpoint registering a model only, no concrete interfaces or
>> implementations (though I guess some default class would have to be used
>> internally).
>>
>
> Would that also be possible to build a model in CXF for CXF-RS
> services? I am asking as the new rest-dsl does that. And we support a
> number of components, but not yet CXF.
>
> So if that is possible or almost possible in CXF, then IMHO it would
> be good if we could get it possible, so camel-cxf is supported with
> rest-dsl.
>
> There is a JIRA ticket
> https://issues.apache.org/jira/browse/CAMEL-7652
To be honest I'm not exactly sure why it can be interesting. As far as I
understand users chose their favorite Camel HTTP-aware components and
work with them, why combine REST DSL Component and CXFRS ? The latter
has a no less capable native support for templates/etc.
from(cxfrs).to(cxfrs) works ok.
I guess from(restdsl).to(cxfrs) can be interesting from the pure
integration point of view.
I will investigate how this can be made to work once I make some more
progress on the CXF end with respect to loosening a bit the JAX-RS
frontend's strict reliance on having a concrete interface with JAX-RS
annotations being available...
Sergey
>
>
>
>> The patch at [2] provides for an optional but very important improvement
>> which will make it much easier for CXF JAX-RS users with the existing JAX-RS
>> implementations migrate to Camel. It is safe, simple and as I said,
>> optional. As I explained at [3], this patch will let CXFRS users route not
>> only the request properties to the next route point but also an existing
>> service's response if it is possible. Example, the existing DB query would
>> return some object (thus no need to do it again in a Camel processor) and
>> then the processor would posty the response to a queue, log, etc...
>>
>> Patch to [4] is also available, but I'm thinking it may need a bit more
>> work, so patches to [1] and [2] is what I'd appreciate someone aplying next
>> week
>>
>> Cheers, Sergey
>>
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-8245
>> [2] https://issues.apache.org/jira/browse/CAMEL-8205
>> [3]
>> https://issues.apache.org/jira/browse/CAMEL-8205?focusedCommentId=14277177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277177
>> [4] https://issues.apache.org/jira/browse/CAMEL-8238
>>
>
>
>
Re: Few CXFRS patches
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jan 16, 2015 at 6:13 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi All,
>
> Happy New Year,
>
> I've worked on creating few CXFRS patches, Willem has helped with applying
> one of them (thanks).
>
> I'd like to ask Willem or someone else who has some experience with CXFRS to
> review and apply two more patches (sometime next week would be great).
>
> The patch at [1] fixes a minor bug where CXFRS does not support CXF JAX-RS
> model resources. I'm aware a number of CXF users do use the external models
> to turn non-annotated classes into JAX-RS endpoints, so it is going be
> useful. Besides, I'd like to use this fix as a base for doing an initial POC
> for CXFRS endpoint registering a model only, no concrete interfaces or
> implementations (though I guess some default class would have to be used
> internally).
>
Would that also be possible to build a model in CXF for CXF-RS
services? I am asking as the new rest-dsl does that. And we support a
number of components, but not yet CXF.
So if that is possible or almost possible in CXF, then IMHO it would
be good if we could get it possible, so camel-cxf is supported with
rest-dsl.
There is a JIRA ticket
https://issues.apache.org/jira/browse/CAMEL-7652
> The patch at [2] provides for an optional but very important improvement
> which will make it much easier for CXF JAX-RS users with the existing JAX-RS
> implementations migrate to Camel. It is safe, simple and as I said,
> optional. As I explained at [3], this patch will let CXFRS users route not
> only the request properties to the next route point but also an existing
> service's response if it is possible. Example, the existing DB query would
> return some object (thus no need to do it again in a Camel processor) and
> then the processor would posty the response to a queue, log, etc...
>
> Patch to [4] is also available, but I'm thinking it may need a bit more
> work, so patches to [1] and [2] is what I'd appreciate someone aplying next
> week
>
> Cheers, Sergey
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-8245
> [2] https://issues.apache.org/jira/browse/CAMEL-8205
> [3]
> https://issues.apache.org/jira/browse/CAMEL-8205?focusedCommentId=14277177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277177
> [4] https://issues.apache.org/jira/browse/CAMEL-8238
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
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/
Camel Transport and CXF : where to convert response Date headers
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 Wiki edit rights
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 02/03/15 12:00, Claus Ibsen wrote:
> Hi
>
> I have granted you karma.
>
Cool, thanks
Sergey
> On Mon, Mar 2, 2015 at 12:06 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>> Hi
>>
>> I'd like to edit the CXFRS wiki page, can the edit rights be set for a
>> 'sergey_beryozkin' Wiki alias please ?
>>
>> I've already signed CLA, this can be validated by checking
>> iclas.txt.
>>
>> Thanks, Sergey
>
>
>
Re: Camel Wiki edit rights
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have granted you karma.
On Mon, Mar 2, 2015 at 12:06 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> I'd like to edit the CXFRS wiki page, can the edit rights be set for a
> 'sergey_beryozkin' Wiki alias please ?
>
> I've already signed CLA, this can be validated by checking
> iclas.txt.
>
> Thanks, Sergey
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Camel Wiki edit rights
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I'd like to edit the CXFRS wiki page, can the edit rights be set for a
'sergey_beryozkin' Wiki alias please ?
I've already signed CLA, this can be validated by checking
iclas.txt.
Thanks, Sergey
Re: Few CXFRS patches
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Willem
Thanks for spending your spare time on applying these patches.
Cheers, Sergey
On 17/01/15 12:13, Willem Jiang wrote:
> Hi Sergey,
>
> I will take care of those patches this weekend.
>
> Regards,
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On January 17, 2015 at 1:14:12 AM, Sergey Beryozkin (sberyozkin@gmail.com) wrote:
>> Hi All,
>>
>> Happy New Year,
>>
>> I've worked on creating few CXFRS patches, Willem has helped with
>> applying one of them (thanks).
>>
>> I'd like to ask Willem or someone else who has some experience with
>> CXFRS to review and apply two more patches (sometime next week would be
>> great).
>>
>> The patch at [1] fixes a minor bug where CXFRS does not support CXF
>> JAX-RS model resources. I'm aware a number of CXF users do use the
>> external models to turn non-annotated classes into JAX-RS endpoints, so
>> it is going be useful. Besides, I'd like to use this fix as a base for
>> doing an initial POC for CXFRS endpoint registering a model only, no
>> concrete interfaces or implementations (though I guess some default
>> class would have to be used internally).
>>
>> The patch at [2] provides for an optional but very important improvement
>> which will make it much easier for CXF JAX-RS users with the existing
>> JAX-RS implementations migrate to Camel. It is safe, simple and as I
>> said, optional. As I explained at [3], this patch will let CXFRS users
>> route not only the request properties to the next route point but also
>> an existing service's response if it is possible. Example, the existing
>> DB query would return some object (thus no need to do it again in a
>> Camel processor) and then the processor would posty the response to a
>> queue, log, etc...
>>
>> Patch to [4] is also available, but I'm thinking it may need a bit more
>> work, so patches to [1] and [2] is what I'd appreciate someone aplying
>> next week
>>
>> Cheers, Sergey
>>
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-8245
>> [2] https://issues.apache.org/jira/browse/CAMEL-8205
>> [3]
>> https://issues.apache.org/jira/browse/CAMEL-8205?focusedCommentId=14277177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277177
>> [4] https://issues.apache.org/jira/browse/CAMEL-8238
>>
>>
>
Re: Few CXFRS patches
Posted by Willem Jiang <wi...@gmail.com>.
Hi Sergey,
I will take care of those patches this weekend.
Regards,
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On January 17, 2015 at 1:14:12 AM, Sergey Beryozkin (sberyozkin@gmail.com) wrote:
> Hi All,
>
> Happy New Year,
>
> I've worked on creating few CXFRS patches, Willem has helped with
> applying one of them (thanks).
>
> I'd like to ask Willem or someone else who has some experience with
> CXFRS to review and apply two more patches (sometime next week would be
> great).
>
> The patch at [1] fixes a minor bug where CXFRS does not support CXF
> JAX-RS model resources. I'm aware a number of CXF users do use the
> external models to turn non-annotated classes into JAX-RS endpoints, so
> it is going be useful. Besides, I'd like to use this fix as a base for
> doing an initial POC for CXFRS endpoint registering a model only, no
> concrete interfaces or implementations (though I guess some default
> class would have to be used internally).
>
> The patch at [2] provides for an optional but very important improvement
> which will make it much easier for CXF JAX-RS users with the existing
> JAX-RS implementations migrate to Camel. It is safe, simple and as I
> said, optional. As I explained at [3], this patch will let CXFRS users
> route not only the request properties to the next route point but also
> an existing service's response if it is possible. Example, the existing
> DB query would return some object (thus no need to do it again in a
> Camel processor) and then the processor would posty the response to a
> queue, log, etc...
>
> Patch to [4] is also available, but I'm thinking it may need a bit more
> work, so patches to [1] and [2] is what I'd appreciate someone aplying
> next week
>
> Cheers, Sergey
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-8245
> [2] https://issues.apache.org/jira/browse/CAMEL-8205
> [3]
> https://issues.apache.org/jira/browse/CAMEL-8205?focusedCommentId=14277177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14277177
> [4] https://issues.apache.org/jira/browse/CAMEL-8238
>
>