[
https://issues.apache.org/jira/browse/CAMEL-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CAMEL-8383:
------------------------------------
Attachment: patch8383.txt
The patch supports the optional propagation of JAX-RS contexts to the Camel
exchange.
Right now it is done in CxfRsInvoker - but may be easily enough refactored for
it to be done inside the default binding. I marginally prefer it be done in the
invoker so that if someone does write a custom binding without extending the
default one the propagation of context still works. The other reason is that
for it to work the invoker needs to pass an optional flag to the binding and
we'd need a property name for that - and I'd like to do that as part of another
refactoring related to where some of JAXRS constants are defined.
So IMHO doing it in the invoker if fine for now. The patch is safe with respect
to the existing cxfrs users
> CXFRS Consumer processors should be able to use JAX-RS contexts
> ---------------------------------------------------------------
>
> Key: CAMEL-8383
> URL: https://issues.apache.org/jira/browse/CAMEL-8383
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Reporter: Sergey Beryozkin
> Priority: Minor
> Fix For: 2.15.0
>
> Attachments: patch8383.txt
>
>
> CXFRS consumer processors should be able to use JAX-RS Contexts, for example,
> instead of
> {code:java}
> String path = exchange.getIn().getHeader(Exchange.HTTP_PATH, String.class);
> if (path.equals("/customers")) {
> //...
> }
> {code}
> do something like
> {code:java}
> javax.ws.rs.core.UriInfo ui = exchange.getProperty(UriInfo.class.getName(),
> UriInfo.class);
> if (ui.getPath().equals("/customers")) {
> //...
> }
> {code}
> This will make the processor code more JAX-RS friendly. Besides UriInfo,
> Request, HttpHeaders and other JAX-RS contexts offer a lot of utility methods
> for simplifying managing an HTTP request
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
