Exactly, I have the same feeling: most of the time, we just want to register a pretty simple JAXRS service as we do with blueprint:
https://github.com/apache/karaf/tree/master/examples/karaf-rest-example/karaf-rest-example-provider However, today, using CXF (which works fine), we need to use blueprint just register the JAXRS server: https://github.com/apache/karaf/blob/master/examples/karaf-rest-example/karaf-rest-example-provider/src/main/resources/OSGI-INF/blueprint/rest.xml So the idea is to leverage the service properties to define the CXF JAXRS server (address, providers, ...) and then we won't need the blueprint dependency. For Aries JAXRS, AFAIR, the problem was in the provided features XML. Regards JB On 22/11/2018 17:14, [email protected] wrote: >> that won't work out of the box as Karaf 4.2.x is still R6. >> >> It will work with Karaf 4.3.x that will be R7. >> >> In the mean time, I'm creating a very simply rest whiteboard pattern for >> CXF. >> It doesn't use all the JAXRS whiteboard spec, but just works fine for >> most of the use cases. > > OK, thanks. That's appreciated. > We're only doing simple things, registering resources and extensions (message > body writer, request/response filters etc), but we only have one application. > It's what I would have thought was pretty normal stuff to be honest. > We do use SSE (server sent events) implementation from jersey at the moment, > and also multipart, but it looks like CXF supports those, so I'm sure that'll > be possible ;-) > > I'll hold off for now then. > What's the timescale for Karaf 4.3? > > Thanks. > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
