karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Aries JAX-RS Whiteboard
Date Sun, 25 Nov 2018 04:48:39 GMT
Hi Tom,

I'm curious: what JAXRS API bundle do you use (that provide the JAXRS
contract) ?


On 24/11/2018 19:24, tom@quarendon.net wrote:
>> The SSE from JAX-RS 2.1 definitely works (client and server side) with the Aries
implementation, so hopefully that will give you everything that you need. 
> I have it all working now. I've had to make one or two changes though, as a result of
the change from jersey to cxf.
> Generally, the implementation was pretty easy, it certainly works to use Aries JAX-RS
Whiteboard within Karaf 4.1.2. Once I worked out what the required dependency bundles were,
it was OK. Anecdotally the requests seem faster than using jersey as well, though I haven't
done any testing on that.
> I battled with an issue for a while because I had two bundles providing the jaxrs API.
I had the original one, plus I also had the org.apache.aries.javax.jax.rs-api one (required
as it adds a required OSGi contract specification). That caused me some issues with bundles
sometimes working and sometimes reporting "exposed to package via two dependency chain" issues,
and huge startup times and memory use while it figured it out. That took me a while to iron
> An issue I failed to resolve was that we had some use of jaxrs http client. I never did
manage to get it to use the CXF client implementation. The Aries JAX-RS whiteboard bundles
the required parts of CXF within it, but I don't think they are accessible to use. I tried
including the relevant parts of CXF, but couldn't get it all to work. It seemed to be a bundle
initialisation order issue, in that the geronimo osgi locator component was being used to
find the JAX-RS http client classes before it had been initialised. Maybe if I'd just included
the complete CXF bundle it would all have worked OK, but that seemed overkill when all I wanted
was the client, and when the Aries JAX-RS whiteboard implementation includes its own copy
of CXF as well. Since we only had one class using it I just substituted it for a non-jax-rs
http client and the problem went away.
> I encountered an issue with Aries JAX-RS Whiteboard that I will raise on github. It doesn't
like "void" resource method results. You get:
>   java.lang.NullPointerException
>         at 
>  org.apache.aries.jax.rs.whiteboard.internal.cxf.PromiseAwareJAXRSInvoker.checkFutureResponse(PromiseAwareJAXRSInvoker.java:40)
> This has caused me a bit of rework to get round to be sure it was the problem. 
> I also encountered a difference in behaviour between cxf and jersey. I had a resource
component with a path of "/a", and another with a path of "/a/b". In CXF the second of these
didn't seem to get matched. Instead I had to add a subresource locator method on the first
to match "b" and return the second resource component. No big deal, and I don't actually know
what the spec says is valid. I'm assuming that this is in CXF rather than the whiteboard.
> Apart from all of that, it worked fine. 
> Now to see whether it all actually solves the reliability issues we were having with
our own homebrew whiteboard.
> Thanks for the assistance.

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message