I agree that Aries JAXRS whiteboard currently might not be in good enough shape to already use it. I am pretty sure though that it can be fixed to fit nicely to what we need.
I think the embedding is on purpose to make it easy to deploy jax-rs whiteboard to platforms outside of karaf. Maybe it can provide an embedded as well as a plugable bundle that coexists nicely with an installed cxf. Christian 2018-01-19 14:42 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Yeah, it's where I'm struggling, it requires some private package, and so. > > I'm not a big fan right now to be honest. > > Regards > JB > > > On 01/19/2018 02:33 PM, Daniel Kulp wrote: > >> 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 <ch...@die-schneider.net> >>> 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 <gno...@apache.org>: >>> >>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <dk...@apache.org>: >>>> >>>> >>>>> >>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gno...@apache.org> >>>>>> >>>>> 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é <j...@nanthrax.net>: >>>>>> >>>>>> 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é >>>>>>> jbono...@apache.org >>>>>>> http://blog.nanthrax.net >>>>>>> Talend - http://www.talend.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> >>>>> >>>>> -- >>>>> Daniel Kulp >>>>> dk...@apache.org - 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 >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
