JAX-RS whiteboard currently has a few other issues, mostly due to the implementation in Aries. Probably should find some time to work on that.
The main issue is that, right now, it embeds parts of CXF but then exports a few packages. Thus, getting it and a “real” CXF application working together is nearly impossible. The Aries implementation really needs to be split so that there is a “whiteboard only” bundle that imports CXF (and other deps) instead of embedding them, and then maybe a separate uber bundle that embeds the stuff if that’s needed for the TCK. Dan > On Jan 19, 2018, at 8:01 AM, Christian Schneider <[email protected]> > wrote: > > How about implementing jax-rs services using the OSGi jax-rs whiteboard > spec? So the implementation would be CXF but the code would ideally only be > tied to the jax-rs spec and the jax-rs whiteboard spec. > > Cheers > Christian > > 2018-01-19 13:54 GMT+01:00 Guillaume Nodet <[email protected]>: > >> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[email protected]>: >> >>> >>> >>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[email protected]> >> wrote: >>>> >>>> * investigate the use of JaxRS 2.0 api instead of the CXF dependency >> (to >>>> be more flexible and also because it would create yet another circular >>>> dependency) >>> >>> I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you >> still >>> need an implementation in order for the API’s to work. I hope the >> chosen. >>> Implementation would remain CXF. >>> >> >> 1./ unless there's a compelling reason to tie the implementation to CXF, >> I'd rather use the standard API instead >> 2./ this does create a circular dependency, as karaf will depend on CXF and >> CXF on Karaf. I know this is not a problem when releasing because we >> always reference an older version of the other project, but still, if this >> can be avoided I think it would be better >> 3./ i'd like CXF to be the default and i don't have any reason to switch to >> a different provider, but that does not mean everyone should be forced to >> use it, as they may have reasons to use a different provider (which could >> also be a non technical reason) >> >> I don't see any difference between choosing a jaxrs provider and choosing a >> servlet provider or a transaction manager. We do usually leave room for >> choice, I'd like to keep it that way, if that's technically possible. >> >> >>> >>> >>> Dan >>> >>> >>> >>>> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >>>> >>>>> Hi, >>>>> >>>>> Some days ago, we discussed about Decanter 2.0.0 and using "external" >>>>> instances of used engines, like Elasticsearch or Kibana. >>>>> >>>>> Basically, the main reason is that some engines are not easy to embed >> in >>>>> Karaf. It's the case of Kibana as it uses node.js. >>>>> >>>>> However, one of the big advantage of embedded instance of >> Elasticsearch >>> or >>>>> Kibana is that it's very easy to install and use: it's just a >>>>> feature:install command to perform. >>>>> >>>>> So, I would like to provide both advantages: easy to install and use >>> with >>>>> external instances ;) >>>>> >>>>> A first approach would be to create a "exec" bundle starting the >>> instance. >>>>> But we gonna face the "classic" issues depending of the environment. >>>>> >>>>> Maybe some of you remember the karaf-docker PoC I did month ago: >>>>> >>>>> https://github.com/jbonofre/karaf-docker >>>>> >>>>> This is a simple feature that allows you to manipulate docker images: >>>>> bootstrapping, starting/running, ... >>>>> >>>>> I think it would help a lot in Decanter or Cellar: we can just provide >>>>> Karaf Docker commands to bootstrap Elasticsearch, Kibana, OrientDB, >> ... >>>>> As a best effort, we will try to provide embedded instance as >> possible, >>>>> but it won't be the preferred approach. >>>>> >>>>> As karaf-docker is small project and just basically use docker, I >> think >>> it >>>>> doesn't require to be a Karaf subproject. >>>>> As we have the karaf scheduler (using Quartz internally), I would like >>> to >>>>> propose to add docker in Karaf container in a dedicated module. >>>>> >>>>> It means that users will be able to do feature:install docker to have >>> the >>>>> docker commands. >>>>> I would like also to add a command and configuration to have "ready to >>> go >>>>> images". Something that will allow users to do: >>>>> >>>>> docker:run elasticsearch >>>>> >>>>> then, elasticsearch will use a ready to go dockerfile. >>>>> >>>>> It would be possible to do: >>>>> >>>>> docker:run mvn:org.apache.karaf.decanter.docker/elasticsearch/6.1.0/ >>> docker >>>>> >>>>> Where we can host ready to use "official" dockerfile. >>>>> >>>>> Thoughts ? >>>>> >>>>> Regards >>>>> JB >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>> >>> -- >>> Daniel Kulp >>> [email protected] - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >>> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
