Closed Dnnd closed 4 years ago
Thank you for the issue!
Commit https://github.com/sane-city/wot-servient/commit/24918ef49c3963304a4e8000b1f9fb9b52a15e97 should fix the bug. Can you please confirm this bugfix?
Yes, https://github.com/sane-city/wot-servient/commit/24918ef49c3963304a4e8000b1f9fb9b52a15e97 fixes this issue. Thank you for fixing this so quickly!
Expected behavior
Calling
DefaultWot::serverOnly(Config config)
afterWot::destory
is independent from previous calls ofDefaultWot::serverOnly(Config config)
Observed behavior
Calling
DefaultWot::serverOnly(Config config)
afterWot::destory
will create the instance ofWot
with config from the first invocation ofDefaultWot::serverOnly(Config config)
Example
Output:
As you can see, despite different config parameters, the actual configuration is remains unchanged after first call to
DefaultWot::serverOnly(Config config)
.I suppose, the root cause of this behavior is interaction between
SharedMqttClientProvider
andMqttProtocolServer
classes. TheMqttProtocolServer::stop
method https://github.com/sane-city/wot-servient/blob/35f8e899e7f22548fc98aaafd1494f26952aa9ef/wot-servient-binding-mqtt/src/main/java/city/sane/wot/binding/mqtt/MqttProtocolServer.java#L70 won't set value ofSharedMqttClientProvider::singleton
field to null so it's reinitialization https://github.com/sane-city/wot-servient/blob/35f8e899e7f22548fc98aaafd1494f26952aa9ef/wot-servient-binding-mqtt/src/main/java/city/sane/wot/binding/mqtt/SharedMqttClientProvider.java#L21-L22 insidesingleton == null
clause will never happen.