Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

camel_case
Needing to confirm, with cxfrs you can't use the same url and have the REST application choose the proper route based on the http method POST GET PUT DELETE.  With rest dsl you can because the method is part of the route, you have something like rest(url).get(etc
I tried to cheat by dividing the same route between the route class and resource class but it didn't work.  Meaning I had route 1
from("cxfrs://http://somecompany.com:8080/pathsegment1/pathsegment2/").
and route 2
from("cxfrs://http://somecompany.com:8080/pathsegment1/").
and then in the resource file I had
@GET
String dummyMeth1(){return null;}
and
@GET
@Path("pathsegment2?{myQueryParam}")
String dummyMeth2(@QueryParam(myQueryParam) String queryParam) ){return null;}

but this didn't work either.  The concept of calling the same url/uri for a service and having it apply the proper service method based on the http method type is not part of the cxfrs framework.  It must find a matching http method in the resource file, but it can't pick the route based on http method.  Of course it can't I assume, the resource file methods are separated from the route, so picking of the route is done before checking the resource file for a matching method.  Rest dsl as in rest(url).get ties the method to the route instead.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

camel_case
I see that with performInvocation, it's possible to get the same effect, but only by giving up the idea and convenience of different routes.  You may use one route and have the resource file invoke the method according to the http method, (replacing "return null" with a call to a service I presume).  This feature is new to Camel 2.15 released March 2015.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
In reply to this post by camel_case
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
In reply to this post by camel_case
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

camel_case
Yes, thanks, I was referring the interface, though I was using a resource class instead with return nulls.
I think I now have a couple of options, I think I could also get the http method from the exchange and pass to the recipient list, just as the operationName is used though operationName gives finer grain control perhaps.  
Also it's possible to use choice, though I don't see the advantage over the direct:$operationName call
except easier to have default route I guess.
https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/Web_Services_and_Routing_with_Camel_CXF/files/Pojo-OpName.html
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Sergey Beryozkin
In reply to this post by camel_case
Hi

Usually users register custom route processors, with CXFRS interface
only acting as a matcher, with the route processors checking next the
matched verb, etc, and deciding what to do. With latest Camel this
process can be simplified - JAX-RS contexts such as UriInfo,
SecurityContext, Request are available as typed exchange properties to
custom processors after the match has happened.

Retuning null with CXF is not really needed any more, it can be simply
an interface.

'performInvocation' is useful if you have an existing JAX-RS
implementation and you'd like it do some work and then continue
processing the response in the camel routes, as opposed to CXFRS
interfaces acting as the matchers only.

Finally, I did may be 70% of work needed for CXFRS being able to support
REST DSL routes but unfortunately not able to prioritize right now due
to being involved in a high priority project, but committed to getting
it completed sooner rather than later...

Sergey

On 09/02/16 22:30, camel_case wrote:

> I see that with performInvocation, it's possible to get the same effect, but
> only by giving up the idea and convenience of different routes.  You may use
> one route and have the resource file invoke the method according to the http
> method, (replacing "return null" with a call to a service I presume).  This
> feature is new to Camel 2.15 released March 2015.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777495.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

camel_case
performInvocation allows you to use the resource file to match http method type (GET POST PUT DELETE) to a method in the resource file.  However, it wipes out the Exchange headers and body, and the return value is set to the Exchange.In body, except when null is returned.  There doesn't seem to be a way to access the exchange, In or Out, headers or body, get or set, inside the resource method.  One does have access to @PathParam or @QueryParam that appear in the method signature params which could then be set in the body, are returned to the route, passed in the Exchange.  The method can call a service and return values to the calling route in the inBody.

Alternatively, one can direct the cxfrs routes according to http method by using recipient list as in

 .recipientList(simple("direct:${header.CamelHttpMethod}"));

