On Sat, Nov 24, 2018 at 1:24 PM <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.
Did you notice that the JAX-RS Whiteboard provides a ClientBuilder (prototype scoped) service? e.g. @Reference ClientBuilder clientBuilder; [1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e134114 > 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. > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
