Karaf feature installation issue.

[Ryan Moquin]

Hi,

So I decided to experiment with installing, removing and reinstalling
features.  I now remember the reason why I am unsure about how to upgrade a
feature.  I seem to be able to install, uninstall and then reinstall my
features (didn't play with it too much, just tried to see if it looks like
it worked) but things break if you do the same thing with Hawtio and I'm
not really sure why.  So if you do the following from a fresh Karaf 3.0.3:

karaf@root>feature:repo-add hawtio
Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
karaf@root>feature:install hawtio-offline
karaf@root>feature:repo-remove -u hawtio-1.4.48
karaf@root>feature:repo-add hawtio
Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
karaf@root>feature:install hawtio-offline

then you get the error below.  At that point I can't even install my Karaf
features the first time because of the jine conflicts.  If there is truly a
JLine conflict, why does hawtio install correctly at all?

2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
   | 25 - org.apache.karaf.shell.console - 3.0.3 | Exception caught
while executing command
java.lang.IllegalStateException: Can't install feature hawtio-offline/0.0.0:
Could not start bundle mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint violation. Unable
to resolve bundle revision io.hawt.hawtio-karaf-terminal [107.0] because it
is exposed to package 'jline' from bundle revisions jline [106.0] and jline
[22.0] via two dependency chains.

Chain 1:
  io.hawt.hawtio-karaf-terminal [107.0]
import:
(&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
 |
export: osgi.wiring.package=jline
  jline [106.0]

Chain 2:
  io.hawt.hawtio-karaf-terminal [107.0]
import:
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package=org.apache.karaf.shell.console; uses:=jline
  org.apache.karaf.shell.console [25.0]
import:
(&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
 |
export: osgi.wiring.package=jline
  jline [22.0]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:388)
at Proxyaa4edd16_924a_4c58_9988_7a5a568d5be9.installFeature(Unknown Source)
at
org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:67)
at
org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:38)
at
org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:39)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.karaf.shell.commands.basic.AbstractCommand.execute(AbstractCommand.java:33)[25:org.apache.karaf.shell.console:3.0.3]
at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
at
org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.java:208)
at
org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1$1.run(LocalConsoleManager.java:109)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_40]
at
org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.java:57)[26:org.apache.karaf.jaas.modules:3.0.3]
at
org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1.run(LocalConsoleManager.java:102)[25:org.apache.karaf.shell.console:3.0.3]
2015-04-18 23:33:03,172 | WARN  | l for user karaf | FeatureValidationUtil
   | 20 - org.a

Re: Karaf and Docker

[Niels]

Maybe drawing a timeline of a typical application lifecycle and outlining the 
challenges at the various stages should paint a pretty good picture. This could 
then be overlaid with the technology features that support each of those 
concerns. We'd get to a view that would show the areas where docker provides 
benefits and where OSGi plays its strengths.

End of the day OSGi covers the  lifecycle of interdependent application 
components and docker is more or less a means to speed up deployment of a 
configured compute resource.

Nothing wrong with docker but using it purposeful seems a bit of a challenge to 
a lot of folks out there.

Cheers,
Niels

Re: Karaf and Docker

[Serge Huber]

James, I don't think JB cared. He was probably more than happy to have a
discussion than to have to simply walk through slides without any feedback.
At least that's how I prefer it.

Personally I think that OSGi is really a great way to make sure that people
get into the good practice about thinking about the full lifecycle of code,
not just developing it and starting it, but also shutting it down, and what
happens when dependencies are not present or shutdown.

In that regard I've seen that in our team since we switched to OSGi,
although it took a little investment in terms of getting used to it, people
are a lot more productive because they can focus on the module they are
building without having to restart the whole container. This is a huge
improvement over Docker type of deployments where rebuilding and restarting
a container can take a lot longer to test a single change.

I believe that OSGi is also more than proven since it has been around for a
long time, and it is defined by a standard body that is quite significant.
I just wish it would get adopted more, and hopefully Karaf will help with
this effort.

Not to make me say that Docker or Spring Boot or the Play Framework don't
have their merits, but I think that it is not enough to look at the time to
get started, it is also important to look at the TMDT (an acronym I just
made up : Total Maintenance and Deployment Time :)).

cheers,
  Serge...

- -- --- -=[ shuber at jahia dot com ]= --- -- -
CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 Acacias,
Switzerland
twitter: @sergehuber 


JahiaOne , our international user conference is
back! June 10-12 in Paris - Grab your tickets now 
!

Jahia is a leading open source User eXperience Platform (UXP) vendor,
relentlessly working at transforming a siloed industry into a user-driven
one, beyond technology constraints - http://www.jahia.com


On Sat, Apr 18, 2015 at 10:47 AM, James Carman 
wrote:

