From dev-return-12621-archive-asf-public=cust-asf.ponee.io@karaf.apache.org Fri Jan 19 14:42:47 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 1A407180607 for ; Fri, 19 Jan 2018 14:42:47 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 0A5A5160C28; Fri, 19 Jan 2018 13:42:47 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 26032160C27 for ; Fri, 19 Jan 2018 14:42:45 +0100 (CET) Received: (qmail 6333 invoked by uid 500); 19 Jan 2018 13:42:45 -0000 Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list dev@karaf.apache.org Received: (qmail 6322 invoked by uid 99); 19 Jan 2018 13:42:45 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jan 2018 13:42:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 90E621A07C4 for ; Fri, 19 Jan 2018 13:42:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id jaEDlLVRWV2W for ; Fri, 19 Jan 2018 13:42:42 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 25EAB5F23E for ; Fri, 19 Jan 2018 13:42:42 +0000 (UTC) X-Originating-IP: 82.238.224.4 Received: from [192.168.134.109] (bre91-1-82-238-224-4.fbx.proxad.net [82.238.224.4]) (Authenticated sender: jb@nanthrax.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E4284172098 for ; Fri, 19 Jan 2018 14:42:40 +0100 (CET) Subject: Re: [PROPOSAL] Docker feature in Karaf container To: dev@karaf.apache.org References: <7d9b161e-2ca4-ae76-119c-ef5e3e9d11bc@nanthrax.net> <59FBB102-6D86-4AC0-ADA8-58F89A15EA31@apache.org> From: =?UTF-8?Q?Jean-Baptiste_Onofr=c3=a9?= Message-ID: <95d58328-b569-5374-e4aa-952f29d27ce2@nanthrax.net> Date: Fri, 19 Jan 2018 14:42:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 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 : >> >>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp : >>> >>>> >>>> >>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet >>> 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é : >>>>> >>>>>> 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é >>>>>> jbonofre@apache.org >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------ >>>>> Guillaume Nodet >>>> >>>> -- >>>> Daniel Kulp >>>> dkulp@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é jbonofre@apache.org http://blog.nanthrax.net Talend - http://www.talend.com