Use Apache Karaf as a runtime container

[kaikreuzer]

No description provided.

[kaikreuzer]

Using Apache Karaf would bring a couple of features for openHAB:

• stable management scripts that also allow integration as a system service (e.g. on Windows or Linux)
• Integration with other OSGi-based applications such as Apache Camel, CXF and ActiveMQ
• provisioning through Karaf archives, so we could install addons from a remote repo easily.

Possible risks of this move:

• Karaf does not use logback for logging, so the logger implementation would change
• The size of the runtime increases as Karaf is not modular and comes with a lot of stuff which we would not need (e.g. Blueprint). This might be contra-productive on small systems like a RasPi 1.
• Having multi-instance possibilities and many console commands (which are different to the existing ones from Equinox) may make things more complicated for "regular" openHAB users.
• We are between the two worlds of Eclipse Equinox and Apache Felix - this might lead to unexpected problems.

If any expert on Karaf could comment on these risks, it would be great :-)

[watou]

I for one would like to see OH2 running in Karaf. While I'm no Karaf expert, I use it for Camel and I find it very easy to monitor and manage remotely. The only reason I can think of to not switch is if it expands the memory footprint more than a trivial amount, as there is already an uncomfortable size gap between OH1 and dedicated systems like Vera.

[maggu2810]

As I am already using Karaf for OH2 I prefer to support it mainline, too. ;-)

[kaikreuzer]

@maggu2810 Do you have any opinion about the concern of an increasing size and thus higher performance requirements? Does it e.g. still run on a RaspPi1?

[maggu2810]

Never tested it with a RespPi1.
If we use an "empty" Karaf framework, just using the stuff Karaf needs to
work, this should be the size the memory footprint increases.
Do you concern, that Karaf adds a lot of management information to every
bundle, so the memory footprint of every bundle increases?

2015-04-29 11:17 GMT+02:00 Kai Kreuzer notifications@github.com:

@maggu2810 https://github.com/maggu2810 Do you have any opinion about
the concern of an increasing size and thus higher performance requirements?
Does it e.g. still run on a RaspPi1?

—
Reply to this email directly or view it on GitHub
#194 (comment).

[kaikreuzer]

Do you concern, that Karaf adds a lot of management information to every
bundle, so the memory footprint of every bundle increases?

No, I don't think (hope!) that there will be any additional overhead per bundle - my concern is only the "base" that is added as Karaf has Spring/Blueprint as a mandatory part and a few other components that I think are not really relevant for an openHAB container, but cannot be removed from Karaf, so it feels like some unnecessary ballast.

[hakan42]

From karaf.apache.org:

Logging System: using a centralized logging back end supported by Log4J, Karaf supports a number of different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)

I seriously hope that we can bolt SLF4j underneath karaf as I would love to ship my OpenHab logs to a logstash server. Mainly, my OpenHab server is running on a Raspberry 2, and I want to avoid lots of log file writing on the small SD card if possible.

[kaikreuzer]

What I said is

Karaf does not use logback for logging, so the logger implementation would change

slf4j is the API, logback and log4j two possible logger implementations. openHAB currently uses logback and as far as I understand Karaf uses log4j.

[oliverlietz]

I'm interested in openHAB on Karaf/RasPi2. Karaf 4 will be released soon: The 4.0.x line will ship with OSGi Rev5 support via Felix 4.4.1 and Equinox 3.9.1-v20140110-1610, and a completely refactored internal framework without Blueprint for internal usage. From a users point of view these changes will yield a smaller, more efficient Karaf core.

[kaikreuzer]

Yes, I am already using 4.0.0M2 and waiting for M3 to be released soon. That Blueprint is optional now is a good thing!

[oliverlietz]

Can you provide a quickstart guide and/or Karaf Feature (compiling my own right now for use with EnOcean) to get SmartHome/openHAB up and running on Karaf? I've some spare time and would like to see openHAB, Karaf, RasPi 1/2, EnOcean Pi 868/EnOcean USB 300 and my PEHA Easyclick devices playing together finally.

[kaikreuzer]

@oliverlietz you have spare time? Sounds fantastic as I am currently struggling with Karaf and not getting much further...
You can have a look at my current state of things here: https://github.com/kaikreuzer/openhab2/tree/karaf.

In there, I have replaced the whole p2 feature build by one KAR: https://github.com/kaikreuzer/openhab2/tree/karaf/features/
This currently only includes one Karaf feature with only one bundle - this needs to be of course extended to include everything relevant.
In https://github.com/kaikreuzer/openhab2/tree/karaf/distribution/karaf I am trying to build a custom Karaf distribution, but so far I failed to include my own resources in src/main/resources.
In https://github.com/kaikreuzer/openhab2/tree/karaf/distribution/downloads, I want to assemble a final distributable - I actually plan to have Karaf within the "runtime" subfolder there, so that the openHAB user is not directly exposed to Karaf. But also on here I didn't yet succeed in extracting the custom Karaf distro into the right place.
So if you have any chance to help on these things, it would be great!

