[PROPOSAL] Docker feature in Karaf container

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Docker feature in Karaf container

jbonofre
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

fpapon
Hi JB,

I think it's a good idea !

I'm agree with adding docker as a dedicated module in Karaf container
because it just use docker.

It would be also interesting to be able to create an image of Karaf from
the running instance :)

François


Le 18/01/2018 à 13:37, Jean-Baptiste Onofré a écrit :

> 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

François Papon
fpapon@apache.org
Yupiik - https://www.yupiik.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Andrea Cosentino
In reply to this post by jbonofre
+1 :-)

--
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix PMC Member
Email: [hidden email]
Twitter: @oscerd2
Github: oscerd






On Thursday, January 18, 2018, 10:38:03 AM GMT+1, Jean-Baptiste Onofré <[hidden email]> wrote:





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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Achim Nierbeck
+1 sound like an interesting idea i'd like to see.

2018-01-18 11:15 GMT+01:00 Andrea Cosentino <[hidden email]>:

> +1 :-)
>
> --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: [hidden email]
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
>
>
> On Thursday, January 18, 2018, 10:38:03 AM GMT+1, Jean-Baptiste Onofré <
> [hidden email]> wrote:
>
>
>
>
>
> 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é
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Guillaume Nodet-2
In reply to this post by jbonofre
Sounds good to me.

I think there's a few technical things that need to be addressed while
merging:
  * remove blueprint dependency
  * use a single bundle (i don't see any benefit in splitting this feature
in multiple bundles)
  * 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)

2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <[hidden email]>:

> 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é
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
------------------------
Guillaume Nodet
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

jbonofre
Thanks for the feedback, and fully agree.

I'm planning to do that for the PR.

Regards
JB

On 01/19/2018 10:00 AM, Guillaume Nodet wrote:

> Sounds good to me.
>
> I think there's a few technical things that need to be addressed while
> merging:
>    * remove blueprint dependency
>    * use a single bundle (i don't see any benefit in splitting this feature
> in multiple bundles)
>    * 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)
>
> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <[hidden email]>:
>
>> 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é
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Daniel Kulp
In reply to this post by Guillaume Nodet-2


> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]> 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.


Dan



> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <[hidden email]>:
>
>> 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é
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Guillaume Nodet-2
2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:

>
>
> > On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]> 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é <[hidden email]>:
> >
> >> 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é
> >> [hidden email]
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


--
------------------------
Guillaume Nodet
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

cschneider
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 <[hidden email]>:

> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>
> >
> >
> > > On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]>
> 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é <[hidden email]>:
> > >
> > >> 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é
> > >> [hidden email]
> > >> http://blog.nanthrax.net
> > >> Talend - http://www.talend.com
> > >>
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
> > --
> > Daniel Kulp
> > [hidden email] - 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
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

jbonofre
Actually, it's what I started to check using Aries JAXRS.

I will give you an update with the different options I'm evaluating.

Regards
JB

On 01/19/2018 02:01 PM, 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 <[hidden email]>:
>
>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>>
>>>
>>>
>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]>
>> 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é <[hidden email]>:
>>>>
>>>>> 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é
>>>>> [hidden email]
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>
>>> --
>>> Daniel Kulp
>>> [hidden email] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

fpapon
In reply to this post by Guillaume Nodet-2
I'm agree with Guillaume, CXF could be the default implementation but
not be mandatory.


Le 19/01/2018 à 16:54, Guillaume Nodet a écrit :

> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>
>>
>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]> 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é <[hidden email]>:
>>>
>>>> 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é
>>>> [hidden email]
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>> --
>> Daniel Kulp
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>

François Papon
fpapon@apache.org
Yupiik - https://www.yupiik.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

Daniel Kulp
In reply to this post by cschneider
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 <[hidden email]> 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 <[hidden email]>:
>
>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>>
>>>
>>>
>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]>
>> 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é <[hidden email]>:
>>>>
>>>>> 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é
>>>>> [hidden email]
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>
>>> --
>>> Daniel Kulp
>>> [hidden email] - 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

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

jbonofre
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 <[hidden email]> 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 <[hidden email]>:
>>
>>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>>>
>>>>
>>>>
>>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]>
>>> 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é <[hidden email]>:
>>>>>
>>>>>> 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é
>>>>>> [hidden email]
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>
>>>> --
>>>> Daniel Kulp
>>>> [hidden email] - 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

cschneider
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é <[hidden email]>:

> 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 <[hidden email]>
>>> 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 <[hidden email]>:
>>>
>>> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[hidden email]>:
>>>>
>>>>
>>>>>
>>>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[hidden email]>
>>>>>>
>>>>> 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é <[hidden email]>:
>>>>>>
>>>>>> 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é
>>>>>>> [hidden email]
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> [hidden email] - 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é
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



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

Computer Scientist
http://www.adobe.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Docker feature in Karaf container

jbonofre
In reply to this post by jbonofre
Hi guys,

quick update about this. I removed the blueprint dependency to use the same
approach as other Karaf modules (BaseActivator). I also started to use the JAXRS
spec instead of CXFRS backend.
I started an local integration branch this morning. I should create a PR
including utests/itests, features and so on tomorrow.

Thanks !
Regards
JB

On 01/18/2018 10:37 AM, Jean-Baptiste Onofré wrote:

> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com