In either case, one could then use the same target url ( as in http://mycompany.com/callrestservice?myparam=12 and the route finds the service restfully according to the http method.  
With the recipientList trick, the routes are set up with endpoints start direct:GET direct:POST direct:PUT direct:DELETE
With peformInvocation, each resource method can call an appropriate service.

Furthermore, two identical url requests distinguished only by use of pathParam vs. queryParam or even the name of the param, can be routed, with a further refinement of recipientList trick or if statement in resource method, or .choice( in route.

This routing style is actually built in to the rest dsl as in rest(url).get etc.

It is difficult to find debate over cxfrs vs rest dsl (avail only since Fall 2015)
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Sergey Beryozkin
In reply to this post by camel_case
I don't quite follow what are you saying about performInvocation,
there's a simple test, with the processor coded as follows:

https://github.com/apache/camel/blob/master/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/jaxrs/CxfRsConsumerTest.java#L276

Are you trying to use it with CXFRS using an interface/no-op imlpl ? May
be I need to tighten the code to make sure 'performInvocation' is
ignored in such cases...

Sergey
On 10/02/16 21:51, camel_case wrote:

> performInvocation allows you to use the resource file to match http method
> type (GET POST PUT DELETE) to a method in the resource file.  However, it
> wipes out the Exchange headers and body, and the return value is set to the
> Exchange.In body, except when null is returned.  There doesn't seem to be a
> way to access the exchange, In or Out, headers or body, get or set, inside
> the resource method.  One does have access to @PathParam or @QueryParam that
> appear in the method signature params which could then be set in the body,
> are returned to the route, passed in the Exchange.  The method can call a
> service and return values to the calling route in the inBody.
>
> Alternatively, one can direct the cxfrs routes according to http method by
> using recipient list as in
>
>   .recipientList(simple("direct:${header.CamelHttpMethod}"));
>
> In either case, one could then use the same target url ( as in
> http://mycompany.com/callrestservice?myparam=12 and the route finds the
> service restfully according to the http method.
> With the recipientList trick, the routes are set up with endpoints start
> direct:GET direct:POST direct:PUT direct:DELETE
> With peformInvocation, each resource method can call an appropriate service.
>
> Furthermore, two identical url requests distinguished only by use of
> pathParam vs. queryParam or even the name of the param, can be routed, with
> a further refinement of recipientList trick or if statement in resource
> method, or .choice( in route.
>
> This routing style is actually built in to the rest dsl as in rest(url).get
> etc.
>
> It is difficult to find debate over cxfrs vs rest dsl (avail only since Fall
> 2015)
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777554.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Sergey Beryozkin
Sorry, that was a link to the processor working with JAX-RS contexts,

this one is doing something that a JAX-RS service has returned as a
result of 'performInvocation', in this case it is a Customer bean:

https://github.com/apache/camel/blob/master/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/jaxrs/CxfRsSpringConsumerTest.java#L48

May be it is off-topic, sorry for the noise if so...
Sergey


On 10/02/16 22:16, Sergey Beryozkin wrote:

> I don't quite follow what are you saying about performInvocation,
> there's a simple test, with the processor coded as follows:
>
> https://github.com/apache/camel/blob/master/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/jaxrs/CxfRsConsumerTest.java#L276
>
>
> Are you trying to use it with CXFRS using an interface/no-op imlpl ? May
> be I need to tighten the code to make sure 'performInvocation' is
> ignored in such cases...
>
> Sergey
> On 10/02/16 21:51, camel_case wrote:
>> performInvocation allows you to use the resource file to match http
>> method
>> type (GET POST PUT DELETE) to a method in the resource file.  However, it
>> wipes out the Exchange headers and body, and the return value is set
>> to the
>> Exchange.In body, except when null is returned.  There doesn't seem to
>> be a
>> way to access the exchange, In or Out, headers or body, get or set,
>> inside
>> the resource method.  One does have access to @PathParam or
>> @QueryParam that
>> appear in the method signature params which could then be set in the
>> body,
>> are returned to the route, passed in the Exchange.  The method can call a
>> service and return values to the calling route in the inBody.
>>
>> Alternatively, one can direct the cxfrs routes according to http
>> method by
>> using recipient list as in
>>
>>   .recipientList(simple("direct:${header.CamelHttpMethod}"));
>>
>> In either case, one could then use the same target url ( as in
>> http://mycompany.com/callrestservice?myparam=12 and the route finds the
>> service restfully according to the http method.
>> With the recipientList trick, the routes are set up with endpoints start
>> direct:GET direct:POST direct:PUT direct:DELETE
>> With peformInvocation, each resource method can call an appropriate
>> service.
>>
>> Furthermore, two identical url requests distinguished only by use of
>> pathParam vs. queryParam or even the name of the param, can be routed,
>> with
>> a further refinement of recipientList trick or if statement in resource
>> method, or .choice( in route.
>>
>> This routing style is actually built in to the rest dsl as in
>> rest(url).get
>> etc.
>>
>> It is difficult to find debate over cxfrs vs rest dsl (avail only
>> since Fall
>> 2015)
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777554.html
>>
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

camel_case
Thanks for the correct processor link.
I'm summarizing main difference between rest dsl routes and cxfrs routes
rest dsl can include the method .get .post .put .delete baked into the route
This is an advantage if you want a different route for each http method, whereas the cxfrs has paths, params, consumer producer return types configured in resource file (interface or class)

Unclear about deciding factors favoring one over the other aside from these obvious structural differences.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Sergey Beryozkin
The difference is declarative vs code-centric, in CXFRS we still have
HTTP methods, but the custom processor needs to do the actual routing
based on the matched verb.

This verb is actually stored on the Camel exchange/message so I'd not be
surprised if it were possible to do it declaratively with some of Camel
components which check this verb which sits after from:cxfrs.

The other difference is that REST DSL is meant to be HTTP-aware
component neutral, as I mentioned CXFRS will support REST DSL eventually...

Sergey

On 11/02/16 15:13, camel_case wrote:

> Thanks for the correct processor link.
> I'm summarizing main difference between rest dsl routes and cxfrs routes
> rest dsl can include the method .get .post .put .delete baked into the route
> This is an advantage if you want a different route for each http method,
> whereas the cxfrs has paths, params, consumer producer return types
> configured in resource file (interface or class)
>
> Unclear about deciding factors favoring one over the other aside from these
> obvious structural differences.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777600.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Sergey Beryozkin
On 11/02/16 16:23, Brad Johnson wrote:
> If  you're using the CXFRs with annotated interfaces there isn't a need to
> be aware of the verb that I'm aware of since the method invoked on the
> interface itself will actually determine the route to invoke when using the
> recipient list.  The only qualifier there is that the Java interface method
> names will have to be unique for each resource.
>
> I've not used the REST DSL so can't comment on it.  But the routing via
> CXFRS is simple with the recipientList mechanics.  That's especially true
> now that null/no-op implementations are no longer required.

Great, I guess this is what I was vaguely referring to, that some
component can help streamline the route processing when working with
CXFRS while you actually know how to do it :-)

Cheers, Sergey

> The interface
> with annotations works.  For me, where I have endpoints with both SOAP and
> REST requirements it is nice to be able to do it that way.
>
> On Thu, Feb 11, 2016 at 9:20 AM, Sergey Beryozkin <[hidden email]>
> wrote:
>
>> The difference is declarative vs code-centric, in CXFRS we still have HTTP
>> methods, but the custom processor needs to do the actual routing based on
>> the matched verb.
>>
>> This verb is actually stored on the Camel exchange/message so I'd not be
>> surprised if it were possible to do it declaratively with some of Camel
>> components which check this verb which sits after from:cxfrs.
>>
>> The other difference is that REST DSL is meant to be HTTP-aware component
>> neutral, as I mentioned CXFRS will support REST DSL eventually...
>>
>> Sergey
>>
>>
>> On 11/02/16 15:13, camel_case wrote:
>>
>>> Thanks for the correct processor link.
>>> I'm summarizing main difference between rest dsl routes and cxfrs routes
>>> rest dsl can include the method .get .post .put .delete baked into the
>>> route
>>> This is an advantage if you want a different route for each http method,
>>> whereas the cxfrs has paths, params, consumer producer return types
>>> configured in resource file (interface or class)
>>>
>>> Unclear about deciding factors favoring one over the other aside from
>>> these
>>> obvious structural differences.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777600.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Multiple consumers for the same endpoint is not allowed cxfrs vs rest dsl

Ranx-2
CONTENTS DELETED
The author has deleted this message.