Re: Deploying applications on Karaf

[Achim Nierbeck]

Hi Ryan,

see comments inline.

regards, Achim


2015-04-12 0:37 GMT+02:00 Ryan Moquin :

> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
> deployment flexibility using features feels a little tougher than it feels
> like it should be (I don't have any better ideas).
>
That's strange, cause features are there to make life easier not harder.
Make sure you cut the features right, not to big but also not to small
(like one bundle, one feature). Usually it helps to create those feature
files yourself as the plugin can't estimate what your intension of this
combination of bundles is.


>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
> seems to not be able to initialize properly for who knows what reason.
> Another problem is that I seem to run into a lot of problems in the tests
> and can't seem to find anything in the output or Karaf love that
> indicate.the problem.  If I run it normally in Karaf, I usually get clued
> into what the issue is.
>
Now that could be addressed. First of all, does it work for you on your
machine? Is Bamboo capable of connecting to the internet.
Is maven capable of connecting to the required repositories. Do you have
all dependencies defined in your POM, so the configuration section of the
test does find those (combined with the depends-maven-plugin)


> One last thing is that since my development shop uses MacOSx, Docker
> containers have to be run in a VM which feels silly and is slow.  I don't
> have a choice in that manner.
>
Oh, I'm working with MacOSx too. I know it can be cumbersome but running 4
images in parallel can be done :-)



> It would be nice if there was a way to manage feature xml files in a way
> that felt more straight forward  Maybe there is and I'm just not aware
> of it.
>
You have the choices, use the karaf maven plugin for generation, or build
those yourself. In the end it's up to how you want your application build.
But maybe I miss something cause usually you have a certain set of bundles
running in your application that need to run anyway. With this setup you
can test your application.



> On Apr 8, 2015 3:07 PM, "Achim Nierbeck"  wrote:
>
>> Hi,
>>
>> just recently for a talk with showcase I was thinking about how to create
>> a CI/CD build pipeline with Karaf. Maybe some of this does help you.[1]
>> In the end I ended up with a setup where I have a pre-configured Karaf
>> (custom build) which is startable as Docker Image or can be used as startup
>> tar.gz of the Pax Exam integration tests.
>> Usually camel routes are more about Integration therefore the most
>> use-cases need to be handled by Integration tests. In those scenarios you
>> just can't rely only on the camel-core bundles therefore you need more
>> features just to have your unit tests/integration tests runnable. In those
>> scenarios I usually suggest build your own distribution on top of Karaf and
>> use it as your base-image in the pax-exam tests. If there is more external
>> infrastructure needed I tend to use either full-integration test systems or
>> now a docker based test-environment which can be started via a maven goal
>> as pre-intergration phase systems.
>>
>> regards, Achim
>>
>> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>>
>> 2015-04-08 17:24 GMT+02:00 Ryan Moquin :
>>
>>> Hi,
>>>
>>> I have another question regarding Karaf and deployments.  I was hoping
>>> maybe some others could chime in on how they deal with the following
>>> situation.
>>>
>>> I've been working on a fairly complex Karaf based application.  I'm
>>> using features heavily to allow deploying the correct resources in
>>> different environments (configuration and bundles).  I find it works very
>>> well except for a couple situations:
>>>
>>> 1.  Unit testing.  It's hard to unit test things like camel routes since
>>> I have ended up basically marking all bundle dependencies as provided (in
>>> order to keep the created features files .  So if I try to unit test a
>>> Camel route, transitive dependencies have to be directly added to the
>>> project pom.
>>>
>>> 2.  I have all my configurations defined in a maven project for
>>> assembling the final features xml file.  This of course doesn't make it
>>> easy to use any of those configurations in camel integration tests since
>>> configurations needed for config admin would have to be added to the
>>> projects test resources.
>>>
>>> Obviously the two brief examples above focus mostly on Camel, but the
>>> main problem is that I'm trying to figure out how I can no longer make
>>> everything provided in my bundle project provided scope without having to
>>> manually maintain the features files.
>>>
>>> That being said, I was looking at Apache Ace, but I'm not sure if using
>>> Apache Ace would cause it to be more work to do Karaf integration testing
>>> since Apache Ace doesn't use Karaf features.  I thought about maybe using
>>> OBR, but we use Artifactory and so I'm not sure if going down the O

Re: Karaf and Docker

[Achim Nierbeck]

Hi Serge,

since you wanted to integrate ES in Karaf, take a look at decanter. About
the modularization of ES, I'm with you. A colleague of mine just recently
talked to Shay Banon about this, but right now they aren't in for OSGi, I
guess we have to push them there a little.

About tooling, yes I think we could need some better tooling here and
there, but as usual the devs here just scratch their own itches. So if we
miss things, since we do it just a bit different or don't feel the pain
we're not going to build those tools ;)

Personally I think the learning curve used to be steeper, but with
blueprint and DS it turns out to be much simpler. Until people stumble over
service-trackers in Activators ;)

The thing about Docker is, it's a nice tool and does help here and there,
for showcases, POCs and such. In the end people will use
it as the hammer for every issue they have.

regards, Achim


2015-04-12 3:52 GMT+02:00 Serge Huber :

