Last week I started replacing our forked Http Bridge with a more OSGi friendly and generic approach. I got to a point where it somewhat worked, but Vaadin UIs seem to have a problem with the new structure. So today I am going to investigate the issue some more. Debugging the issue showed that the widgetset property, required for Vaadin UIs is not propagated properly, resulting in loading the DefaultWidgetSet which - for the Topology UI - is missing certain components.

Yesterday we started to to replace our custom Http Bridge with the official Http Felix Bridge. I started implementing a ProxyFilter to dispatch all requests to the OSGi world if it can be handled by any OSGi registered service to make /opennms/topology work instead of using /opennms/osgi/topology. While finalizing this initial work, I encountered a problem that service properties supported by the PAX WEB project are not officially supported by OSGi and with that not supported by the Apache Felix HTTP project.

Yesterday I found out, that we can no longer use our forked Http Service Bridge. This is good for once, as we can now finally get rid of it. But on the other hand this, will be a lot of work. So let’s get started. Which version to use As we can no longer use the pax-whiteboard bundle as we used to, we have to find another solution. I asked the Oracle and found out, that the Apache HTTP Felix project provides a "

Yesterday I learned, that the pax-whiteboard bundle is no longer starting. Investigating the issue some further revealed, that when activating the bundle an Exception java.lang.IllegalStateException: HttpService must be implementing Pax-Web WebContainer! is thrown. This is a known issue (with OpenNMS), but before Karaf 4.2.2 it just worked. My guess is, that the Exception was triggered AFTER the bundle was started. However now this happens when the bundle is still starting and therefore failing.

Last week I started upgrading Karaf to version 4.2.2. You can see the endevour started at Day 1 and continued at Day 2. At Day 2 we left off with three exception in the karaf.log. While two were something like "Cannot register an already registered Mbean" which are most likely caused by some code (inside Karaf) trying to register already registered Mbeans by Jetty itself. So the "real" Exception to investigate here is the issue with the plugin manager.

I always find myself wondering which Horizon Version a Meridian release is based on. To solve this problem once and for all, I looked them all up by looking at the pom.xml of each foundation* branch. Which Horizon Version is Meridian based on? Meridian Horizon Branch M2015 H14 foundation M2016 H17 foundation-2016 M2017

While yesterday I managed to fix One exception, a bunch of more showed up. I wanted to investigate those isuses today, but found a weird behaviour: After a restart of OpenNMS the web console was no longer available. Besides that, I got a ClassNotFoundException org.eclipse.jetty.jaas.JAASLoginService in the logs. First thing I did was to add the dependency <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-jaas</artifactId> <version>${jettyVersion}</version> </dependency> to OpenNMS and copy it to the lib directory.

We are attempting to get OpenNMS to run on Java 9 . The first step of this is to make it compile for Java 9, which we are working on actively . However making it run/compile on Java 9 requires a lot of dependencies to be upgrades as they are not Java 9 compatible as well. One of those dependency upgrades is to upgrade Apache Karaf to version 4.2.2, as you can see in the following figure.

In the very past OpenNMS was mostly driven by Jetty and Spring*. Probably a more flexible solution needed to be found, as with a big application like OpenNMS dependency issues are always present. For example dependency A requires dependency B in Version 1, but dependency C requires the same dependency B in Version 2. Modern containers - such as Apache Karaf (an OSGi container) - can solve these problems. Besides that OSGi offers a nice API and Implementation differentiation.

The Bootstrap 4 Migration is about to be finalized. When we showed the work to the community (and also around internally) the feedback was mostly positive. Some pages did not render properly, but besides that the most commonly reported issues were: Card Headers use up too much space Elements use up too much space in general Concerns about the blue as this is supposed to be reserved for OpenNMS Meridian