Simplify core features to prevent unnecessary bundle refreshes

[wborn]

It seems that when multiple features install the same bundle it may cause Karaf to refresh bundles when (un)installing features.

I found the bundles which cause these refreshes by (un)installing features with the verbose (-v) option so Karaf shows what happens:

openhab> feature:install -v openhab-binding-mail
Adding features: openhab-binding-mail/[3.0.0.SNAPSHOT,3.0.0.SNAPSHOT]
Changes to perform:
  Region: root
    Bundles to install:
      mvn:com.sun.mail/javax.mail/1.6.2
      mvn:org.openhab.addons.bundles/org.openhab.binding.mail/3.0.0-SNAPSHOT
Stopping bundles:
  org.openhab.binding.network/3.0.0.202010080341
  org.openhab.core.automation.rest/3.0.0.202010080309
  org.openhab.core.model.script.runtime/3.0.0.202010080314
  org.openhab.core.model.rule.runtime/3.0.0.202010080314
  org.openhab.core.automation.module.script/3.0.0.202010080308
  org.openhab.core.automation.module.media/3.0.0.202010080308
  org.openhab.core.automation/3.0.0.202010080258
  org.eclipse.jetty.plus/9.4.20.v20190813
  org.eclipse.jetty.jndi/9.4.20.v20190813
Installing bundles:
  mvn:com.sun.mail/javax.mail/1.6.2
  mvn:org.openhab.addons.bundles/org.openhab.binding.mail/3.0.0-SNAPSHOT
Refreshing bundles:
    org.eclipse.jetty.jndi/9.4.20.v20190813 (Should be wired to: com.sun.mail.javax.mail/1.6.2 (through [org.eclipse.jetty.jndi/9.4.20.v20190813] osgi.wiring.package; resolution:=optional; filter:="(&(osgi.wiring.package=javax.mail)(version>=1.4.1)(!(version>=2.0.0)))"))
    org.eclipse.jetty.plus/9.4.20.v20190813 (Wired to org.eclipse.jetty.jndi/9.4.20.v20190813 which is being refreshed)
    org.openhab.binding.network/3.0.0.202010080341 (Wired to org.openhab.core.automation/3.0.0.202010080258 which is being refreshed)
    org.openhab.core.automation/3.0.0.202010080258 (Should be wired to: org.openhab.core.automation/3.0.0.202010080258 (through [org.openhab.core.automation/3.0.0.202010080258] osgi.wiring.package; resolution:=optional; filter:="(osgi.wiring.package=org.openhab.core.automation.annotation)"))
    org.openhab.core.automation.module.media/3.0.0.202010080308 (Wired to org.openhab.core.automation/3.0.0.202010080258 which is being refreshed)
    org.openhab.core.automation.module.script/3.0.0.202010080308 (Wired to org.openhab.core.automation/3.0.0.202010080258 which is being refreshed)
    org.openhab.core.automation.rest/3.0.0.202010080309 (Wired to org.openhab.core.automation/3.0.0.202010080258 which is being refreshed)
    org.openhab.core.model.rule.runtime/3.0.0.202010080314 (Wired to org.openhab.core.automation/3.0.0.202010080258 which is being refreshed)
    org.openhab.core.model.script.runtime/3.0.0.202010080314 (Wired to org.openhab.core.automation.module.script/3.0.0.202010080308 which is being refreshed)
Starting bundles:
  org.openhab.binding.mail/3.0.0.202010080338
  com.sun.mail.javax.mail/1.6.2
Done.

In this case it restarted the whole RuleEngine and also the Network Binding because it refreshed the org.openhab.core.automation bundle.

Refreshes of the org.openhab.core.io.transport.serial bundle also seems to cause these restarts:

openhab> feature:uninstall -v openhab-binding-astro
Removing features: openhab-binding-astro/[3.0.0.SNAPSHOT,3.0.0.SNAPSHOT]
Changes to perform:
  Region: root
    Bundles to uninstall:
      org.openhab.binding.astro/3.0.0.202010092151
Stopping bundles:
  org.openhab.binding.astro/3.0.0.202010092151
  org.openhab.core.config.serial/3.0.0.202010092149
  org.openhab.binding.plugwise/3.0.0.202010092151
  org.openhab.core.io.transport.serial.rxtx.rfc2217/3.0.0.202010092149
  org.openhab.core.io.transport.serial/3.0.0.202010092149
  org.openhab.core.io.transport.serial.rxtx/3.0.0.202010092149
Uninstalling bundles:
  org.openhab.binding.astro/3.0.0.202010092151
Refreshing bundles:
    org.openhab.binding.astro/3.0.0.202010092151 (Bundle will be uninstalled)
    org.openhab.binding.plugwise/3.0.0.202010092151 (Should be wired to: org.openhab.core.io.transport.serial/3.0.0.202010092149 (through [org.openhab.binding.plugwise/3.0.0.202010092151] osgi.wiring.package; filter:="(osgi.wiring.package=org.openhab.core.io.transport.serial)"))
    org.openhab.core.config.serial/3.0.0.202010092149 (Should be wired to: org.openhab.core.io.transport.serial/3.0.0.202010092149 (through [org.openhab.core.config.serial/3.0.0.202010092149] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.openhab.core.io.transport.serial)(version>=3.0.0)(!(version>=4.0.0)))"))
    org.openhab.core.io.transport.serial/3.0.0.202010092149 (Should be wired to: org.openhab.core.io.transport.serial/3.0.0.202010092149 (through [org.openhab.core.io.transport.serial/3.0.0.202010092149] osgi.wiring.package; filter:="(osgi.wiring.package=org.openhab.core.io.transport.serial)"))
    org.openhab.core.io.transport.serial.rxtx/3.0.0.202010092149 (Wired to org.openhab.core.io.transport.serial/3.0.0.202010092149 which is being refreshed)
    org.openhab.core.io.transport.serial.rxtx.rfc2217/3.0.0.202010092149 (Wired to org.openhab.core.io.transport.serial/3.0.0.202010092149 which is being refreshed)
Done.

When the (redundant) openhab-core-automation feature is removed and the serial dependencies are merged into the openhab-transport-serial feature these restarts due these bundle refreshes no longer occur.

Fixes #1322
Fixes #1354

[wborn]

Note that it might still occasionally refresh bundles during (un)installs. That is normal behavior in an OSGi environment when a bundle has an optional dependency which is installed and previously was not (and vice versa).

[kaikreuzer]

Sounds awesome @wborn!
Are you sure that these are the only problematic features and problem is thus solved for all our add-ons?
Do I understand it correctly that Karaf (as some precaution?) refreshes bundles in dependent features of any newly installed feature? Is there a strong reason why Karaf does that (instead of leaving the decision to the underlying OSGi framework) and can that maybe be deactivated?

[wborn]

Are you sure that these are the only problematic features and problem is thus solved for all our add-ons?

I tested installing and uninstalling several add-on features and with these changes the unnecessary refreshes were resolved. If there are more such issues we might fix them similarly.

Do I understand it correctly that Karaf (as some precaution?) refreshes bundles in dependent features of any newly installed feature? Is there a strong reason why Karaf does that (instead of leaving the decision to the underlying OSGi framework) and can that maybe be deactivated?

The exact reasons why Karaf starts refreshing bundles that are defined in multiple features is not clear to me. Perhaps it is a bug and it gets confused somehow. Maybe @jbonofre knows the reason and if this is a known (and fixed) Karaf issue? I couldn't find a fix for this in newer 4.2.x releases. We currently use Karaf 4.2.7.