karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Docker feature in Karaf container
Date Fri, 19 Jan 2018 13:42:40 GMT
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 <chris@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 <gnodet@apache.org>:
>>
>>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <dkulp@apache.org>:
>>>
>>>>
>>>>
>>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gnodet@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é <jb@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é
>>>>>> 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

Mime
View raw message