> Very interesting thread guys :)
>
> Actually I recently started a project integrating Karaf with ElasticSearch
> and for me it was a little like what you guys are describing in this
> thread. ES, at least in the early versions is quite monolithic and it would
> clearly benefit from a framework such as OSGi. For example, the clustering
> technology is quite interesting but why can't it be reused without all the
> other stuff ? Or maybe you want to wire things a little differently ? Not
> have everything directly listen to ports without any security but be able
> to plugin whatever filter or modules you need ?
>
> Personally I think that what is really needed in OSGi is better tooling,
> especially for making it a lot simpler to build high quality and
> minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is
> quite tedious and possibly error prone. I've built my own Maven plugin on
> top of the bundle plugin so that it can handle a lot more resources
> (including JSPs that include taglibs for example) and that also tries to be
> smarter at generating import-package statements. This makes it easier for
> OSGi newbies to adopt the technology.
>
> I'm also worried that the initial learning curve of OSGi might be putting
> less experienced developers off and more towards package-the-world
> solutions such as Docker, which while acceptable for some cases such as
> continuous integration, could also be dangerous if not maintained properly.
>
> Regards,
>   Serge
>
> Le 11 avr. 2015 à 19:43, Niels  a écrit :
>
> Could not agree more Achim. Good fad indicators are high promises which
> are designed to target the ultimate need of decision makers to deliver
> software quicker and cheaper. Just rewind 10 years and we will find the
> exact same promises were made at the start of the SOA hype which are now
> touted by the microservices believers. At the end of the day nothing will
> prevent people from doing something really badly.
>
> I can see the value of docker but unless one really has all the lifecycle
> ducks in a row I would not go down the path and containerise the all and
> sundry.
>
> Cheers,
> Niels
>
> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
>
> I used to work somewhere with other developers who always became very
> spiritual about whatever the latest "cool" developer technology or
> methodology is.  Microservices was one of them.  It always made me laugh
> when I was told how super efficient and streamlined it was over any other
> solution because every fat jar deployed (Maven shade plugin abuse in order
> to be lazy) was between 500Mb and 1.7Gb.  So much for being a
> "micro"-service.
> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>
>> I'm very ambivalent regarding this topic.
>>
>> On one hand I see a lot of move to Docker as heading for the holy grail
>> on fixing all the issues we had in the past. #FAIL
>> On the other hand I see some benefits of it, but still haven't found the
>> concrete use-case where it did top a bar-metal or bare virtualized machine.
>>
>> It's absolutely true that it does have some benefits for easier
>> deployment of "Infrastructure" but I also see a lot of failures in usage of
>> Docker. Just to mention one, where did the init daemon go, it's been there
>> for a reason in linux OS's and now we run applications on top of the system
>> without it ... I don't feel comfortable with that, especially if you don't
>> have a JVM as process running which starts spawning other processes (one
>> might remember the zombie processes).
>> In the end there are mostly more slopy/lazy people around[1] trying to
>> get something going, that's why Docker will be sufficient enough, while the
>> dynamic and re-configurable service oriented software architecture will be
>> on the decrease. One just needs to follow that Microservice hype.
>> Docker/SpringBoot are just part of this "mantra" :D
>> In the end people will just split their Monolithic rubbish up to
>> different small Monolithic piles of rubbish, but in case one of them is
>> faili

Re: Karaf and Docker

[Serge Huber]

Very interesting thread guys :)

Actually I recently started a project integrating Karaf with ElasticSearch and 
for me it was a little like what you guys are describing in this thread. ES, at 
least in the early versions is quite monolithic and it would clearly benefit 
from a framework such as OSGi. For example, the clustering technology is quite 
interesting but why can't it be reused without all the other stuff ? Or maybe 
you want to wire things a little differently ? Not have everything directly 
listen to ports without any security but be able to plugin whatever filter or 
modules you need ?

Personally I think that what is really needed in OSGi is better tooling, 
especially for making it a lot simpler to build high quality and minimalistic 
bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious 
and possibly error prone. I've built my own Maven plugin on top of the bundle 
plugin so that it can handle a lot more resources (including JSPs that include 
taglibs for example) and that also tries to be smarter at generating 
import-package statements. This makes it easier for OSGi newbies to adopt the 
technology.

I'm also worried that the initial learning curve of OSGi might be putting less 
experienced developers off and more towards package-the-world solutions such as 
Docker, which while acceptable for some cases such as continuous integration, 
could also be dangerous if not maintained properly. 

Regards,
  Serge