> Serge,
>
> We had some pretty good discussions during JB's talk (hope we didn't
> hijack it too much, JB).  I don't think this topic really has anything to
> do with Docker, necessarily.  Docker is merely a tool people employ to
> implement a deployment strategy.  I think it basically boils down to the
> notion that in the "cloud era", it's simpler and cheaper to spin up a new
> node configured the way you want.  Cloud-enabled applications need to be
> "cloneable" in this way already, so you kind of get this benefit for free.
>
> This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
> isn't only about being able to runtime-refresh your modules.  There are
> many other benefits of the OSGi programming model that make it suitable for
> building statically-configured applications as well.
>
> Just my $0.02
>
> James
>
> On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber  wrote:
>
>> Interesting discussion indeed.
>>
>> I'm currently at ApacheCon US and I've taken a few opportunities to
>> promote Apache Karaf which surprisingly few people know about. But again
>> what I was describing earlier is really a frequent feedback : is modularity
>> worth the trouble when I can built "micro-services" that are actually
>> running in docker containers ? Although I am convinced that the two are not
>> in opposition, I think it would be great to have a killer use case to
>> demonstrate what the benefits of using Karaf would be.
>>
>> I'm really looking forward to meeting Jean-Baptiste in person ! I love
>> Karaf and I hope to be able to exchange with him a few experiences around
>> it.
>>
>> Regards,
>>   Serge
>>
>> - -- --- -=[ shuber at jahia dot com ]= --- -- -
>> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
>> Acacias, Switzerland
>> twitter: @sergehuber 
>>
>> 
>> JahiaOne , our international user conference
>> is back! June 10-12 in Paris - Grab your tickets now
>> !
>>
>> Jahia is a leading open source User eXperience Platform (UXP) vendor,
>> relentlessly working at transforming a siloed industry into a user-driven
>> one, beyond technology constraints - http://www.jahia.com
>>
>>
>> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck 
>> wrote:
>>
>>> Hey,
>>>
>>> yes I fully agree, also with the Spring-Boot stuff.
>>> as already stated on the other thread, I think there are certain cases
>>> where Docker images are useful.
>>> For a POC, for CI I think a Docker Image is useful. In the end if you
>>> want to run it in Production I rather have the Ansible setup.
>>>
>>> regards, Achim
>>>
>>>
>>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré :
>>>
 Hi Ed,

 I can't agree more ;)
 I fully agree about your points.

 I quite have the same view on Spring Boot ;)

 Regards
 JB


 On 04

Re: Karaf and Docker

[Jean-Baptiste Onofré]

Hi James,

no problem at all ! It was more than cool to share our thoughts and views.

Regards
JB

On 04/18/2015 05:47 PM, James Carman wrote:

Serge,

We had some pretty good discussions during JB's talk (hope we didn't
hijack it too much, JB).  I don't think this topic really has anything
to do with Docker, necessarily.  Docker is merely a tool people employ
to implement a deployment strategy.  I think it basically boils down to
the notion that in the "cloud era", it's simpler and cheaper to spin up
a new node configured the way you want.  Cloud-enabled applications need
to be "cloneable" in this way already, so you kind of get this benefit
for free.

This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
isn't only about being able to runtime-refresh your modules.  There are
many other benefits of the OSGi programming model that make it suitable
for building statically-configured applications as well.

Just my $0.02

James

On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber mailto:shu...@jahia.com>> wrote:

Interesting discussion indeed.

I'm currently at ApacheCon US and I've taken a few opportunities to
promote Apache Karaf which surprisingly few people know about. But
again what I was describing earlier is really a frequent feedback :
is modularity worth the trouble when I can built "micro-services"
that are actually running in docker containers ? Although I am
convinced that the two are not in opposition, I think it would be
great to have a killer use case to demonstrate what the benefits of
using Karaf would be.

I'm really looking forward to meeting Jean-Baptiste in person ! I
love Karaf and I hope to be able to exchange with him a few
experiences around it.

Regards,
   Serge

- -- --- -=[ shuber at jahia dot com ]= --- -- -
CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
Acacias, Switzerland
twitter: @sergehuber 


JahiaOne , our international user
conference is back! June 10-12 in Paris - Grab your tickets now
!

Jahia is a leading open source User eXperience Platform (UXP)
vendor, relentlessly working at transforming a siloed industry into
a user-driven one, beyond technology constraints -
http://www.jahia.com 


On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
mailto:bcanh...@googlemail.com>> wrote:

Hey,

yes I fully agree, also with the Spring-Boot stuff.
as already stated on the other thread, I think there are certain
cases where Docker images are useful.
For a POC, for CI I think a Docker Image is useful. In the end
if you want to run it in Production I rather have the Ansible
setup.

regards, Achim


2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré mailto:j...@nanthrax.net>>:

Hi Ed,

I can't agree more ;)
I fully agree about your points.

I quite have the same view on Spring Boot ;)

Regards
JB


On 04/13/2015 04:32 PM, Ed Welch wrote:

I've really enjoyed following this thread, and I have to
say, as a Docker skeptic surrounded by people who want
to bash my brains in with docker images, it's nice to
hear some feedback from people who seem to have a
healthy dose of skepticism like I do...

