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.
