Openhab-addons: [mqtt] Errors in the log file after MQTT binding installation

Created on 26 Mar 2019  路  30Comments  路  Source: openhab/openhab-addons

Hi guys! (@davidgraeff)

I'm trying the latest openHAB 2.5.0 SNAPSHOT version and I have found the following errors after installing the MQTT binding:

2019-03-26 15:34:17.609 [ERROR] [org.openhab.binding.mqtt.generic    ] - bundle org.openhab.binding.mqtt.generic:2.5.0.201903260114 (223)[org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider(215)] : Could not load implementation object class org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider
java.lang.ClassNotFoundException: org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider cannot be found by org.openhab.binding.mqtt.generic_2.5.0.201903260114

Many thanks for your work and support!

PS: The long version of the error message can be found here: https://pastebin.com/14RHjbd5

bug infrastructure

All 30 comments

Meh, I'm unable to setup up the Eclipse IDE correctly :cry:

The error seems to be related to the visibility of the MqttChannelStateDescriptionProvider class, isn't it? After splitting the binding in multiple packages (mqtt.generic, mqtt.homie and mqtt.homeassistant), some classes from the mqtt.generic package should be accessible to the other classes, right?

Correct. I made most generic classes public therefore.

It compiles and the tests are running through. I have no idea what is causing this failing dependency resolution.

Which version will I not get this error on, its really made my server not useable

Hi @GadgetAngel!

You can't, we need to wait patiently until @davidgraeff finds some time to submit a PR with the fix :+1: Keep calm and trust David!

Thanks for your time!

I will check in the next snapshot version, let's see if it is tomorrow, if the problem is fixed. Fingers crossed 馃 Thanks David!

I just placed these kars into addons folder, without stopping Openhab. If this doesn't work try stopping Openhab, delete userdata/cache and userdata/tmp folders and start Openhab.

works! but only until reboot.
the error reappears after restarting

works! but only until reboot.
the error reappears after restarting

Hi @blademckain!

Are you talking about the latest version of the binding (openHAB 2.5 SNAPSHOT from today) or about the files shared by @GadgetAngel? Because the file from @GadgetAngel are more than 2 weeks old and my original bug report was related to the latest code 馃槈

Anyway, @davidgraeff, you have done it right reopening the issue, because the errors are still there. Right after installing the binding, the same error messages appear in the log file:

2019-03-31 22:25:40.568 [ERROR] [org.openhab.binding.mqtt.generic    ] - bundle org.openhab.binding.mqtt.generic:2.5.0.201903310938 (223)[org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider(217)] : Could not load implementation object class org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider
java.lang.ClassNotFoundException: org.openhab.binding.mqtt.MqttChannelStateDescriptionProvider cannot be found by org.openhab.binding.mqtt.generic_2.5.0.201903310938
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433) ~[?:?]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) ~[?:?]
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) ~[?:?]
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) ~[?:?]
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:564) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:999) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1026) ~[?:?]
    at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:936) ~[?:?]
    at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:901) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) ~[?:?]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624) ~[?:?]
    at com.eclipsesource.jaxrs.publisher.internal.ResourceTracker.addingService(ResourceTracker.java:39) ~[?:?]
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) ~[?:?]
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) ~[?:?]
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) ~[?:?]
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[?:?]
    at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) ~[?:?]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:920) ~[?:?]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[?:?]
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:805) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:1) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:803) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) ~[?:?]
    at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225) ~[?:?]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:469) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:906) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:892) ~[?:?]
    at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:128) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:959) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:732) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:666) ~[?:?]
    at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:432) ~[?:?]
    at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:665) ~[?:?]
    at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339) ~[?:?]
    at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:381) ~[?:?]
    at org.apache.felix.scr.impl.Activator.access$200(Activator.java:49) ~[?:?]
    at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:263) ~[?:?]
    at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) ~[?:?]
    at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) ~[?:?]
    at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49) ~[?:?]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482) ~[?:?]
    at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) ~[?:?]
    at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) ~[?:?]
    at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) ~[?:?]
    at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908) ~[?:?]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[?:?]
    at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:124) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:1) ~[?:?]
    at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:122) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168) ~[?:?]
    at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) ~[?:?]
    at org.eclipse.osgi.container.Module.start(Module.java:467) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:402) ~[?:?]
    at org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161) ~[?:?]
    at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1116) ~[?:?]
    at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:997) ~[?:?]
    at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025) ~[?:?]
    at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964) ~[?:?]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]

