On Sat, Nov 24, 2018, 23:48 Jean-Baptiste Onofré <[email protected] wrote:
> Hi Tom, > > I'm curious: what JAXRS API bundle do you use (that provide the JAXRS > contract) ? > There's two you could use. The one in Aries jaxrs whiteboard repo that was built to bootstrap the project and the one from Apache Geronimo. - Ray > > Regards > JB > > On 24/11/2018 19:24, [email protected] 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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