So rather than rehash all the things I agree with that
have been said so far, I wanted to comment a few things
I hadn't seen:

The biggest discussion point I bring up with my peers
regarding docker that I've been using to kind of hold
the floodgates back:  Who is responsible for updates to
the underlying docker image OS?  Our organization is
fairly segmented, we have a linux operations group, we
have a development group.  If our development group
deploys 50 docker images, all with a variety of distros
inside them, different versions of everything... What
happens if there is a big vulnerability found
(think/remember bash).  Is our linux team now on the
hook to learn docker and handle digging through dozens
to hundreds of potentially very different docker images
( which would make you want to force standardization of
your docker images on a particular distro at a minimum
), or does the dev team now own this responsibility?
This is a hard question for our company to answer...

My other comment, is actually regarding what I think is
the most fantastic use case I'v

Re: Karaf and Docker

[James Carman]

Serge,

We had some pretty good discussions during JB's talk (hope we didn't hijack
it too much, JB).  I don't think this topic really has anything to do with
Docker, necessarily.  Docker is merely a tool people employ to implement a
deployment strategy.  I think it basically boils down to the notion that in
the "cloud era", it's simpler and cheaper to spin up a new node configured
the way you want.  Cloud-enabled applications need to be "cloneable" in
this way already, so you kind of get this benefit for free.

This doesn't mean we can't use OSGi to piece together these nodes.  OSGi
isn't only about being able to runtime-refresh your modules.  There are
many other benefits of the OSGi programming model that make it suitable for
building statically-configured applications as well.

Just my $0.02

James

On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber  wrote:

> Interesting discussion indeed.
>
> I'm currently at ApacheCon US and I've taken a few opportunities to
> promote Apache Karaf which surprisingly few people know about. But again
> what I was describing earlier is really a frequent feedback : is modularity
> worth the trouble when I can built "micro-services" that are actually
> running in docker containers ? Although I am convinced that the two are not
> in opposition, I think it would be great to have a killer use case to
> demonstrate what the benefits of using Karaf would be.
>
> I'm really looking forward to meeting Jean-Baptiste in person ! I love
> Karaf and I hope to be able to exchange with him a few experiences around
> it.
>
> Regards,
>   Serge
>
> - -- --- -=[ shuber at jahia dot com ]= --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> Acacias, Switzerland
> twitter: @sergehuber 
>
> 
> JahiaOne , our international user conference is
> back! June 10-12 in Paris - Grab your tickets now
> !
>
> Jahia is a leading open source User eXperience Platform (UXP) vendor,
> relentlessly working at transforming a siloed industry into a user-driven
> one, beyond technology constraints - http://www.jahia.com
>
>
> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck 
> wrote:
>
>> Hey,
>>
>> yes I fully agree, also with the Spring-Boot stuff.
>> as already stated on the other thread, I think there are certain cases
>> where Docker images are useful.
>> For a POC, for CI I think a Docker Image is useful. In the end if you
>> want to run it in Production I rather have the Ansible setup.
>>
>> regards, Achim
>>
>>
>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré :
>>
>>> Hi Ed,
>>>
>>> I can't agree more ;)
>>> I fully agree about your points.
>>>
>>> I quite have the same view on Spring Boot ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 04/13/2015 04:32 PM, Ed Welch wrote:
>>>
 I've really enjoyed following this thread, and I have to say, as a
 Docker skeptic surrounded by people who want to bash my brains in with
 docker images, it's nice to hear some feedback from people who seem to have
 a healthy dose of skepticism like I do...

 So rather than rehash all the things I agree with that have been said
 so far, I wanted to comment a few things I hadn't seen:

 The biggest discussion point I bring up with my peers regarding docker
 that I've been using to kind of hold the floodgates back:  Who is
 responsible for updates to the underlying docker image OS?  Our
 organization is fairly segmented, we have a linux operations group, we have
 a development group.  If our development group deploys 50 docker images,
 all with a variety of distros inside them, different versions of
 everything... What happens if there is a big vulnerability found
 (think/remember bash).  Is our linux team now on the hook to learn docker
 and handle digging through dozens to hundreds of potentially very different
 docker images ( which would make you want to force standardization of your
 docker images on a particular distro at a minimum ), or does the dev team
 now own this responsibility?  This is a hard question for our company to
 answer...

 My other comment, is actually regarding what I think is the most
 fantastic use case I've seen for docker, which was written up by Roland
 Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/
 Using docker as part of your automated integration tests is a really
 neat idea, especially if you work on a project that has to maintain support
 for piles of application servers, operating systems, and versions of java.
 I think there is some real opportunity here as was previously mentioned, to
 build a docker image that sets up the OS, java, and karaf, and then at test
 time you deploy your app and run your tests.  With this kind of model you
 can just keep adding new docker images to your test suite and retire old
 ones w