You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ralf Steppacher <ra...@derivativepartners.com> on 2013/01/15 12:01:12 UTC
Re: RESTful route with Apache CXF
Sergey,
sorry for the extremely delayed response!
What you suggest would work for me. Though it would be nice if the steps
"restore" and "complete" were implicitly invoked. But I know way too
little about the internal workings of Camel and the route construction
to suggest that this was possible.
Thanks for your help!
Ralf
-----Original Message-----
From: Sergey Beryozkin <sb...@gmail.com>
Reply-to: users@camel.apache.org
To: users@camel.apache.org
Subject: Re: RESTful route with Apache CXF
Date: Wed, 03 Oct 2012 20:43:18 +0100
Sorry for a noise,
I think the route below is not exactly correct, should be something
along these lines:
<route>
<from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
<!-- this is invokes a jaxrs bean -->
<to uri="direct:HelloWorldRestServerEndpoint"/>
<!-- this method will just get the cached object back into Exchange -->
<to uri="bean://jaxbProvider?method=restore"/>
<!-- now do whatever is needed with the bean returned from the service -->
<!-- finally write to the output stream -->
<to uri="bean://jaxbProvider?method=complete"/>
</route>
The 'bean:' parts of the routes can be most likely optimized with a
custom Processor, and the object properties can be updated on the
provider in case the intermediate parts of the roots somehow enrich or
change the object properties.
The provider itself can be written to delegate to JAX-RS Providers to
make sure it is not bound to XML/JAXB only....
Sergey
On 03/10/12 17:29, Sergey Beryozkin wrote:
> Ralf,
>
> I experimented a bit with the idea of using a two-stage JAX-RS message
> body writer, that seems to work, here is a prototype.
>
> Context:
>
> <bean id="jaxbProvider" class="server.CachingJAXBProvider"/>
>
> <jaxrs:server id="hello_rest"
> address="camel://direct:HelloWorldRestServerEndpoint">
> <jaxrs:serviceBeans>
> <ref bean="hello-world-bean"/>
> </jaxrs:serviceBeans>
> <jaxrs:providers>
> <ref bean="jaxbProvider"/>
> </jaxrs:providers>
> </jaxrs:server>
>
> <bean id="hello-world-bean" class="server.HelloWorldImpl"/>
>
> <camelContext id="camelContext"
> xmlns="http://camel.apache.org/schema/spring" trace="false">
> <route>
> <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
> <!-- this is invokes a jaxrs bean -->
> <to uri="direct:HelloWorldRestServerEndpoint"/>
> <!-- do whatever is needed with the bean returned from the service -->
>
> <!-- write to the output stream -->
> <to uri="bean://jaxbProvider?method=complete"/>
> </route>
> </camelContext>
>
> Provider:
>
> public class CachingJAXBProvider<T> extends JAXBElementProvider<T> {
>
> private T object;
> private Class<?> cls;
> private Type genericType;
> private Annotation[] anns;
> private MediaType m;
> private MultivaluedMap<String, Object> headers;
> private CacheAndWriteOutputStream os;
>
> @Override
> public void writeTo(T obj, Class<?> cls, Type genericType, Annotation[]
> anns,
> MediaType m, MultivaluedMap<String, Object> headers, OutputStream os) {
> this.object = obj;
> this.cls = cls;
> this.genericType = genericType;
> this.anns = anns;
> this.m = m;
> this.headers = headers;
> this.os = new
> CacheAndWriteOutputStream(((CacheAndWriteOutputStream)os).getFlowThroughStream());
>
> }
>
> public Object complete(Object obj) throws IOException {
> super.writeTo(object, cls, genericType, anns, m, headers, os);
> return os.getOut();
> }
>
> }
>
>
> This actually works, I think it looks a bit hacky and I wonder if a
> utility provider like this one can be utilized internally and hidden
> somehow. However I'm quite positive about the fact the process can
> definitely be controlled - I'd like play with JAX-RS 2.0 AsyncResponse
> later on.
>
> When we have oneway invocations, then it is a different scenario.
> Also Christian wrote a demo showing how a custom listener is injected
> into a JAX-RS service bean and then another route starts from this
> listener being notified
>
> Sergey
>
>
> On 03/10/12 12:23, Sergey Beryozkin wrote:
>> Actually, here is the slightly updated code from one of the tests which
>> Willem did:
>>
>> protected RouteBuilder createRouteBuilder() throws Exception {
>> return new RouteBuilder() {
>> public void configure() {
>> final ResponseBuilder builder = Response.ok();
>>
>> from(CXF_RS_ENDPOINT_URI)
>> // should be able to convert to Customer
>> .convertBodyTo(Customer.class)
>> .to("mock:result")
>> // respond with OK
>> .transform(constant(builder.entity(***new Customer()***).build()));
>> };
>> };
>> }
>>
>> Note the cxfrs server endpoint accepts the request, the response object
>> is run through the route and finally it can be set on the builder to do
>> the marshalling done and the response returned.
>>
>> The only thing I could not figure out quickly enough was how to actually
>> get hold of this response object :-)
>>
>> Cheers, Sergey
>>
>>
>> On 01/10/12 11:38, Sergey Beryozkin wrote:
>>> Hi Ralf
>>> On 01/10/12 07:50, Ralf Steppacher wrote:
>>>> Willam,
>>>>
>>>> thanks for the hint. I shall look into camel-cxfrs.
>>>>
>>>> Could you give me a usage example of the cxfbean component? What would
>>>> be a scenario where immediate marshalling to the client-requested
>>>> format
>>>> is desired? Is the idea that all work necessary to produce a meaningful
>>>> response is done in the resource class and the route only consists of
>>>> the cxfbean endpoint?
>>>>
>>>
>>> When you have a JAX-RS annotated bean with @Produces, it is not really
>>> possible to 'delay' marshalling of the response object.
>>>
>>> I think something interesting in this regard can also done with the new
>>> JAX-RS 2.0 AsyncResponse: say at the top of the route the JAX-RS request
>>> is accepted, suspended and resumed at some later stage (the end of the
>>> route). This just a theory at the moment though, not sure how it will
>>> can be coordinated with the Camel thread running the whole route
>>>
>>> Perhaps one working option is to register a custom JAX-RS
>>> MessageBodyReader which will simply cache the response object in its
>>> writeTo method and then at the end of the route this provider will be
>>> asked to 'flush' the response. Will it work for you ?
>>>
>>> Sergey
>>>>
>>>> Thanks!
>>>> Ralf
>>>>
>>>> -----Original Message-----
>>>> From: Willem jiang<wi...@gmail.com>
>>>> Reply-to: users@camel.apache.org
>>>> To: users@camel.apache.org
>>>> Subject: Re: RESTful route with Apache CXF
>>>> Date: Thu, 27 Sep 2012 15:56:17 +0800
>>>>
>>>> Hi Ralf,
>>>>
>>>> I think you use misused the cxfbean component.
>>>> cxfbean component is trying to leverage the camel components to
>>>> provides different transports.
>>>>
>>>> It will marshal and unmarshal the request and response out of box.
>>>>
>>>> What's you need is camel-cxfrs[1] component, you should be able to get
>>>> the Java object of PriceReuqestMessage from the message body.
>>>>
>>>> [1]http://camel.apache.org/cxfrs.html
>>>>
>>>
>>>
Re: RESTful route with Apache CXF
Posted by Ralf Steppacher <ra...@derivativepartners.com>.
OK. Thanks again!
Ralf
-----Original Message-----
From: Sergey Beryozkin <sb...@gmail.com>
Reply-to: users@camel.apache.org
To: users@camel.apache.org
Subject: Re: RESTful route with Apache CXF
Date: Tue, 15 Jan 2013 11:11:37 +0000
Hi Ralf
On 15/01/13 11:01, Ralf Steppacher wrote:
> Sergey,
>
> sorry for the extremely delayed response!
np, better later than never :-),
> What you suggest would work for me. Though it would be nice if the steps
> "restore" and "complete" were implicitly invoked. But I know way too
> little about the internal workings of Camel and the route construction
> to suggest that this was possible.
Well, I have to do some homework too and get a better appreciation, but
I guess this all can be hidden somehow with custom processors of the
individual route steps.
By the way, if you were to go for it, custom MBW does not need to cast
to CXF specific output stream, it was my initial experiment really.
Cheers, Sergey
>
>
> Thanks for your help!
> Ralf
>
>
> -----Original Message-----
> From: Sergey Beryozkin<sb...@gmail.com>
> Reply-to: users@camel.apache.org
> To: users@camel.apache.org
> Subject: Re: RESTful route with Apache CXF
> Date: Wed, 03 Oct 2012 20:43:18 +0100
>
> Sorry for a noise,
>
> I think the route below is not exactly correct, should be something
> along these lines:
>
> <route>
> <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
> <!-- this is invokes a jaxrs bean -->
> <to uri="direct:HelloWorldRestServerEndpoint"/>
>
> <!-- this method will just get the cached object back into Exchange -->
> <to uri="bean://jaxbProvider?method=restore"/>
>
> <!-- now do whatever is needed with the bean returned from the service -->
>
> <!-- finally write to the output stream -->
> <to uri="bean://jaxbProvider?method=complete"/>
> </route>
>
> The 'bean:' parts of the routes can be most likely optimized with a
> custom Processor, and the object properties can be updated on the
> provider in case the intermediate parts of the roots somehow enrich or
> change the object properties.
>
> The provider itself can be written to delegate to JAX-RS Providers to
> make sure it is not bound to XML/JAXB only....
>
> Sergey
>
>
>
> On 03/10/12 17:29, Sergey Beryozkin wrote:
>> Ralf,
>>
>> I experimented a bit with the idea of using a two-stage JAX-RS message
>> body writer, that seems to work, here is a prototype.
>>
>> Context:
>>
>> <bean id="jaxbProvider" class="server.CachingJAXBProvider"/>
>>
>> <jaxrs:server id="hello_rest"
>> address="camel://direct:HelloWorldRestServerEndpoint">
>> <jaxrs:serviceBeans>
>> <ref bean="hello-world-bean"/>
>> </jaxrs:serviceBeans>
>> <jaxrs:providers>
>> <ref bean="jaxbProvider"/>
>> </jaxrs:providers>
>> </jaxrs:server>
>>
>> <bean id="hello-world-bean" class="server.HelloWorldImpl"/>
>>
>> <camelContext id="camelContext"
>> xmlns="http://camel.apache.org/schema/spring" trace="false">
>> <route>
>> <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
>> <!-- this is invokes a jaxrs bean -->
>> <to uri="direct:HelloWorldRestServerEndpoint"/>
>> <!-- do whatever is needed with the bean returned from the service -->
>>
>> <!-- write to the output stream -->
>> <to uri="bean://jaxbProvider?method=complete"/>
>> </route>
>> </camelContext>
>>
>> Provider:
>>
>> public class CachingJAXBProvider<T> extends JAXBElementProvider<T> {
>>
>> private T object;
>> private Class<?> cls;
>> private Type genericType;
>> private Annotation[] anns;
>> private MediaType m;
>> private MultivaluedMap<String, Object> headers;
>> private CacheAndWriteOutputStream os;
>>
>> @Override
>> public void writeTo(T obj, Class<?> cls, Type genericType, Annotation[]
>> anns,
>> MediaType m, MultivaluedMap<String, Object> headers, OutputStream os) {
>> this.object = obj;
>> this.cls = cls;
>> this.genericType = genericType;
>> this.anns = anns;
>> this.m = m;
>> this.headers = headers;
>> this.os = new
>> CacheAndWriteOutputStream(((CacheAndWriteOutputStream)os).getFlowThroughStream());
>>
>> }
>>
>> public Object complete(Object obj) throws IOException {
>> super.writeTo(object, cls, genericType, anns, m, headers, os);
>> return os.getOut();
>> }
>>
>> }
>>
>>
>> This actually works, I think it looks a bit hacky and I wonder if a
>> utility provider like this one can be utilized internally and hidden
>> somehow. However I'm quite positive about the fact the process can
>> definitely be controlled - I'd like play with JAX-RS 2.0 AsyncResponse
>> later on.
>>
>> When we have oneway invocations, then it is a different scenario.
>> Also Christian wrote a demo showing how a custom listener is injected
>> into a JAX-RS service bean and then another route starts from this
>> listener being notified
>>
>> Sergey
>>
>>
>> On 03/10/12 12:23, Sergey Beryozkin wrote:
>>> Actually, here is the slightly updated code from one of the tests which
>>> Willem did:
>>>
>>> protected RouteBuilder createRouteBuilder() throws Exception {
>>> return new RouteBuilder() {
>>> public void configure() {
>>> final ResponseBuilder builder = Response.ok();
>>>
>>> from(CXF_RS_ENDPOINT_URI)
>>> // should be able to convert to Customer
>>> .convertBodyTo(Customer.class)
>>> .to("mock:result")
>>> // respond with OK
>>> .transform(constant(builder.entity(***new Customer()***).build()));
>>> };
>>> };
>>> }
>>>
>>> Note the cxfrs server endpoint accepts the request, the response object
>>> is run through the route and finally it can be set on the builder to do
>>> the marshalling done and the response returned.
>>>
>>> The only thing I could not figure out quickly enough was how to actually
>>> get hold of this response object :-)
>>>
>>> Cheers, Sergey
>>>
>>>
>>> On 01/10/12 11:38, Sergey Beryozkin wrote:
>>>> Hi Ralf
>>>> On 01/10/12 07:50, Ralf Steppacher wrote:
>>>>> Willam,
>>>>>
>>>>> thanks for the hint. I shall look into camel-cxfrs.
>>>>>
>>>>> Could you give me a usage example of the cxfbean component? What would
>>>>> be a scenario where immediate marshalling to the client-requested
>>>>> format
>>>>> is desired? Is the idea that all work necessary to produce a meaningful
>>>>> response is done in the resource class and the route only consists of
>>>>> the cxfbean endpoint?
>>>>>
>>>>
>>>> When you have a JAX-RS annotated bean with @Produces, it is not really
>>>> possible to 'delay' marshalling of the response object.
>>>>
>>>> I think something interesting in this regard can also done with the new
>>>> JAX-RS 2.0 AsyncResponse: say at the top of the route the JAX-RS request
>>>> is accepted, suspended and resumed at some later stage (the end of the
>>>> route). This just a theory at the moment though, not sure how it will
>>>> can be coordinated with the Camel thread running the whole route
>>>>
>>>> Perhaps one working option is to register a custom JAX-RS
>>>> MessageBodyReader which will simply cache the response object in its
>>>> writeTo method and then at the end of the route this provider will be
>>>> asked to 'flush' the response. Will it work for you ?
>>>>
>>>> Sergey
>>>>>
>>>>> Thanks!
>>>>> Ralf
>>>>>
>>>>> -----Original Message-----
>>>>> From: Willem jiang<wi...@gmail.com>
>>>>> Reply-to: users@camel.apache.org
>>>>> To: users@camel.apache.org
>>>>> Subject: Re: RESTful route with Apache CXF
>>>>> Date: Thu, 27 Sep 2012 15:56:17 +0800
>>>>>
>>>>> Hi Ralf,
>>>>>
>>>>> I think you use misused the cxfbean component.
>>>>> cxfbean component is trying to leverage the camel components to
>>>>> provides different transports.
>>>>>
>>>>> It will marshal and unmarshal the request and response out of box.
>>>>>
>>>>> What's you need is camel-cxfrs[1] component, you should be able to get
>>>>> the Java object of PriceReuqestMessage from the message body.
>>>>>
>>>>> [1]http://camel.apache.org/cxfrs.html
>>>>>
>>>>
>>>>
>
>
Re: RESTful route with Apache CXF
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ralf
On 15/01/13 11:01, Ralf Steppacher wrote:
> Sergey,
>
> sorry for the extremely delayed response!
np, better later than never :-),
> What you suggest would work for me. Though it would be nice if the steps
> "restore" and "complete" were implicitly invoked. But I know way too
> little about the internal workings of Camel and the route construction
> to suggest that this was possible.
Well, I have to do some homework too and get a better appreciation, but
I guess this all can be hidden somehow with custom processors of the
individual route steps.
By the way, if you were to go for it, custom MBW does not need to cast
to CXF specific output stream, it was my initial experiment really.
Cheers, Sergey
>
>
> Thanks for your help!
> Ralf
>
>
> -----Original Message-----
> From: Sergey Beryozkin<sb...@gmail.com>
> Reply-to: users@camel.apache.org
> To: users@camel.apache.org
> Subject: Re: RESTful route with Apache CXF
> Date: Wed, 03 Oct 2012 20:43:18 +0100
>
> Sorry for a noise,
>
> I think the route below is not exactly correct, should be something
> along these lines:
>
> <route>
> <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
> <!-- this is invokes a jaxrs bean -->
> <to uri="direct:HelloWorldRestServerEndpoint"/>
>
> <!-- this method will just get the cached object back into Exchange -->
> <to uri="bean://jaxbProvider?method=restore"/>
>
> <!-- now do whatever is needed with the bean returned from the service -->
>
> <!-- finally write to the output stream -->
> <to uri="bean://jaxbProvider?method=complete"/>
> </route>
>
> The 'bean:' parts of the routes can be most likely optimized with a
> custom Processor, and the object properties can be updated on the
> provider in case the intermediate parts of the roots somehow enrich or
> change the object properties.
>
> The provider itself can be written to delegate to JAX-RS Providers to
> make sure it is not bound to XML/JAXB only....
>
> Sergey
>
>
>
> On 03/10/12 17:29, Sergey Beryozkin wrote:
>> Ralf,
>>
>> I experimented a bit with the idea of using a two-stage JAX-RS message
>> body writer, that seems to work, here is a prototype.
>>
>> Context:
>>
>> <bean id="jaxbProvider" class="server.CachingJAXBProvider"/>
>>
>> <jaxrs:server id="hello_rest"
>> address="camel://direct:HelloWorldRestServerEndpoint">
>> <jaxrs:serviceBeans>
>> <ref bean="hello-world-bean"/>
>> </jaxrs:serviceBeans>
>> <jaxrs:providers>
>> <ref bean="jaxbProvider"/>
>> </jaxrs:providers>
>> </jaxrs:server>
>>
>> <bean id="hello-world-bean" class="server.HelloWorldImpl"/>
>>
>> <camelContext id="camelContext"
>> xmlns="http://camel.apache.org/schema/spring" trace="false">
>> <route>
>> <from uri="servlet:///HelloWorld?matchOnUriPrefix=true"/>
>> <!-- this is invokes a jaxrs bean -->
>> <to uri="direct:HelloWorldRestServerEndpoint"/>
>> <!-- do whatever is needed with the bean returned from the service -->
>>
>> <!-- write to the output stream -->
>> <to uri="bean://jaxbProvider?method=complete"/>
>> </route>
>> </camelContext>
>>
>> Provider:
>>
>> public class CachingJAXBProvider<T> extends JAXBElementProvider<T> {
>>
>> private T object;
>> private Class<?> cls;
>> private Type genericType;
>> private Annotation[] anns;
>> private MediaType m;
>> private MultivaluedMap<String, Object> headers;
>> private CacheAndWriteOutputStream os;
>>
>> @Override
>> public void writeTo(T obj, Class<?> cls, Type genericType, Annotation[]
>> anns,
>> MediaType m, MultivaluedMap<String, Object> headers, OutputStream os) {
>> this.object = obj;
>> this.cls = cls;
>> this.genericType = genericType;
>> this.anns = anns;
>> this.m = m;
>> this.headers = headers;
>> this.os = new
>> CacheAndWriteOutputStream(((CacheAndWriteOutputStream)os).getFlowThroughStream());
>>
>> }
>>
>> public Object complete(Object obj) throws IOException {
>> super.writeTo(object, cls, genericType, anns, m, headers, os);
>> return os.getOut();
>> }
>>
>> }
>>
>>
>> This actually works, I think it looks a bit hacky and I wonder if a
>> utility provider like this one can be utilized internally and hidden
>> somehow. However I'm quite positive about the fact the process can
>> definitely be controlled - I'd like play with JAX-RS 2.0 AsyncResponse
>> later on.
>>
>> When we have oneway invocations, then it is a different scenario.
>> Also Christian wrote a demo showing how a custom listener is injected
>> into a JAX-RS service bean and then another route starts from this
>> listener being notified
>>
>> Sergey
>>
>>
>> On 03/10/12 12:23, Sergey Beryozkin wrote:
>>> Actually, here is the slightly updated code from one of the tests which
>>> Willem did:
>>>
>>> protected RouteBuilder createRouteBuilder() throws Exception {
>>> return new RouteBuilder() {
>>> public void configure() {
>>> final ResponseBuilder builder = Response.ok();
>>>
>>> from(CXF_RS_ENDPOINT_URI)
>>> // should be able to convert to Customer
>>> .convertBodyTo(Customer.class)
>>> .to("mock:result")
>>> // respond with OK
>>> .transform(constant(builder.entity(***new Customer()***).build()));
>>> };
>>> };
>>> }
>>>
>>> Note the cxfrs server endpoint accepts the request, the response object
>>> is run through the route and finally it can be set on the builder to do
>>> the marshalling done and the response returned.
>>>
>>> The only thing I could not figure out quickly enough was how to actually
>>> get hold of this response object :-)
>>>
>>> Cheers, Sergey
>>>
>>>
>>> On 01/10/12 11:38, Sergey Beryozkin wrote:
>>>> Hi Ralf
>>>> On 01/10/12 07:50, Ralf Steppacher wrote:
>>>>> Willam,
>>>>>
>>>>> thanks for the hint. I shall look into camel-cxfrs.
>>>>>
>>>>> Could you give me a usage example of the cxfbean component? What would
>>>>> be a scenario where immediate marshalling to the client-requested
>>>>> format
>>>>> is desired? Is the idea that all work necessary to produce a meaningful
>>>>> response is done in the resource class and the route only consists of
>>>>> the cxfbean endpoint?
>>>>>
>>>>
>>>> When you have a JAX-RS annotated bean with @Produces, it is not really
>>>> possible to 'delay' marshalling of the response object.
>>>>
>>>> I think something interesting in this regard can also done with the new
>>>> JAX-RS 2.0 AsyncResponse: say at the top of the route the JAX-RS request
>>>> is accepted, suspended and resumed at some later stage (the end of the
>>>> route). This just a theory at the moment though, not sure how it will
>>>> can be coordinated with the Camel thread running the whole route
>>>>
>>>> Perhaps one working option is to register a custom JAX-RS
>>>> MessageBodyReader which will simply cache the response object in its
>>>> writeTo method and then at the end of the route this provider will be
>>>> asked to 'flush' the response. Will it work for you ?
>>>>
>>>> Sergey
>>>>>
>>>>> Thanks!
>>>>> Ralf
>>>>>
>>>>> -----Original Message-----
>>>>> From: Willem jiang<wi...@gmail.com>
>>>>> Reply-to: users@camel.apache.org
>>>>> To: users@camel.apache.org
>>>>> Subject: Re: RESTful route with Apache CXF
>>>>> Date: Thu, 27 Sep 2012 15:56:17 +0800
>>>>>
>>>>> Hi Ralf,
>>>>>
>>>>> I think you use misused the cxfbean component.
>>>>> cxfbean component is trying to leverage the camel components to
>>>>> provides different transports.
>>>>>
>>>>> It will marshal and unmarshal the request and response out of box.
>>>>>
>>>>> What's you need is camel-cxfrs[1] component, you should be able to get
>>>>> the Java object of PriceReuqestMessage from the message body.
>>>>>
>>>>> [1]http://camel.apache.org/cxfrs.html
>>>>>
>>>>
>>>>
>
>