> Le 11 avr. 2015 à 19:43, Niels  a écrit :
> 
> Could not agree more Achim. Good fad indicators are high promises which are 
> designed to target the ultimate need of decision makers to deliver software 
> quicker and cheaper. Just rewind 10 years and we will find the exact same 
> promises were made at the start of the SOA hype which are now touted by the 
> microservices believers. At the end of the day nothing will prevent people 
> from doing something really badly.
> 
> I can see the value of docker but unless one really has all the lifecycle 
> ducks in a row I would not go down the path and containerise the all and 
> sundry.
> 
> Cheers,
> Niels
> 
>> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
>> 
>> I used to work somewhere with other developers who always became very 
>> spiritual about whatever the latest "cool" developer technology or 
>> methodology is.  Microservices was one of them.  It always made me laugh 
>> when I was told how super efficient and streamlined it was over any other 
>> solution because every fat jar deployed (Maven shade plugin abuse in order 
>> to be lazy) was between 500Mb and 1.7Gb.  So much for being a 
>> "micro"-service.
>> 
>>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>>> I'm very ambivalent regarding this topic. 
>>> 
>>> On one hand I see a lot of move to Docker as heading for the holy grail on 
>>> fixing all the issues we had in the past. #FAIL
>>> On the other hand I see some benefits of it, but still haven't found the 
>>> concrete use-case where it did top a bar-metal or bare virtualized machine. 
>>> 
>>> It's absolutely true that it does have some benefits for easier deployment 
>>> of "Infrastructure" but I also see a lot of failures in usage of Docker. 
>>> Just to mention one, where did the init daemon go, it's been there for a 
>>> reason in linux OS's and now we run applications on top of the system 
>>> without it ... I don't feel comfortable with that, especially if you don't 
>>> have a JVM as process running which starts spawning other processes (one 
>>> might remember the zombie processes). 
>>> In the end there are mostly more slopy/lazy people around[1] trying to get 
>>> something going, that's why Docker will be sufficient enough, while the 
>>> dynamic and re-configurable service oriented software architecture will be 
>>> on the decrease. One just needs to follow that Microservice hype. 
>>> Docker/SpringBoot are just part of this "mantra" :D
>>> In the end people will just split their Monolithic rubbish up to different 
>>> small Monolithic piles of rubbish, but in case one of them is failing, 
>>> they'll end up with one big failing pile of rubbish. 
>>> 
>>> Besides this rant, I think building a custom Karaf with your application on 
>>> top, distributable as Docker image. Or as I did for a showcase building a 
>>> base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a 
>>> good combination. As long as it's possible to configure the services inside 
>>> this docker image from the outside. 
>>> 
>>> regards, Achim 
>>> 
>>> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html
>>> 
>>> 
>>> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu :
 I agree, I do feel that vibe from time to time, mostly due to the 
 'containers should be immutable' mantra.
 
 In my opinion, if you can get away with it, make it as dynamic as you 
 want, but I guess we all know that building an application that can be 
 reconfigured + updated on the fly is not e

Re: Karaf and Docker

[Niels]

Could not agree more Achim. Good fad indicators are high promises which are 
designed to target the ultimate need of decision makers to deliver software 
quicker and cheaper. Just rewind 10 years and we will find the exact same 
promises were made at the start of the SOA hype which are now touted by the 
microservices believers. At the end of the day nothing will prevent people from 
doing something really badly.

I can see the value of docker but unless one really has all the lifecycle ducks 
in a row I would not go down the path and containerise the all and sundry.

Cheers,
Niels

> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
> 
> I used to work somewhere with other developers who always became very 
> spiritual about whatever the latest "cool" developer technology or 
> methodology is.  Microservices was one of them.  It always made me laugh when 
> I was told how super efficient and streamlined it was over any other solution 
> because every fat jar deployed (Maven shade plugin abuse in order to be lazy) 
> was between 500Mb and 1.7Gb.  So much for being a "micro"-service.
> 
>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>> I'm very ambivalent regarding this topic. 
>> 
>> On one hand I see a lot of move to Docker as heading for the holy grail on 
>> fixing all the issues we had in the past. #FAIL
>> On the other hand I see some benefits of it, but still haven't found the 
>> concrete use-case where it did top a bar-metal or bare virtualized machine. 
>> 
>> It's absolutely true that it does have some benefits for easier deployment 
>> of "Infrastructure" but I also see a lot of failures in usage of Docker. 
>> Just to mention one, where did the init daemon go, it's been there for a 
>> reason in linux OS's and now we run applications on top of the system 
>> without it ... I don't feel comfortable with that, especially if you don't 
>> have a JVM as process running which starts spawning other processes (one 
>> might remember the zombie processes). 
>> In the end there are mostly more slopy/lazy people around[1] trying to get 
>> something going, that's why Docker will be sufficient enough, while the 
>> dynamic and re-configurable service oriented software architecture will be 
>> on the decrease. One just needs to follow that Microservice hype. 
>> Docker/SpringBoot are just part of this "mantra" :D
>> In the end people will just split their Monolithic rubbish up to different 
>> small Monolithic piles of rubbish, but in case one of them is failing, 
>> they'll end up with one big failing pile of rubbish. 
>> 
>> Besides this rant, I think building a custom Karaf with your application on 
>> top, distributable as Docker image. Or as I did for a showcase building a 
>> base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a 
>> good combination. As long as it's possible to configure the services inside 
>> this docker image from the outside. 
>> 
>> regards, Achim 
>> 
>> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html
>> 
>> 
>> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu :
>>> I agree, I do feel that vibe from time to time, mostly due to the 
>>> 'containers should be immutable' mantra.
>>> 
>>> In my opinion, if you can get away with it, make it as dynamic as you want, 
>>> but I guess we all know that building an application that can be 
>>> reconfigured + updated on the fly is not easy at all.
>>> 
>>> Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, 
>>> with quite a different approach: I explore monitoring the Docker API to 
>>> discover services, and inject those services as OSGi configuration data:
>>> 
>>> http://www.codemonkey.nl/discovery/
>>> 
>>> I think OSGi and Docker can complement each other very nicely.
>>> 
>>> regards, Frank
>>> 
 On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin  wrote:
 Don't get me wrong, I don't mean that Docker and Karaf are 
 interchangeable.  I mean that it feels like, from quite a few things I 
 read, that the trend may be to have a docker image built as part of every 
 CI build.  The purpose being that deployments should be fully immutable 
 and if changes need to be made, then a new Docker image should be 
 generated and deployed.
 
 One particular conversation that I felt really expressed this type of 
 development track is this one:
 
 https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk
 
 Fabric8 used to be fully built on Karaf but has changed the approach to 
 support other runtimes.  Nothing is wrong with that, but if that pattern 
 becomes a trend, then it feels that many of the nice features of Karaf 
 will become "discouraged" and I can't see them being furthered in Karaf at 
 that point.
 
 I love Karaf and everything it offers.  I'm just a little concerned about 
 how Docker is being pushed and the mindset that seems to evolving around 
 it.  The point is, I'm hoping that because Docker 

