You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by camel_case <cs...@remedypartners.com> on 2016/02/09 22:55:12 UTC
Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
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.
--
View this message in context: http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
Using recipientList with header.operationName instead of
header.CamelHttpMethod will let you set the route to a name that matches
the method invoked on your interface.
@GET
@Path("foo/{fooId}")
@Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Consumes({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@WebMethod(operationName="getInvoice")
@WebResult(name="invoice")
public InvoicePDF getInvoice(
@WebParam(name = "foo", targetNamespace = "")
@PathParam("fooId") String invoiceId);
public FooReturn processFoo(
@WebParam(name = "foo", targetNamespace = "")
@PathParam("invoiceId") String foo);
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
Will route the incoming message to the direct-vm:processFoo. At that
point it doesn't matter what the HTTP method invocation was as it isn't
using that information to determine the route to invoke. Obviously I have
this tagged for both REST and SOAP which isn't entirely of interest to you.
On Wed, Feb 10, 2016 at 3:51 PM, camel_case <cs...@remedypartners.com>
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.
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
In the future I may use the new REST DSL if I find an appropriate place for
it. It seems rather straightforward. I'd just have to make sure I was
working on an exclusive REST API and was certain that being tied to HTTP
was going to be OK.
I was a little surprised to find it embedded in the RouteBuilder code. I'd
sort of assumed something like that would have been in its own class or
even separate jar/bundle.
On Thu, Feb 11, 2016 at 10:29 AM, Sergey Beryozkin <sb...@gmail.com>
wrote:
> 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 <sb...@gmail.com>
>> 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.
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com>
> 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.
>>>
>>>
>>
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
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. 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 <sb...@gmail.com>
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.
>>
>>
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs
vs rest dsl
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs
vs rest dsl
Posted by camel_case <cs...@remedypartners.com>.
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.
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: Multiple consumers for the same endpoint is not allowed cxfrs
vs rest dsl
Posted by camel_case <cs...@remedypartners.com>.
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.
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
I've used recipient list a lot and it works quite well. Right now I'm
using annotations for both REST and SOAP on the same interface and can
thereby expose and route the values in the same fashion. You're right that
there isn't a default but when you're using these there wouldn't really be
a default anyway. Either the REST endpoint exists and thereby invokes your
recipient list or it will be rejected by CXF as a non-existent resource
before it ever gets to you anyway.
On Tue, Feb 9, 2016 at 5:11 PM, camel_case <cs...@remedypartners.com>
wrote:
> 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
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777498.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs
vs rest dsl
Posted by camel_case <cs...@remedypartners.com>.
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
--
View this message in context: http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492p5777498.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
When you say resource file are you talking about a Java interface with
annotations or something else? If it is the interface then the
operationName comes from the invocation name of the method on the interface
and is dynamically routed with a recipient list to the appropriate route.
But I'm not sure if that's what you're asking about.
On Tue, Feb 9, 2016 at 4:30 PM, camel_case <cs...@remedypartners.com>
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.
>
Re: Multiple consumers for the same endpoint is not allowed cxfrs
vs rest dsl
Posted by camel_case <cs...@remedypartners.com>.
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.
Re: Multiple consumers for the same endpoint is not allowed cxfrs vs
rest dsl
Posted by Brad Johnson <br...@mediadriver.com>.
Have you tried using a recipientList with appropriate header values.
Something like this:
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
On Tue, Feb 9, 2016 at 3:55 PM, camel_case <cs...@remedypartners.com>
wrote:
> 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.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Multiple-consumers-for-the-same-endpoint-is-not-allowed-cxfrs-vs-rest-dsl-tp5777492.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>