[kaikreuzer]

Btw, my goal is to have quite finegrained features, so that every addon can be installed as a feature individually as well as things like MQTT support, the Paper UI, HABmin, etc.

[maggu2810]

In https://github.com/kaikreuzer/openhab2/tree/karaf/distribution/karaf I am trying to build a custom Karaf distribution, but so far I failed to include my own resources in src/main/resources.

I changed your project pom to use Karaf 4.0.0.M2 instead of 4.0.0-SNAPSHOT (karaf.version).
The stuff of src/main/resources is used (the feature xmls, branding file in etc, ...) but e.g. config.properties seems to be overwritten again.

• .../distribution/karaf/target/assembly contains the normal karaf stuff
• .../distribution/karaf/target/classes contains the resources

So, perhaps we need to change who win, if a file is available in both locations.

Will have a brief look, if I found something that could help.

[maggu2810]

IMHO this is the related issue:
http://karaf.922171.n3.nabble.com/karaf-assembly-and-config-files-td4032040.html

[kaikreuzer]

I changed your project pom to use Karaf 4.0.0.M2 instead of 4.0.0-SNAPSHOT (karaf.version).

I switched from M2 to SNAPSHOT because of http://mail-archives.apache.org/mod_mbox/karaf-user/201504.mbox/%3C551E8912.1030006@imag.fr%3E:
2. The generated distribution archives have very fancy names:
pom.xml.tar.gz or pom.xml.zip! Apart from that, the content of the
distribution is just fine. I don't know if the configuration for
maven-karaf-plugin has changed, BUT this specific issue seems to be
solved in the trunk version: distributions names are back to normal (cf.
B.2).

[maggu2810]

You could try that one: kaikreuzer/openhab-addons@karaf...maggu2810:karaf
The config.properties is your one.

[maggu2810]

Wait a moment... ;-)

You have written:

In https://github.com/kaikreuzer/openhab2/tree/karaf/distribution/karaf I am trying to build a custom Karaf distribution, but so far I failed to include my own resources in src/main/resources.

and you have written:

I switched from M2 to SNAPSHOT because of ... the content of the distribution is just fine.

So, is the problem (config.properties of resources is overwritten by config.properties of karaf) already solved if you are using the SNAPSHOT?

[kaikreuzer]

Are you sure that the

    <resources>
        <resource>
            <directory>${basedir}/target/assembly</directory>
        </resource>
    </resources>

is required? That does not seem to make much sense...

[kaikreuzer]

and you have written: "... the content of the distribution is just fine."

No, this wasn't me, that was someone else reporting the problem about the pom.xml.zip filename.

So, is the problem (config.properties of resources is overwritten by config.properties of karaf) already solved if you are using the SNAPSHOT?

No, it isn't.

[maggu2810]

Are you sure that the ... is required?

I just tried to get a workaround for the problem and pushed it, so you can test it.
The intention was not to create a cleaned up commit that could be merged.
First I want to know, if your first problem could be solved.

But yes, it seems that the lines are required to prevent creation of target/classes.

Feels very hackish.

It feels also very strange, that we have to use filtered=true if we want to overwrite the files.

[oliverlietz]

I'm maintaining Sling's Karaf Features and have something similar in mind for my SmartHome/openHAB features - so features first, custom distribution second.

I had to set version of org.osgi.service.http in Dashboard UI's MANIFEST.MF to 1.2.0 (was 1.2.1) to start in K4M2. Any reason why it is 1.2.1?

The last time I played with openHAB was in 2013. Is the EnOcean support now useable? Any hints to get quick results? Seeing/receiving signals from my switches in openHAB connected to EnOcean Pi 868/EnOcean USB 300 would be sufficient.

[kaikreuzer]

I'm maintaining Sling's Karaf Features and have something similar in mind for my SmartHome/openHAB features - so features first

Sounds good - having someone with experience defining the features is great! Btw, what do you think: Should we also define Karaf features on the Eclipse SmartHome side (such as "esh-core", "esh-rest", "esh-dsl" etc. and include them in openHAB 2 features? Or would you suggest to define all of them only within openHAB for the moment?

I had to set version of org.osgi.service.http in Dashboard UI's MANIFEST.MF to 1.2.0 (was 1.2.1) to start in K4M2. Any reason why it is 1.2.1?

Not at all, I have removed it now: a802790

Is the EnOcean support now useable?

It works pretty well with the 1.x EnOcean binding through the compat layer - I am using it myself regularly for demos with the PTM210. But better ask @maggu2810, he is the better expert for EnOcean :-)