Re: bundle:update

[Ryan Moquin]

I'm not sure how that would help with the refresh issue, or am I missing
something?  :)
On Apr 5, 2015 10:23 AM, "Charlie Mordant"  wrote:

> Hi,
> You can reference your services with service listeners (bind and unbind)
> to overcome this issue. Doing this, you won't encounter that issue
>
> Regards,
>
> 2015-04-05 0:33 GMT+02:00 Ryan Moquin :
>
>> Out of curiosity, sometimes if I do a global refresh with Karaf 3.0.3, it
>> will appear to reload everything, even the ssh bundle.  When that happens
>> sometime the Karaf features bundle will fail to refresh which causes other
>> Karaf bundles to be shutdown.  I'm not sure what causes this (it seems like
>> using the Karaf shutdown shutdown command to clean the data directory or
>> the bundle cache seems to cause a similar problem).  Are there any known
>> issues that would cause this?  If not, I'll see if I can find a
>> reproducible example of this.  Unfortunately, I seem to run into a lot of
>> trouble with shutdown and the restart option.  I guess I want to make sure
>> there isn't anything known, otherwise I'll see if I can come up with some
>> examples.
>>
>> Ryan
>>
>> On Fri, Feb 27, 2015 at 12:10 AM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Global refresh could be a good advice to re-wire the packages.
>>>
>>>
>>> On 02/26/2015 11:05 PM, asookazian2 wrote:
>>>
 ok what about refresh, restart, resolve after update?  are those
 recommended/required?



 --
 View this message in context: http://karaf.922171.n3.nabble.
 com/bundle-update-tp4038534p4038716.html
 Sent from the Karaf - User mailing list archive at Nabble.com.


>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>

Re: Deploying applications on Karaf

