Yes, my proposal is the output would be one distribution with multiple configuration profiles that the user selects via config or startup.
> On May 7, 2026, at 10:13 PM, Jean-Baptiste Onofré <[email protected]> wrote: > > If the output is a distribution that works for me. We cannot ask the users > to do the assembly. In my opinion it’s over engineered compared to > distributions as we do today. > > Regards > JB > > Le jeu. 7 mai 2026 à 19:13, Matt Pavlovich <[email protected]> a écrit : > >> Correct. That’s my point — store all the etc/ contents for each ‘distro’ >> in separate folders and change the ${karaf.etc} as desired vs shipping a >> separate runtime. >> >> The startup scripts simply change the value of ${karaf.etc} to point to >> the appropriate profile/$foo/etc >> >> Example: Container would flip ‘distros’ by a simple env variable: >> >> KARAF_PROFILE = ‘default | minimal | mix | kservices' >> >> if [[ $KARAF_PROFILE (is not set or) eq ‘default’ ]] then >> karaf.etc = etc/ >> fi >> >> if [[ $KARAF_PROFILE eq ‘kservices’ ]] then >> karaf.etc = profiles/kservices/etc/ >> fi >> >> if [[ $KARAF_PROFILE eq ‘mix’ ]] then >> karaf.etc = profiles/mix/etc/ >> fi >> >> if [[ $KARAF_PROFILE eq ‘minimal’ ]] then >> karaf.etc = profiles/minimal/etc/ >> fi >> >> .. and so on >> >> I think trying to package local offline repositories is a challenge >> (especially with Camel). Instead, we can rely on the tooling and examples >> to ship things like a ‘apache-cxf-rest-repo’ , >> ‘apache-activemq-broker-repo’ that is a local-repo/ folder zipped up that >> can be injected into a container or overlayed during assembly. >> >> Matt Pavlovich >> >>> On May 7, 2026, at 11:13 AM, Jean-Baptiste Onofré <[email protected]> >> wrote: >>> >>> The etc content is not the same. >>> >>> Le jeu. 7 mai 2026 à 17:38, Matt Pavlovich <[email protected]> a >> écrit : >>> >>>> Example: >>>> >>>> Use a cli flag and/or a setenv/env var to flip the ‘profile’ or >>>> ${karaf.etc} >>>> >>>> etc/ <— default ‘Karaf’ today configurations >>>> >>>> profiles/minimal/etc <— karaf minimal >>>> profiles/mix/etc <— karaf mix >>>> profiles/kservices/etc <— Karaf-based services >>>> >>>> This would allow for _all_ settings to be swapped in/out— cover system >>>> properties, encrypted properties, cfg files (aka CXF, jetty, etc) >>>> >>>> >>>> >>>>> On May 7, 2026, at 10:00 AM, Matt Pavlovich <[email protected]> >> wrote: >>>>> >>>>> How about instead of separate distros it is separate profiles or >>>> configuration ’sets’ within one distribution tar.gz/zip/container? Pax >> vs >>>> Karaf services are really just a list of features. >>>>> >>>>> My understanding is that the only difference between Karaf and minimal >>>> is the boot features. Seems like that could be a property and we could >>>> simply have different folders of the configurations defined — >> featuresBoot, >>>> feature repositories added at boot time, etc. >>>>> >>>>> That would be much easier to manage, document and maintain vs separate >>>> archives. >>>>> >>>>> -Matt >>>>> >>>>>> On May 7, 2026, at 9:36 AM, Jean-Baptiste Onofré <[email protected]> >>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks everyone for your feedback. >>>>>> >>>>>> Here's the latest iteration about distribution names, incorporating >> your >>>>>> input: >>>>>> >>>>>> - Apache Karaf: same as today ("full" features service, PAX services) >>>>>> - Apache Karaf Minimal: same as today (Apache Karaf but with less boot >>>>>> features) >>>>>> - Apache Karaf Light ("simple" features service, Karaf services) >>>>>> - Apache Karaf Mix (based on Karaf, with ServiceMix flavor, e.g. >> Camel, >>>>>> ActiveMQ, ...) >>>>>> >>>>>> Does it work for everyone? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On Thu, May 7, 2026 at 3:43 PM Achim Nierbeck < >> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi JB, >>>>>>> >>>>>>> Thanks for the clarification, from the customer perspective I'd >> suggest >>>>>>> sticking to the current set for the std. Apache Karaf distribution. >>>>>>> The newer simplified version should be called as such. But as usual >>>> finding >>>>>>> names for variables and products is the hardest part in IT, I'll >> leave >>>> this >>>>>>> up to you ;) >>>>>>> Maybe something like "light". >>>>>>> Apache Karaf (TM) light >>>>>>> >>>>>>> Something that indicates by name, that you won't get the full >>>> experience >>>>>>> that you've been used to, when using Apache Karaf. >>>>>>> >>>>>>> Again, my two cents from the peanut gallery, just providing the idea >>>> of a >>>>>>> customer experience. >>>>>>> >>>>>>> regards, Achim >>>>>>> >>>>>>> >>>>>>> Am Do., 7. Mai 2026 um 14:05 Uhr schrieb Jean-Baptiste Onofré < >>>>>>> [email protected]>: >>>>>>> >>>>>>>> Hi Achim, >>>>>>>> >>>>>>>> The discussion centers on the turnkey distributions we provide to >> our >>>>>>>> users, whether they use them directly or build upon them. The goal >> is >>>> to >>>>>>>> provide opinionated distributions that better align with specific >> use >>>>>>>> cases. >>>>>>>> >>>>>>>> I strongly advocate for keeping "Apache Karaf" as the name for the >>>>>>> standard >>>>>>>> distribution. >>>>>>>> >>>>>>>> The main questions are: >>>>>>>> >>>>>>>> 1. Should the standard Apache Karaf distribution now use the >> "simple" >>>>>>>> features service and Karaf services by default? (Note: users could >>>> still >>>>>>>> switch to the "full" service via configuration). If so, should we >>>> still >>>>>>>> provide a distribution powered by the "full" feature resolver and >> Pax >>>>>>>> services as we do today? What should that distribution be named? >>>>>>>> >>>>>>>> 2. Alternatively, should the standard Apache Karaf distribution >>>> continue >>>>>>> to >>>>>>>> use the "full" features service and Pax services as it does today? >> If >>>> we >>>>>>>> choose this, should we provide an alternate distribution powered by >>>> the >>>>>>>> "simple" features service and Karaf services? What would we name >> that >>>>>>>> version? >>>>>>>> >>>>>>>> Regards, >>>>>>>> JB >>>>>>>> >>>>>>>> On Thu, May 7, 2026 at 12:01 PM Achim Nierbeck < >>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> looks like Grzegorz isn't the only one late to the part ;) >>>>>>>>> Let me be the advocatus diaboli: >>>>>>>>> >>>>>>>>> What are you trying to fix that needs fixing? >>>>>>>>> How are our "customers" looking at a name change? >>>>>>>>> What's in it for them? >>>>>>>>> >>>>>>>>> In case this is christal clear for everybody besides me, please >>>> proceed >>>>>>>> and >>>>>>>>> I'll go back to the peanut gallery. >>>>>>>>> >>>>>>>>> best regards, Achim >>>>>>>>> >>>>>>>>> >>>>>>>>> Am Do., 7. Mai 2026 um 08:50 Uhr schrieb Grzegorz Grzybek < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Late to the party, but I was triggered by "pax" label ;) >>>>>>>>>> I'm not sure I understand the brand "Karaf Pax"... is it about >>>>>>> bringing >>>>>>>>>> ops4j projects into/under Karaf umbrella? >>>>>>>>>> >>>>>>>>>> Speaking from Pax (Pax Logging, Pax Web, Pax URL in that order) - >> I >>>>>>>> don't >>>>>>>>>> have clear data about usage of these projects, but I'm sure these >>>> are >>>>>>>>>> sometimes used outside of Karaf. >>>>>>>>>> And after I got used to being one of the "old time" >>>>>>>>> maintainers/releasers, >>>>>>>>>> I can admit that somehow I drifted away from caps/reqs approach. >>>>>>> Sure - >>>>>>>>>> there are proper headers, but in my experience: >>>>>>>>>> >>>>>>>>>> - these are too incompatible with Maven artifacts (single artifact >>>>>>>>>> version = several libraries - like spring-core, spring-beans, ...) >>>>>>>>>> - in (my) practice (working on JBoss/RedHat Fuse since Fuse 6.1 >>>>>>>>> running >>>>>>>>>> on Karaf 2.3) it's more important to rely on particular version >>>>>>> of a >>>>>>>>>> Maven >>>>>>>>>> artifact (assuming proper Export/Import-Package) than on vague >>>>>>>> notion >>>>>>>>> of >>>>>>>>>> caps/reqs >>>>>>>>>> - CVEs!!!! it changed a lot over last ~10 years and the problem is >>>>>>>>> that >>>>>>>>>> security scanners do not scan packages or caps - they scan Maven >>>>>>>>>> artifacts >>>>>>>>>> >>>>>>>>>> I'm happy Karaf is evolving and I'm happy with any consensus that >>>>>>>> emerges >>>>>>>>>> ;) >>>>>>>>>> >>>>>>>>>> kind regards >>>>>>>>>> Grzegorz Grzybek >>>>>>>>>> >>>>>>>>>> czw., 7 maj 2026 o 08:16 Jean-Baptiste Onofré <[email protected]> >>>>>>>>>> napisał(a): >>>>>>>>>> >>>>>>>>>>> Cloud distro will have exactly the same features and >>>>>>> functionalities >>>>>>>> as >>>>>>>>>>> Karaf "PAX": the feature resolver is as the full one but not >> using >>>>>>>> the >>>>>>>>>>> rep/cap (just reading the features XML without guessing >>>>>>> resolution). >>>>>>>>> So, >>>>>>>>>>> users don't have to re-assemble at all: the resolution is still >> at >>>>>>>>>> runtime >>>>>>>>>>> but without using cap/req (it's basically like it was in Karaf >> 2.x >>>>>>>> kind >>>>>>>>>>> of). >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> JB >>>>>>>>>>> >>>>>>>>>>> On Wed, May 6, 2026 at 10:53 PM Łukasz Dywicki < >>>>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> Why not keeping just these two: >>>>>>>>>>>> - Apache Karaf >>>>>>>>>>>> - Apache Karaf Integration (or Mix as Jammie suggested) >>>>>>>>>>>> >>>>>>>>>>>> Having a minimal distro with shell (without ssh), OSGi + logging >>>>>>>>> isn't >>>>>>>>>> a >>>>>>>>>>>> bad idea. That's how OSGi framework usually starts. Still, given >>>>>>>> how >>>>>>>>>>>> many APIs nowadays apps need, I doubt if it will be used beyond >> a >>>>>>>> dry >>>>>>>>>>> run. >>>>>>>>>>>> There is bunch of variants for many of OSGi specs, some of them >>>>>>>>> coming >>>>>>>>>>>> from Eclipse, some from ASF and some from PAX. For example http >>>>>>>>> service >>>>>>>>>>>> can be pax-web, felix-http (or its servlet bridge), or equinox >>>>>>>> (http >>>>>>>>> or >>>>>>>>>>>> servlet bridge). I don't think its possible to create a variant >>>>>>> for >>>>>>>>>> each >>>>>>>>>>>> ecosystem, as number of combinations may grow faster than we >>>>>>> can >>>>>>>>>>>> supply them. >>>>>>>>>>>> Having atomic features which Jean mentioned in other thread >>>>>>> should >>>>>>>>>>>> really help users who need to assembly their own distribution >>>>>>> with >>>>>>>>> bits >>>>>>>>>>>> and pieces they like and work with. >>>>>>>>>>>> >>>>>>>>>>>> The "Cloud" distro with static resolver is basically unusable >>>>>>>> without >>>>>>>>>>>> re-assembling it with user application. So its better to keep it >>>>>>> as >>>>>>>>>>>> documentation / example rather than a release artifact. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Łukasz Dywicki >>>>>>>>>>>> >>>>>>>>>>>> On 5/6/26 21:57, Jamie G. wrote: >>>>>>>>>>>>> - Karaf PAX >>>>>>>>>>>>> - Karaf >>>>>>>>>>>>> - Karaf Mix >>>>>>>>>>>>> >>>>>>>>>>>>> (easy to see it's a semi continuation of servicemix). >>>>>>>>>>>>> >>>>>>>>>>>>> --Jamie >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, May 6, 2026 at 2:28 PM Romain Manni-Bucau < >>>>>>>>>>> [email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe bus instead of orchestration which has 2-3 other >>>>>>> meanings >>>>>>>> in >>>>>>>>>>>> nowdays >>>>>>>>>>>>>> world? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog >>>>>>>>>>>>>> <https://dotnetbirdie.github.io/> | Blog < >>>>>>>>>>>> https://rmannibucau.github.io/> | Old >>>>>>>>>>>>>> Blog <http://rmannibucau.wordpress.com> | Github >>>>>>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>>>>>>>> < >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 >>>>>>>>>>>>> >>>>>>>>>>>>>> Javaccino founder (Java/.NET service - contact via linkedin) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le mer. 6 mai 2026, 18:06, Jean-Baptiste Onofré < >>>>>>>> [email protected]> >>>>>>>>> a >>>>>>>>>>>> écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I understand the reasoning behind those names. My main >>>>>>> priority >>>>>>>>> is >>>>>>>>>>>> ensuring >>>>>>>>>>>>>>> that the names are explicit and that "Karaf Cloud" wouldn't >>>>>>> be >>>>>>>>>>>>>>> misinterpreted by our users. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That being said, I still have a slight preference for the >>>>>>>>>> following: >>>>>>>>>>>>>>> - Karaf PAX >>>>>>>>>>>>>>> - Karaf >>>>>>>>>>>>>>> - Karaf Orchestration >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, May 6, 2026 at 4:25 PM Francois Papon < >>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My thoughts was that >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Karaf OSGi => OSGi is used internaly and by users >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Karaf Cloud => OSGi is used internaly only and not by >>>>>>> userrs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The name "Cloud" was because it's focused on immutable >>>>>>>> resolver >>>>>>>>> at >>>>>>>>>>>> build >>>>>>>>>>>>>>>> time but I am ok with the others proposals. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> François >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le 06/05/2026 à 15:32, Jean-Baptiste Onofré a écrit : >>>>>>>>>>>>>>>>> Technically, (using your name), both Karaf OSGi and Karaf >>>>>>>> Cloud >>>>>>>>>> are >>>>>>>>>>>>>>> OSGi >>>>>>>>>>>>>>>>> internally. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Karaf Cloud looks a bit "weird" to me because it isn't >>>>>>>>>>>> cloud-specific. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Mixing your proposal and Romain's proposal, what about: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Karaf -> Karaf PAX >>>>>>>>>>>>>>>>> - Karaf Simple -> Karaf >>>>>>>>>>>>>>>>> - Karaf Integration -> Karaf Orchestration >>>>>>>>>>>>>>>>> - Karaf Minimal -> delete >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, May 6, 2026 at 1:47 PM Francois Papon < >>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> May be having : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Karaf > Karaf OSGi >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Karaf Simple > Karaf Cloud >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Karaf Integration > Karaf Orchestration >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think tagging the standard distribution as OSGi will >>>>>>> help >>>>>>>> to >>>>>>>>>>>>>>> abstract >>>>>>>>>>>>>>>>>> the OSGi part on the others distribution. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> François >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Le 06/05/2026 à 11:12, Jean-Baptiste Onofré a écrit : >>>>>>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Currently, we provide 3 Karaf distributions: >>>>>>>>>>>>>>>>>>> - Karaf >>>>>>>>>>>>>>>>>>> - Karaf Minimal >>>>>>>>>>>>>>>>>>> - Karaf Integration >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1. Karaf >>>>>>>>>>>>>>>>>>> This is our standard distribution, packaging the full >>>>>>>> feature >>>>>>>>>>>>>>>>>>> resolver/service (supporting cap/req), sshd, deployers, >>>>>>>>>>> diagnostic, >>>>>>>>>>>>>>>> kar, >>>>>>>>>>>>>>>>>>> wrapper, etc. >>>>>>>>>>>>>>>>>>> That's the de facto most used distribution. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2. Karaf Minimal >>>>>>>>>>>>>>>>>>> This is a very light distribution, packaging the full >>>>>>>> feature >>>>>>>>>>>>>>>>>>> resolver/service, config, local shell console, ... Hot >>>>>>>>>>> deployment, >>>>>>>>>>>>>>> etc >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> not packaged in this distribution by default. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3. Karaf Integration >>>>>>>>>>>>>>>>>>> This is based on the Karaf distribution, adding Apache >>>>>>>> Camel, >>>>>>>>>>>>>>> ActiveMQ >>>>>>>>>>>>>>>>>>> (similar to what was Apache ServiceMix). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Now, with the new feature service (simple resolver), and >>>>>>>> the >>>>>>>>>>> Karaf >>>>>>>>>>>>>>>>>> services >>>>>>>>>>>>>>>>>>> (Karaf URL, Karaf Web, etc), I propose creating a new >>>>>>>>>>> distribution >>>>>>>>>>>>>>>>>>> packaging the simple feature service (instead of the full >>>>>>>>> one, >>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> providing Karaf services instead of Pax services. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have two questions for you: >>>>>>>>>>>>>>>>>>> 1. Should we keep the Karaf Minimal distribution? I'm not >>>>>>>>> sure >>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> distribution is actually heavily used. >>>>>>>>>>>>>>>>>>> 2. Should we rename Karaf as Karaf "Full" and use Karaf >>>>>>> for >>>>>>>>> the >>>>>>>>>>> new >>>>>>>>>>>>>>>>>>> distribution (the one with the simple feature service and >>>>>>>>> Karaf >>>>>>>>>>>>>>>>>> services)? >>>>>>>>>>>>>>>>>>> Or should we keep the Karaf distribution as it is today >>>>>>> and >>>>>>>>>>>>>>> introduce a >>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>> distribution "Karaf Simple"? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> 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> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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> >>>>>>> >>>>> >>>> >>>> >> >>
