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 <cshoo...@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.
>