[Ryan Moquin]

Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
deployment flexibility using features feels a little tougher than it feels
like it should be (I don't have any better ideas).  I also have issues with
my Karaf integration tests in Bamboo.  Paxexam seems to not be able to
initialize properly for who knows what reason.  Another problem is that I
seem to run into a lot of problems in the tests and can't seem to find
anything in the output or Karaf love that indicate.the problem.  If I run
it normally in Karaf, I usually get clued into what the issue is.

One last thing is that since my development shop uses MacOSx, Docker
containers have to be run in a VM which feels silly and is slow.  I don't
have a choice in that manner.

It would be nice if there was a way to manage feature xml files in a way
that felt more straight forward  Maybe there is and I'm just not aware
of it.
On Apr 8, 2015 3:07 PM, "Achim Nierbeck"  wrote:

> Hi,
>
> just recently for a talk with showcase I was thinking about how to create
> a CI/CD build pipeline with Karaf. Maybe some of this does help you.[1]
> In the end I ended up with a setup where I have a pre-configured Karaf
> (custom build) which is startable as Docker Image or can be used as startup
> tar.gz of the Pax Exam integration tests.
> Usually camel routes are more about Integration therefore the most
> use-cases need to be handled by Integration tests. In those scenarios you
> just can't rely only on the camel-core bundles therefore you need more
> features just to have your unit tests/integration tests runnable. In those
> scenarios I usually suggest build your own distribution on top of Karaf and
> use it as your base-image in the pax-exam tests. If there is more external
> infrastructure needed I tend to use either full-integration test systems or
> now a docker based test-environment which can be started via a maven goal
> as pre-intergration phase systems.
>
> regards, Achim
>
> [1] - https://github.com/ANierbeck/JavaLang-Tooling
>
> 2015-04-08 17:24 GMT+02:00 Ryan Moquin :
>
>> Hi,
>>
>> I have another question regarding Karaf and deployments.  I was hoping
>> maybe some others could chime in on how they deal with the following
>> situation.
>>
>> I've been working on a fairly complex Karaf based application.  I'm using
>> features heavily to allow deploying the correct resources in different
>> environments (configuration and bundles).  I find it works very well except
>> for a couple situations:
>>
>> 1.  Unit testing.  It's hard to unit test things like camel routes since
>> I have ended up basically marking all bundle dependencies as provided (in
>> order to keep the created features files .  So if I try to unit test a
>> Camel route, transitive dependencies have to be directly added to the
>> project pom.
>>
>> 2.  I have all my configurations defined in a maven project for
>> assembling the final features xml file.  This of course doesn't make it
>> easy to use any of those configurations in camel integration tests since
>> configurations needed for config admin would have to be added to the
>> projects test resources.
>>
>> Obviously the two brief examples above focus mostly on Camel, but the
>> main problem is that I'm trying to figure out how I can no longer make
>> everything provided in my bundle project provided scope without having to
>> manually maintain the features files.
>>
>> That being said, I was looking at Apache Ace, but I'm not sure if using
>> Apache Ace would cause it to be more work to do Karaf integration testing
>> since Apache Ace doesn't use Karaf features.  I thought about maybe using
>> OBR, but we use Artifactory and so I'm not sure if going down the OBR route
>> might ultimately not be possible (I could be wrong but Artifactory doesn't
>> appear to have OBR support), also I read that OSGi has moved away from OBR
>> to different repository mechanism (forget offhand what it's called).  I
>> looked into Apache Cave, but I don't want to rock the boat where I'm at yet
>> since I'm the only one pushing Karaf and OSGi currently.  I don't want to
>> try to push things out of my organizations comfort zone by getting too
>> radical in my project deployment.  I haven't gotten to read into the Karaf
>> 4.0 profiles yet.
>>
>> What it really boils down to is that I'm not sure which deployment
>> approach with Karaf would be the best to use out of all the options with
>> the goal of moving to a continuous deployment model.
>>
>> Hoping someone might be willing to comment on how they solved these
>> issues or maybe what direction I should look at going down that will allow
>> me to improve these aspects.  It took me a while to get things where they
>> are at, I want to be pretty confident in what path I go down next since if
>> it doesn't pan out, it will be a lot of potentially wasted time and effort.
>> :)
>>
>> Thanks in advance for any thoughts/suggestions.
>>
>> Ryan
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf 

Re: Karaf and Docker

[Ryan Moquin]

I used to work somewhere with other developers who always became very
spiritual about whatever the latest "cool" developer technology or
methodology is.  Microservices was one of them.  It always made me laugh
when I was told how super efficient and streamlined it was over any other
solution because every fat jar deployed (Maven shade plugin abuse in order
to be lazy) was between 500Mb and 1.7Gb.  So much for being a
"micro"-service.
On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:

> I'm very ambivalent regarding this topic.
>
> On one hand I see a lot of move to Docker as heading for the holy grail on
> fixing all the issues we had in the past. #FAIL
> On the other hand I see some benefits of it, but still haven't found the
> concrete use-case where it did top a bar-metal or bare virtualized machine.
>
> It's absolutely true that it does have some benefits for easier deployment
> of "Infrastructure" but I also see a lot of failures in usage of Docker.
> Just to mention one, where did the init daemon go, it's been there for a
> reason in linux OS's and now we run applications on top of the system
> without it ... I don't feel comfortable with that, especially if you don't
> have a JVM as process running which starts spawning other processes (one
> might remember the zombie processes).
> In the end there are mostly more slopy/lazy people around[1] trying to get
> something going, that's why Docker will be sufficient enough, while the
> dynamic and re-configurable service oriented software architecture will be
> on the decrease. One just needs to follow that Microservice hype.
> Docker/SpringBoot are just part of this "mantra" :D
> In the end people will just split their Monolithic rubbish up to different
> small Monolithic piles of rubbish, but in case one of them is failing,
> they'll end up with one big failing pile of rubbish.
>
> Besides this rant, I think building a custom Karaf with your application
> on top, distributable as Docker image. Or as I did for a showcase building
> a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a
> good combination. As long as it's possible to configure the services inside
> this docker image from the outside.
>
> regards, Achim
>
> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html
>
>
> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu :
>
>> I agree, I do feel that vibe from time to time, mostly due to the
>> 'containers should be immutable' mantra.
>>
>> In my opinion, if you can get away with it, make it as dynamic as you
>> want, but I guess we all know that building an application that can be
>> reconfigured + updated on the fly is not easy at all.
>>
>> Anyway, while we're at it, I also wrote a few posts about OSGi + Docker,
>> with quite a different approach: I explore monitoring the Docker API to
>> discover services, and inject those services as OSGi configuration data:
>>
>> http://www.codemonkey.nl/discovery/
>>
>> I think OSGi and Docker can complement each other very nicely.
>>
>> regards, Frank
>>
>> On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin 
>> wrote:
>>
>>> Don't get me wrong, I don't mean that Docker and Karaf are
>>> interchangeable.  I mean that it feels like, from quite a few things I
>>> read, that the trend may be to have a docker image built as part of every
>>> CI build.  The purpose being that deployments should be fully immutable and
>>> if changes need to be made, then a new Docker image should be generated and
>>> deployed.
>>>
>>> One particular conversation that I felt really expressed this type of
>>> development track is this one:
>>>
>>> https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk
>>>
>>> Fabric8 used to be fully built on Karaf but has changed the approach to
>>> support other runtimes.  Nothing is wrong with that, but if that pattern
>>> becomes a trend, then it feels that many of the nice features of Karaf will
>>> become "discouraged" and I can't see them being furthered in Karaf at that
>>> point.
>>>
>>> I love Karaf and everything it offers.  I'm just a little concerned
>>> about how Docker is being pushed and the mindset that seems to evolving
>>> around it.  The point is, I'm hoping that because Docker is immutable, that
>>> it doesn't cause all software development to shoot to be immutable.
>>>
>>> Hopefully that makes sense. :)  Lots of new technologies allow
>>> developers to know less about software development and to write sloppier
>>> code because they can get away with it.  While building things faster and
>>> minimizing redundant or error prone tasks is great.  I guess I'm a little
>>> concerned about how Docker can be misused and the effect it could have.
>>>
>>> Hopefully that makes sense :)  I have no problem embracing Docker as a
>>> container to run Karaf in, I'm just hoping Docker doesn't become a
>>> liability or stifler to Karaf.
>>>
>>> These of course are only my opinion of the research I've been doing on
>>> and off.  I may be completely off the mark or mis