But, as in the previous report, there are many more error lines :cry: I have also tried to stop and restart the bundle (through an SSH connection to the Karaf console: ssh -p 8101 openhab@localhost and bundle:stop 225 -the Homie bundle ID-) with the same result. I thought that manually restarting the bundle was going to work, because we avoid the start order problem, but that doesn't seem to be the case. I don't know what else I can suggest.

You are able to compile and launch the bindings (generic, homie and home assistant) in the Eclipse IDE? Does it work fine there?

It's a shame that the latest change doesn't solve the problem, but many thanks for your work and support!

Aitor

I'm out of ideas and have time for mqtt only end of the month. But as soon as integration tests are re-enabled, we should see problems on Travis as well and more people are able to see and solve those.

With build 1564 (built on 31.3.2018) and the jars above I am getting

2019-04-02 18:17:14.623 [ERROR] [org.openhab.binding.mqtt.homie      ] - FrameworkEvent ERROR - org.openhab.binding.mqtt.homie
org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
...
Caused by: java.lang.NoClassDefFoundError: org/openhab/binding/mqtt/TransformationServiceProvider
...
Caused by: java.lang.ClassNotFoundException: org.openhab.binding.mqtt.TransformationServiceProvider cannot be found by org.openhab.binding.mqtt.homie_2.5.0.201903310938
        at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433) ~[?:?]

Downloading the jars mentioned above helps reading data from my broker, but publishing does not work...

works! but only until reboot.
the error reappears after restarting

Hi @blademckain!

Are you talking about the latest version of the binding (openHAB 2.5 SNAPSHOT from today) or about the files shared by @GadgetAngel? Because the file from @GadgetAngel are more than 2 weeks old and my original bug report was related to the latest code

Hi,
with the latest openHAB 2.5 SNAPSHOT, the error persist!!
with the latest openHAB 2.5 SNAPSHOT + the files shared by @GadgetAngel, works until a reboot.
Help!

With build 1564 (built on 31.3.2018) and the jars above I am getting
Downloading the jars mentioned above helps reading data from my broker, but publishing does not work...

it happens to me too

This is NOT fixed and WILL NOT be fixed until end of the month. Snapshots are not guaranteed to be stable. If someone have time to fix it in the meantime, you are welcome

errorOH

errorOH2

I'm not a java top. But couldn't the problem be that the "generic" folder is missing?

Hi @davidgraeff!

At first I didn't understand @blademckain's commet very well, but I think that, at least, it makes some sense. Why are MQTT generic binding packages named "org.openhab.binding.mqtt" and not "org.openhab.binding.mqtt.generic"? That could explain why the binding is confused trying to import "org.openhab.binding.mqtt.TransformationServiceProvider". Same thing can be applied to Homie and Home Assistant packages.

Have you though about it? I have tried to refractor the package names in my Eclipse IDE, but the errors are still there, although I can't confirm that the changes are applied :smile: I still have some troubles with the IDE :wink:

EDIT: Ok, after fixing some compilation errors and launching again the app.bndrun file, there are no errors in the log file! Wow! I will make more tests tomorrow, but @blademckain's suggestion seems promising! :+1:

I'm not sure yet what the issue is. There are unit tests that run through and only one integration test (summer time related) is failing.

Those tests require the same classes to be present.

Hi @davidgraeff!

At first I didn't understand @blademckain's commet very well, but I think that, at least, it makes some sense. Why are MQTT generic binding packages named "org.openhab.binding.mqtt" and not "org.openhab.binding.mqtt.generic"? That could explain why the binding is confused trying to import "org.openhab.binding.mqtt.TransformationServiceProvider". Same thing can be applied to Homie and Home Assistant packages.

Have you though about it? I have tried to refractor the package names in my Eclipse IDE, but the errors are still there, although I can't confirm that the changes are applied I still have some troubles with the IDE

EDIT: Ok, after fixing some compilation errors and launching again the app.bndrun file, there are no errors in the log file! Wow! I will make more tests tomorrow, but @blademckain's suggestion seems promising!

