Migrate to mhus-osgi-tools 1.6.3

In osgi tools 1.6.3 are some breaking changes.

To divide api from implementation I created a new project mhu-osgi-api and moved the api interfaces and utilities into to new project. Therefore the package declaration of classes changed.

To fix it in dependent classes it is necessary to organise imports again. In Eclipse this is simply by using the function for the complete source folder. Before you do it you have to change the dependency artefact. Change in you pom from mhu-osgi-services to mhu-osgi-api.

One more change is to do. If you define jms data sources in a blueprint. You have to change the used interfaces and classes.

I found only the following changes to do:

"" to
"" to

vaadin 14 with osgi and karaf

After vaadin changed to the new flow technology it needs more effort to migrate to a new major version then 8.

In my case it means to test how to get vaadin in karaf working.

Unfortunately there is no direct karaf support in vaadin and there is no example or documentation how to do it. But I found OSGi support since vaadin 13. An example project was not working as described in the documentation ( Even with different branches and tags I get dependency exceptions in the OSGi framework.

So I started creating a new configuration and project from scratch.

I used my docker image with karaf 6.2.6 installed and java 11.0.3 to create a sample project and a bundle configuration.

You can checkout the project within my example project ( in folder vaadin-flow/mhu-vaadin-examples1. Compile the sources with maven:

git clone
cd mhus-examples/vaadin-flow/mhu-vaadin-examples1

Migrate to vaadin 8

Since Vaadin 7 will no more supported in 2019 I need to migrate to a newer version of the library. I migrated to Vaadin 8 in mhu-lib 3.4.0, mhu-osgi-tools 1.4.3 and mhu-ports 1.3.6.

The new version no more supports tables (I will discuss pro and contra in another post) but a set of legacy packages will do it for the moment. There are also some other changes but they are more or less handy.

The migration of the application can be done by a tool. The tool will modify all java imports to the new - correct - packages. I was using the standalone tool (alternatively you can use a maven goal). Download the sources from and compile the project afterwards you can use the jar file to migrate your projects. Change location into your project home directory and execute the jar file

java -jar $HOME/.m2/repository/com/vaadin/framework8-migration-tool/8.0-SNAPSHOT/framework8-migration-tool-8.0-SNAPSHOT.jar

If you use maven you need to change the vers…

uptime command for karaf

A tool that I love for unix is uptime. Showing the current and last runtimes. Now I invested 60 minutes to implement id in karaf also. Showing the current and last runtime records or the karaf server as the original.

Use 'uptime' to see the current records

karaf@root()> uptime  Status        | Runtime           | Start                     | Pid         | System               -------------------------------------------------------------------------------------------------- CLOSED        | 00 12:14:52       | 2018-08-03 22:26:43       | 24703       | 02 02:18:00         
CURRENT       | 00 00:39:39       | 2018-08-04 10:41:37       | 26418       | 02 02:58:00         
Using -u you can order it by uptime.
It also shows the system uptime and pid of the records. It's a nice tool for analysing.
Have fun ...

Modified Log Tail in karaf

A long time the command .mhu:log console' was created to tail the log from log file in runtime, means in the background while typing in the current session.

Now I created a new command 'mhus:logtail'. I copied the original 'log:tail' from and modified it to work in background.

The goal is that it will listen to the appenders and not to the log file. In this way it is possible to check the logging thread. With the option '-c' (console thread) it is possible to filter only log messages created by the current session thread. In this way you get feedback for your executed commands only and not all the logs of a running system.

Console madnes

It looks like it's not easy to recognise the console cols and rows in every case. After a period of continuous tries and fails I found that even the 'specialists' are not able to find the size of the console in every case. Just now I use jline to find the terminal size. But if you login into karaf using a ssh client it's not possible at all.

As reaction I created a console factory (as it should be) to create console instances for every thread and it's possible to overwrite the current used console instance. Now in karaf it's possible to use

console set

to set a session bound console instance which will recognise the size correctly by using the session instance.

Move foundation relevant data model entities into a separate project

mhu-sop/1.3.3: Up to now it was a must to have entities like SopFoundation or SopData in the database. For the most osgi instances this is not necessary. This is only a feature.

Therefore I moved the feature in a separate project mhu-sop-foundation. If the functionality is needed then deploy the bundle into osgi.

Note: The entities are always available in mhu-sop-api