Re: Karaf and Docker

[Ryan Moquin]

Exactly, my point being that even though it's not easy to update things at
runtime, I don't want Docker to stop us from trying to achieve that goal
and keep innovating.
On Apr 8, 2015 11:35 AM, "Frank Lyaruu"  wrote:

> I agree, I do feel that vibe from time to time, mostly due to the
> 'containers should be immutable' mantra.
>
> In my opinion, if you can get away with it, make it as dynamic as you
> want, but I guess we all know that building an application that can be
> reconfigured + updated on the fly is not easy at all.
>
> Anyway, while we're at it, I also wrote a few posts about OSGi + Docker,
> with quite a different approach: I explore monitoring the Docker API to
> discover services, and inject those services as OSGi configuration data:
>
> http://www.codemonkey.nl/discovery/
>
> I think OSGi and Docker can complement each other very nicely.
>
> regards, Frank
>
> On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin 
> wrote:
>
>> Don't get me wrong, I don't mean that Docker and Karaf are
>> interchangeable.  I mean that it feels like, from quite a few things I
>> read, that the trend may be to have a docker image built as part of every
>> CI build.  The purpose being that deployments should be fully immutable and
>> if changes need to be made, then a new Docker image should be generated and
>> deployed.
>>
>> One particular conversation that I felt really expressed this type of
>> development track is this one:
>>
>> https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk
>>
>> Fabric8 used to be fully built on Karaf but has changed the approach to
>> support other runtimes.  Nothing is wrong with that, but if that pattern
>> becomes a trend, then it feels that many of the nice features of Karaf will
>> become "discouraged" and I can't see them being furthered in Karaf at that
>> point.
>>
>> I love Karaf and everything it offers.  I'm just a little concerned about
>> how Docker is being pushed and the mindset that seems to evolving around
>> it.  The point is, I'm hoping that because Docker is immutable, that it
>> doesn't cause all software development to shoot to be immutable.
>>
>> Hopefully that makes sense. :)  Lots of new technologies allow developers
>> to know less about software development and to write sloppier code because
>> they can get away with it.  While building things faster and minimizing
>> redundant or error prone tasks is great.  I guess I'm a little concerned
>> about how Docker can be misused and the effect it could have.
>>
>> Hopefully that makes sense :)  I have no problem embracing Docker as a
>> container to run Karaf in, I'm just hoping Docker doesn't become a
>> liability or stifler to Karaf.
>>
>> These of course are only my opinion of the research I've been doing on
>> and off.  I may be completely off the mark or misinterpreting things.
>>
>> Ryan
>>
>> On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak <
>> vincent.zurc...@linagora.com> wrote:
>>
>>>  Hi,
>>>
>>> I don't know if we can really compare Karaf and Docker.
>>> I use OSGi to build modular applications. My bundles are Java modules
>>> that I can assemble in one way or another. And I use Karaf to create a
>>> custom distribution of my OSGi applications. It is a developer thing.
>>>
>>> Now, I use Docker to execute applications in an isolated container on a
>>> machine.
>>> Even on VM, running Docker can simplify support and debug for
>>> applications. The fact we can isolate things is very helpful for that. And
>>> it is convenient to maximize the usage of VM resources.
>>>
>>> I do not see how one could replace the other.
>>> BTW, I already run Karaf in Docker containers. And one of our OSGi
>>> applications (which runs in Karaf) can create and interact with Docker
>>> containers. So, you can make both of them together when you need.
>>>
>>>
>>> Le 08/04/2015 14:31, Ryan Moquin a écrit :
>>>
>>> I kind of feel like the big push of Docker in the development community
>>> in general (as a whole, not talking about the Karaf developer community),
>>> will potentially cause a lack of innovation and improvements in the
>>> deploying of applications.  Docker could become a crutch.  If an
>>> application is slowly leaking memory over a 24 hour period, why fix it?
>>> When it crashes, just replace it with a new instance.
>>>
>>>
>>> May I say that cloud computing and virtualization in general already
>>> setup this kind of approach?
>>> When a VM or a container has a problem, it may indeed be more simple to
>>> launch a new one, reconfigure your application to use it and kill the old
>>> one. But this is not new at all. And there are some little things to deal
>>> with, like reconfiguration. Docker works the same, at its level. And even
>>> if you can create new containers, the less procedures you have in
>>> production environments, the better it is. So, having applications with
>>> 99,99% uptime will always be better.
>>>
>>> BTW, Docker also has some limitations (with systems services as an
>>> example).
>>> S