if you can compile the jars could you upload them and share them ???
I could also do some tests

Hi @davidgraeff,
I don't know if this is the problem, but it seems that the "org.openhab.binding.mqtt" package is physically divided into 4 folders/4 jars (mqtt, mqtt.generic, mqtt.homeassistant, mqtt.homie, ), but together they form the "org.openhab.binding.mqtt" package. It's a mechanism I've never seen, do you have links to java documentation for this?

And are you sure this method is supported by openhab2-addons?
In the only other similar example (org.openhab.extensionservice.marketplace and org.openhab.extensionservice.marketplace.automation) the two packages are in effect 2 different packages

Yes that is supported, openHAB is an OSGi environment that supports dynamic loading of additional classes

Hi again!

Here you have the .jar files I have compiled, although I'm not sure what's the best way to install them, because placing them in the "addons" folder ("/usr/share/openhab2/addons") has led to duplicate entries in the Thing screen. And if I uninstall the mqtt binding (the original one, from Paper UI), the mqtt transport bundle is uninstalled and I'm unable to install it again (no, the "feature:install esh-io-transport-mqtt" command doesn't work on Karaf, it says that "Error executing command: No matching features for esh-io-transport-mqtt"). Anyway, even with the duplicated entries, the binding works :+1:

@davidgraeff, I don't know what's going on then, but it seems that sharing the same package in different bundles doesn't work. Having a look at how it is done for the bluetooth binding (because there are different "modules" using the same "bluetooth" core binding), I can see that each bundle has its own package namespace and they don't share it.

@blademckain, please, download the .jars from the attached zip files and test if it works for you. I could make a PR with the renamed package names if everything works fine.

mqtt-binding.zip

Best regards,

Aitor

The problem is two folded:

For one I had scope compile in the pom.xml which I just recently removed and replaced with scope provided. That caused every bundle to contain the full source code if I understood maven correctly.

And also the access modifiers are probably not correct. Everything in mqtt and mqtt.generic must be public if it is not in internal and so on. I'm not sure if the problem really is that they have the same package name. Still no time for that though.

Hi David!

I will stop mentioning you in my messages, because I don't want to make you feel pressed about the issue :wink: I know that you are focused on other openHAB stuff and my only goal is to dig in the problem and see if I can fix it myself. So, from now on, you can ignore my messages until you have time for the MQTT binding :+1:

For one I had scope compile in the pom.xml which I just recently removed and replaced with scope provided. That caused every bundle to contain the full source code if I understood maven correctly.

I'm working with the latest code of the binding, where the scope attribute of each pom file is updated to "provided" and that hasn't changed anything :cry:

And also the access modifiers are probably not correct. Everything in mqtt and mqtt.generic must be public if it is not in internal and so on. I'm not sure if the problem really is that they have the same package name. Still no time for that though.

As soon as I changed the package names in the 3 bundles (mqtt.generic, mqtt.homie and mqtt.homeassitant, because mqtt can remain untouched) everything started to work, so it looks like the access modifiers are fine.

@bodiroga It doesn't hurt to have them in different packages. Can you prepare a PR?

@bodiroga It doesn't hurt to have them in different packages. Can you prepare a PR?

Done: #5259! :+1:

Has the correction already been released?
I have openHAB 2.5.0 ~ S1566-1 (Build # 1566) but the error persists

Caused by: java.lang.ClassNotFoundException: org.openhab.binding.mqtt.TransformationServiceProvider cannot be found by org.openhab.binding.mqtt.generic_2.5.0.201904040210

According to this, the latest snapshot version was released 6 days ago (April 4), so no, your snapshot doesn't include the changes 馃槩 We have to wait until the next release 馃憤

I can confirm that the fix works :heart: But you should wait until the next snapshot version, because the one from 13-Apr-2019 has a bug with the database serialization and the things are not persisted between reboots!

Thanks to everyone for your contributions!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

d3rh3ld picture d3rh3ld  路  4Comments

martinvw picture martinvw  路  5Comments

doandzhi picture doandzhi  路  6Comments

IOOOTAlan picture IOOOTAlan  路  3Comments

gk4 picture gk4  路  3Comments