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