Re: Karaf and Docker

[Ryan Moquin]

That's been my view, it's something that can be used to make deployments a
little easier, not as a "I don't have to try to write decent,
non-monolithic code anymore".  A lot of others are vocally expressing this
sort of opinion.  It actually feels like a this sort of thing happens a
lot.  A new technology comes along, makes it easy to get a turd of a piece
of software up and running, magically everything goes out the window until
the fad passes.

I saw someone describe this sort of phenomena in a great way, wish I could
find it to quote him.  I certainly have no problem if others want to use
the latest fad, I don't like how people push the newest fad on everyone
rather than let people decide for themselves.
On Apr 8, 2015 11:12 AM, "Jean-Baptiste Onofré"  wrote:

> I see your point.
>
> But IMHO, I don't see anything new with Docker, just a easier or more
> convenient way to do what you do with Solaris Zone, Linux jail/xen, and vm
> like VirtualBox and vmWare ;)
>
> So, Docker itself doesn't provide an application container: it provides an
> system container.
>
> Of course, you can always start a Docker image with just a JVM for your
> application, for instance bootstrapping Jetty, etc. Or you can just
> bootstrap an application container (like Karaf ;)), ready to host your
> applications.
>
> My $0.02.
>
> Regards
> JB
>
> On 04/08/2015 04:58 PM, Ryan Moquin wrote:
>
>> I actually pop by your blob periodically to see if you have posted
>> anything new.  Your blog post on Karaf and Docker is initially what made
>> me want to look into and understand how Docker could benefit Karaf.  As
>> I've been reading other sources, I'm becoming less optimistic about how
>> Docker benefits Karaf.
>>
>> As Vincent mentioned, cloud computing and virtualization are already
>> using a similar approach.  I guess I'm wondering why we need to add yet
>> another virtualization container on top of another.
>>
>> Ryan
>>
>> On Wed, Apr 8, 2015 at 10:12 AM, Jean-Baptiste Onofré > > wrote:
>>
>> Hi Ryan,
>>
>> I invite you to read my blog about Karaf and Docker:
>>
>> http://blog.nanthrax.net/2014/__12/apache-karaf-christmas-__
>> gifts-docker-io-profiles-and-__decanter/
>> > christmas-gifts-docker-io-profiles-and-decanter/>
>>
>> and the Karaf Docker proposal:
>>
>> http://karaf.922171.n3.nabble.__com/DISCUSSION-Karaf-docker-
>> __io-td4038470.html
>> > docker-io-td4038470.html>
>>
>> Regards
>> JB
>>
>>
>> On 04/08/2015 02:31 PM, Ryan Moquin wrote:
>>
>> Hi,
>>
>> I've been reading up on Docker and trying to understand what all
>> the
>> fuss is about  (I'm still not sure for several reasons, but I
>> digress).
>> I was wondering how Docker might influence Karaf in the future
>> as well
>> as how Docker fits in with OSGi and Karaf in general.
>>
>> Specifically my questions are:
>>
>> 1.  It seems like the hype of Docker is causing people to shy
>> away from
>> the dynamic nature of OSGi, such as being able to update bundles
>> in a
>> running Karaf container.  Is the use of Docker and Karaf boiling
>> down to
>> creating a static Karaf image and anytime you want to upgrade
>> anything,
>> you throw away the instance and replace it with a newly built
>> instance?
>> It feels inefficient.  It also feels like it really complicates
>> everything.  Unless you are developing on Linux, development using
>> Docker containers is really slow.  Dealing with setting up docker
>> containers to test things out locally also seems like a lot of
>> overhead.  If you don't test locally with Docker, then can you
>> be sure
>> that deploying in a Docker container will work properly?
>>
>> 2.  In regards to the first question, and the fact that people
>> indicate
>> they think Docker will become the standard, will Karaf be dumbed
>> down in
>> the future due to the static nature of Docker?  Meaning, if Docker
>> *does* becomes the de factor standard for deploying everything,
>> it feels
>> like developers would be discouraged from using a lot of the
>> run-time
>> benefits OSGi offers.
>>
>> I kind of feel like the big push of Docker in the development
>> community
>> in general (as a whole, not talking about the Karaf developer
>> community), will potentially cause a lack of innovation and
>> improvements
>> in the deploying of applications.  Docker could become a
>> crutch.  If an
>> application is slowly leaking memory over a 24 hour period, why
>> fix it?
>> When it crashes, just replace it with a new instance.
>>
>> 

Re: Karaf and Docker

[Ryan Moquin]

Hi Charlie, I completely agree with you.  I'm glad that there are others
that have the same opinion.  I'm fine using Docker.  I don't want to see
great technologies go away because developers can use something like Docker
as a way to get away with write crap code.
On Apr 8, 2015 4:45 PM, "Charlie Mordant"  wrote:

