karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [PROPOSAL] Docker feature in Karaf container
Date Sat, 20 Jan 2018 11:06:57 GMT
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é <jb@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 <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
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message