Hi Tom, I'm curious: what JAXRS API bundle do you use (that provide the JAXRS contract) ?
Regards JB On 24/11/2018 19:24, t...@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 out. > > 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é jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com