> My 2 cents on this:
>
> On one side, you've the way to build real modular application the right
> way, you just have to have a brain to do this, and its going simpler and
> simpler with Karaf, bnd, and all Ops4j work.
>
> On the other side, you can mimic a nearly modular architecture, lowering
> the problem on the infrastructure side.
> * You'll never be able to build real modular application, you'll never be
> able to have multiple version of the same product together, you'll never be
> able to hotswitch your services (or you'll use kubernete, chef or another
> provisioning tool, but it will always be harder than using OSGI itself).
> * You'll also never be able to upgrade your app, just replacing an older
> by a newer (so no automatic provision by Nexus listening).
> * Your apps will always be as crappy as the previous one: no api/impl
> package distinction, no intra vm services (and http ones like spring boot
> add a non negligible overhead).
> * All your 'microservices' will be 20mo sized (embedding tomcat and
> spring-beans/context/boot has a cost). As an addition, all the
> configuration will be duplicated (and slightly different) in all that
> services.
>
> So, the choice is in your hands: coding well and really modular or coding
> crappy and maintaining a hard-to-maintain infrastructure.
>
> Real Microservices architecture is here with Karaf/Camel, not with
> Spring-boot and Docker. I hope people won't be cheated on the commercial
> and hype on these wrong solution.
>
> I'm not against docker, I use this to provision ldap, ELK, Mail servers,
> etc... They're just not suited for micro services (and for Spring boot, I
> consider it always be better than JavaEE, but far from OSGI).
>
> 2015-04-08 20:54 GMT+02:00 Achim Nierbeck :
>
>> I'm very ambivalent regarding this topic.
>>
>> On one hand I see a lot of move to Docker as heading for the holy grail
>> on fixing all the issues we had in the past. #FAIL
>> On the other hand I see some benefits of it, but still haven't found the
>> concrete use-case where it did top a bar-metal or bare virtualized machine.
>>
>> It's absolutely true that it does have some benefits for easier
>> deployment of "Infrastructure" but I also see a lot of failures in usage of
>> Docker. Just to mention one, where did the init daemon go, it's been there
>> for a reason in linux OS's and now we run applications on top of the system
>> without it ... I don't feel comfortable with that, especially if you don't
>> have a JVM as process running which starts spawning other processes (one
>> might remember the zombie processes).
>> In the end there are mostly more slopy/lazy people around[1] trying to
>> get something going, that's why Docker will be sufficient enough, while the
>> dynamic and re-configurable service oriented software architecture will be
>> on the decrease. One just needs to follow that Microservice hype.
>> Docker/SpringBoot are just part of this "mantra" :D
>> In the end people will just split their Monolithic rubbish up to
>> different small Monolithic piles of rubbish, but in case one of them is
>> failing, they'll end up with one big failing pile of rubbish.
>>
>> Besides this rant, I think building a custom Karaf with your application
>> on top, distributable as Docker image. Or as I did for a showcase building
>> a base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a
>> good combination. As long as it's possible to configure the services inside
>> this docker image from the outside.
>>
>> regards, Achim
>>
>> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html
>>
>>
>> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu :
>>
>>> I agree, I do feel that vibe from time to time, mostly due to the
>>> 'containers should be immutable' mantra.
>>>
>>> In my opinion, if you can get away with it, make it as dynamic as you
>>> want, but I guess we all know that building an application that can be
>>> reconfigured + updated on the fly is not easy at all.
>>>
>>> Anyway, while we're at it, I also wrote a few posts about OSGi + Docker,
>>> with quite a different approach: I explore monitoring the Docker API to
>>> discover services, and inject those services as OSGi configuration data:
>>>
>>> http://www.codemonkey.nl/discovery/
>>>
>>> I think OSGi and Docker can complement each other very nicely.
>>>
>>> regards, Frank
>>>
>>> On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin 
>>> wrote:
>>>
 Don't get me wrong, I don't mean that Docker and Karaf are
 interchangeable.  I mean that it feels like, from quite a few things I
 read, that the trend may be to have a docker image built as part of every
 CI build.  The purpose be

[ANN] Apache Karaf 2.3.11 Released!

[Jamie G.]

The Karaf team is pleased to announce the release of Karaf version 2.3.11.

Apache Karaf is a small OSGi distribution which provides a ready to
use container for server side applications.

This is an update patch for Apache Karaf 2.3.x, containing several bug
fixes. Amoung them are a fix for password encryption, txlog files
locked during admin clone on windows, and an issue with using
LDAPLoginModule with ActiveDirectory is resolved.

http://karaf.apache.org/

This release is available from
http://karaf.apache.org/index/community/download.html#Karaf2.3.11 and

Maven:

 
 org.apache.karaf
 apache-karaf
 2.3.11
 

Download Note:
Our mirrors are still syncing the new kits, if your primary mirror
does not have the kit please try another from the server mirror list.

Release Notes:

There are 7 resolved issues included in this release, as such we've
documented them on the 2.3.11 release notes page:
http://karaf.apache.org/index/community/download/karaf-2.3.11-release.html

Enjoy!