[kaikreuzer]

IMHO this is the related issue:
http://karaf.922171.n3.nabble.com/karaf-assembly-and-config-files-td4032040.html

Indeed - unfortunately, there is no solution... Thanks for posting the problem at https://issues.apache.org/jira/browse/KARAF-2742

[maggu2810]

Should we also define Karaf features on the Eclipse SmartHome side (such as "esh-core", "esh-rest", "esh-dsl" etc. and include them in openHAB 2 features?

I think we should have a look at the overhead to maintain that all. At the moment there are still some difference between Tycho and the Eclipse IDE (at least for the karaf console bundle).
Personally I would like to have such features but perhaps we could solve this for OH2 first and then have a look at ESH...

But better ask @maggu2810, he is the better expert for EnOcean

@oliverlietz, We should not mix the topics in this issue. Contact me if you want some information, my email address should be visible.

Indeed - unfortunately, there is no solution...

Doesn't the very ugly workaround / hack (filtered resources, ...) work for you?

Thanks for posting the problem at

You're welcome.

[maggu2810]

One thing seems to be solved (http://karaf.922171.n3.nabble.com/4-0-0-M2-feature-install-system-bundle-td4040561.html).
Got the next one: http://karaf.922171.n3.nabble.com/custom-distribution-features-tc4041246.html

[maggu2810]

It seems to be known, so let's wait for the fix...

• http://karaf.922171.n3.nabble.com/custom-distribution-features-tp4041246p4041263.html
• https://issues.apache.org/jira/browse/KARAF-3805

[maggu2810]

So, I started again to move openHAB 2 to a Karaf based distribution.
You could have a look at my development branch at https://github.com/maggu2810/openhab2/tree/master-for-karaf

[maggu2810]

I think the migration to the Karaf container is in a working state for a review.
The common stuff is working.
At the moment there is just one thing that NEEDS to be solved. Is there someone that could help?
See the karaf-todo.md file in the branch (it's the starting problem).

[maggu2810]

Okay, I know the source of the problem, will report it to ESH.

[maggu2810]

Problem solved with eclipse-archived/smarthome#446

[dvanherbergen]

3 questions:

1. What is the current status of the work
2. Where is it? https://github.com/maggu2810/openhab2/tree/master-for-karaf gives a 404.
3. How can I help?

[kaikreuzer]

1. Grab it from here and have a look yourself: https://openhab.ci.cloudbees.com/job/openHAB2-Karaf/
2. Right here in this repo: https://github.com/openhab/openhab2/tree/karaf
3. We are tracking issues here: https://github.com/openhab/openhab2/labels/karaf. Not that many entered at the moment, @maggu2810 is doing a lot of further preparation work. @maggu2810, any idea what Davy could best help on right now?

[maggu2810]

@dvanherbergen contact me and I will give you further instructions, how you could work with my current development branch

[maggu2810]

• pull requests to get the karaf branch up to date are fine all the time
• a jetty.xml configuration that works with Pax Web and offers the same function as the current ones bundles in the oh2-jetty bundle

[dvanherbergen]

@kaikreuzer I'll start working on pull requests to get karaf branch inline with the master, so you don't have to spend time on that for now.

[maggu2810]

@kaikreuzer Please add the karaf tag
@dvanherbergen as long as #519 is not merged into the upstream karaf branch, you should base your work (the master merges) on "maggu2810:karaf-features" (the branch that should be merged). It will prevent us for a lot of additional conflicts later (IMHO)

[kaikreuzer]

@dvanherbergen Great to have you back on board at openHAB :-)
Main effort when merging the master is to define the features (incl. the cfg files) for the new and changed add-ons. Let us know, if there are any questions.

[dvanherbergen]

@kaikreuzer glad to be back. I'll give it a go, if I get stuck, you will hear about it..

[kaikreuzer]

Note that I have just merged #519, so you should be fine to work here on the Karaf branch and don't have to use @maggu2810's fork.

[dvanherbergen]

Thanks!

[maggu2810]

#521 should merge the current master.
Next step, jetty configuration...

[dvanherbergen]

@maggu2810 There is a first version of the jetty config available here https://github.com/dvanherbergen/openhab2/commit/55772bea5ff5254eecfa4320371ff5908ec2c439
Two things are still missing:

• the jetty deployment manager config, not sure if we still need this though
• advanced ssl config like ExcludeCipherSuites. Basic ssl is working.

[kaikreuzer]

the jetty deployment manager config, not sure if we still need this though

Imho we should leave out the whole web application support. The only thing to consider might be an optional folder for serving static content, see #311.

[kaikreuzer]

Done and available at https://github.com/openhab/openhab-distro