Refactoring bridge/thing life cycle. #2087

sbussweiler · 2016-08-31T13:28:23Z

A BridgeHandler of a bridge is initialized before ThingHandlers of its child things are initialized.
A BridgeHandler is disposed after all ThingHandlers of its child things are disposed.
A bridge handler (new interface BridgeHandler) is notified if a child handler is initialized/disposed.
The methods ThingHandler.bridgeHandlerInitialized() and ThingHandler.bridgeHandlerDisposed() are removed. This breaks the API.
OSGi service registration of thing/bidge handlers has been removed.

Signed-off-by: Stefan Bussweiler s.bussweiler@external.telekom.de

maggu2810 · 2016-09-05T13:28:12Z

Hi @sbussweiler,
I see a lot of

Received update for non-existing item: Item '...' could not be found in the item registry

now.
After that messages, I see

Enabling channel item provider.

and all the

Item '...' has been added.

That is a little bit confusing.

I need to inspect if the updates are generated by my handlers or the framework itself.

If them are generated by my handlers:
My thing handlers call updateState(channelIdWithoutGroup, state); so if the framework tries to update items, it already knows the item names that are linked to the channels and tries to delegate that updates but the items does not yet exist.
If the item is created I would assume that a refresh is called, so the thing handler is able to send the status update of the channel linked to that item again (we added this to the framework some time ago, see #1677). But if I look at the item state it is NULL.

kaikreuzer · 2016-09-06T07:49:36Z

@maggu2810 Upon some analysis, I would assume that these log messages are due to #2096 (and not due to this PR). In #2096, I introduced a small delay before the ChannelItemProvider creates its items. The ThingManager assumes that if there is a link, the referenced item MUST exist as well and thus it sends events for it.
I am not sure how to solve this best; we currently cannot technically guarantee that items are always loaded/created before any link is loaded/created. The solution might also be related to the discussion in #1896, i.e. when we can be sure that all stuff is fully loaded after startup.

maggu2810 · 2016-09-06T08:00:01Z

@kaikreuzer I created #2121 to continue that topic as it seems to be not related (as you already stated) to this PR.

maggu2810 · 2016-09-06T16:37:17Z

@sbussweiler The normal startup works fine.
One question about the state transmissions:

if the bridge goes offline all my thing handlers' status is changed to: OFFLINE (BRIDGE_OFFLINE)
if the bridge goes online again, all my thing handlers' status is changed to: OFFLINE

If my bridge goes online again, I would like to reinitialize my thing handlers (so call dispose(), initialize() -- is this okay?).

What is the correct check?
Using bridgeStatusChanged and check for ONLINE?
I assume bridgeStatusChanged is only called if a thing has been already initialized.

maggu2810 · 2016-09-06T16:38:08Z

@sbussweiler Realized your comment in the other thread a little bit to late

ThingHandler.bridgeStatusChanged() is never called before a child thing has been initialized. The first bridge status change to ONLINE/OFFLINE is initiated by the bridge initialization itself. In that case ThingHandler.bridgeStatusChanged() is not called (because it is not really a change), but ThingHandler.initialize() of all child things. I refactored this behavior this morning, please pull the latest changes.

sbussweiler · 2016-09-07T06:24:18Z

@maggu2810 thanks for your feedback!

if the bridge goes offline all my thing handlers' status is changed to: OFFLINE (BRIDGE_OFFLINE)

if the bridge goes online again, all my thing handlers' status is changed to: OFFLINE

This is the default behavior implemented in BaseThingHandler.bridgeStatusChanged() which can be overridden by any handler implementation.

What is the correct check?
Using bridgeStatusChanged and check for ONLINE

Correct!

If my bridge goes online again, I would like to reinitialize my thing handlers (so call dispose(), initialize() -- is this okay?).

In general initialize and dispose should only be called by the framework (ThingManager). But as you mentioned, it could make sense to execute some logic of initialize and dispose if your bridge goes ONLINE again. In that case extract the logic into some private methods and call them in bridgeStatusChanged(ONLINE) and in initialize() / dispose().

maggu2810 · 2016-09-07T08:00:16Z

@sbussweiler thanks for your feedback, too.
Are there any special scenarios you would like to get tested by me?
I will do some tests this morning myself but I do not see (till now) any blocker.

@kaikreuzer Do we need any further checks before we can merge this?

sbussweiler · 2016-09-07T08:53:28Z

Are there any special scenarios you would like to get tested by me?

Most of the testing scenarios are:

Add things first, then bridge, check that all child thing handlers are initialized.
Delete bridge and check that all child thing handlers are disposed.
Restart binding and check correct disposal & initialize order of bridge and child things.
Check that bridge handler is notified about child thing initialization and disposal.
Play around with Xtext models which leads to an immediate bridge/thing initialization.

kaikreuzer · 2016-09-07T09:38:54Z

@kaikreuzer Do we need any further checks before we can merge this?

As it is a huge change in the inner core, I'd also like to spend some time to review and test it before it is merged - I didn't yet find the time to do this, though.

maggu2810 · 2016-09-07T12:24:38Z

@sbussweiler Can you merge your branch of this PR and this one https://github.com/maggu2810/smarthome/tree/binding-test?
My binding-test branch contains a simple(st) binding to play with things etc.

The test-thing-bridged thing type requires a bridge:
https://github.com/maggu2810/smarthome/blob/63584e607e969d42b765477071d0763194927831/extensions/binding/org.eclipse.smarthome.binding.test/ESH-INF/thing/thing-types.xml#L16

I started with a clean environment (no DSL items / things / ..., no mapdb in the userdata, ...).
I added a thing of type test:test-thing-bridged
I don't select a bridge (there is no one)
The thing handler's initialize method is called.

14:20:20.194 DEBUG o.e.s.c.t.i.ThingRegistryImpl[:245] - Creating thing for type 'test:test-thing-bridged'.
14:20:20.262 DEBUG o.e.s.c.t.i.ThingManager[:427] - Thing 'test:test-thing-bridged:827ad070' is tracked by ThingManager.
14:20:20.262 DEBUG o.e.s.c.t.i.ThingManager[:570] - Calling 'TestHandlerFactory.registerHandler()' for thing 'test:test-thing-bridged:827ad070'.
14:20:20.264 DEBUG o.e.s.c.c.ThreadPoolManager[:145] - Created thread pool 'safeCall' with size 5
14:20:20.266 INFO  s.event.ThingAddedEvent[:43] - Thing 'test:test-thing-bridged:827ad070' has been added.
14:20:20.269 DEBUG o.e.s.c.c.ThreadPoolManager[:115] - Created scheduled thread pool 'thingHandler' of size 3
14:20:20.273 DEBUG o.e.s.c.t.i.ThingManager[:668] - Finished loading meta-data of bundle 'org.eclipse.smarthome.binding.test'
14:20:20.277 INFO  s.event.ThingStatusInfoEvent[:43] - 'test:test-thing-bridged:827ad070' updated: INITIALIZING
14:20:20.279 INFO  s.e.ThingStatusInfoChangedEvent[:43] - 'test:test-thing-bridged:827ad070' changed from UNINITIALIZED to INITIALIZING
14:20:20.280 DEBUG o.e.s.c.c.r.AbstractManagedProvider[:62] - Added new element test:test-thing-bridged:827ad070 to ManagedThingProvider.
14:20:20.283 DEBUG o.e.s.c.t.i.ThingManager[:735] - Calling initialize handler for thing 'test:test-thing-bridged:827ad070' at 'org.eclipse.smarthome.binding.test.internal.handler.TestBaseThingHandler@5a1bfb1e'.
14:20:20.289 INFO  o.e.s.b.t.i.h.TestBaseThingHandler[:21] - Thing initialize: thing uid = test:test-thing-bridged:827ad070, bridge uid = null
14:20:20.293 INFO  s.event.ThingStatusInfoEvent[:43] - 'test:test-thing-bridged:827ad070' updated: ONLINE
14:20:20.293 INFO  s.e.ThingStatusInfoChangedEvent[:43] - 'test:test-thing-bridged:827ad070' changed from INITIALIZING to ONLINE

Shouldn't this PR solve such a problem that a thing with a mandatory bridge is initialized without a bridge?
Is my test case wrong?

sbussweiler · 2016-09-08T14:03:35Z

I added a thing of type test:test-thing-bridged

How did you added the child thing? Via REST call? E.g. in PaperUI adding a child thing first, won't work AFAIK!? You have to specify the bridgeUID for the thing, otherwise the thing is not recognized as a child of a bridge. The ThingManager checks via Thing.getBridgeUID() if a thing is a child of a bridge or not.

@sbussweiler Can you merge your branch of this PR and this one https://github.com/maggu2810/smarthome/tree/binding-test?

You mean I should merge your branch into this PR branch? I didn't had time to have a look on it, sorry. Your branch is providing some test infrastructure for thing/bridge life cycle?

maggu2810 · 2016-09-08T14:24:53Z

You mean I should merge your branch into this PR branch?

No, not to this PR as it is not related.
If you want to give it a try yourself, you can merge this branch with a test binding to your working copy.

How did you added the child thing? Via REST call? E.g. in PaperUI adding a child thing first, won't work AFAIK!?

I was able to add this thing using the Paper UI and leave the bridge selection box empty.
As a referenced bridge could be removed and the thing remains, I don't know if the framework must prevent creation of "bridged-things" without a bridge.
But at least the initialization method should not be called if a bridge is not specified or a specified is missing.

kaikreuzer · 2016-09-08T14:30:58Z

I don't know if the framework must prevent creation of "bridged-things" without a bridge.

I think this is what would need to happen. If there is no bridge referenced in the Thing, there is no chance to tell whether a bridge is required or not - so the framework correctly assumes the Thing can do without a bridge and thus instantiates the handler for it.
If a bridge is mandatory, the bridgeUID must imho always be filled out.

maggu2810

Only minor comments, LGTM

maggu2810 · 2016-09-19T15:03:03Z

...e/org.eclipse.smarthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/Thing.java

- * through a {@link Bridge}.
+ * A {@link Thing} is a representation of a connected part (e.g. physical device or cloud service) from the real world.
+ * It contains a list of {@link Channel}s, which can be bound to {@link Item}s.
+ * </p>


IIRC: <p> should be used only (there is no closing paragraph tag in JavaDoc

"If you have more than one paragraph in the doc comment, separate the paragraphs with a <p> paragraph tag, as shown."
Quote: http://www.oracle.com/technetwork/articles/java/index-137868.html

The closing paragraph tag occurs multiple times in this PR, I don't comment the other occurrences.

maggu2810 · 2016-09-19T15:06:36Z

...re.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/BaseThingHandlerFactory.java

+     * Creates a {@link ThingHandler} for the given thing.
+     *
+     * @param thing
+     *            thing


I assume we don't need a line break between parameter name and its description.

maggu2810 · 2016-09-19T15:13:27Z

...home.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/BaseThingHandler.java

-     * @param thing
-     *            thing
+     * @param thing the thing that should be handled, not null
+     *


Can we drop that empty line?

The empty lines are not required, but from my point of view it makes the javadoc/code more readable.

maggu2810 · 2016-09-19T15:14:19Z

...e.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandlerFactory.java

-     * @param callback
-     *            {@link ThingHandlerCallback} which must be used for the {@link ThingHandler}
+     * @param thing the thing for which a new handler must be registered
+     *


Can we drop that empty line?

maggu2810 · 2016-09-19T15:14:23Z

...e.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandlerFactory.java

+     * @param thing the thing for which a new handler must be registered
+     *
+     * @return the created thing handler instance, not null
+     *


Can we drop that empty line?

maggu2810 · 2016-09-19T15:14:33Z

...e.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandlerFactory.java

+     * @param configuration configuration
+     * @param thingUID thing uid, which can be null
+     * @param bridgeUID bridge uid, which can be null
+     *


Can we drop that empty line?

maggu2810 · 2016-09-19T15:18:10Z

...arthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/ThingManager.java

-            logger.error(
-                    "Exception occured while disposing handler of thing '" + thing.getUID() + "': " + ex.getMessage(),
-                    ex);
+            logger.error("Exception occured while disposing handler of thing '" + thingHandler.getThing().getUID()


It has been wrong before your commit, but as you touched this line could you use {} instead of string concatenation?

yes, will change commented error logs.

maggu2810 · 2016-09-19T15:18:25Z

...arthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/ThingManager.java

-                            logger.error("Exception occured during status update of thing '" + bridgeChildThing.getUID()
-                                    + "': " + ex.getMessage(), ex);
+                            logger.error("Exception occured during notification about bridge status change on thing '"
+                                    + child.getUID() + "': " + ex.getMessage(), ex);


It has been wrong before your commit, but as you touched this line could you use {} instead of string concatenation?

maggu2810 · 2016-09-19T15:18:34Z

...arthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/ThingManager.java

+                    } catch (Exception ex) {
+                        logger.error("Exception occured during bridge handler notification ('" + bridge.getUID()
+                                + "') about handler initialization of child '{}' '" + thing.getUID() + "': "
+                                + ex.getMessage(), ex);


It has been wrong before your commit, but as you touched this line could you use {} instead of string concatenation?

maggu2810 · 2016-09-19T15:18:41Z

...arthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/ThingManager.java

+                    } catch (Exception ex) {
+                        logger.error("Exception occured during bridge handler notification ('" + bridge.getUID()
+                                + "') about handler disposal of child '{}' '" + thing.getUID() + "': "
+                                + ex.getMessage(), ex);


It has been wrong before your commit, but as you touched this line could you use {} instead of string concatenation?

sbussweiler · 2016-09-27T09:21:08Z

@maggu2810 thanks for your comments, I'm back from vacation and will have a look on it!

kaikreuzer · 2016-09-29T08:05:24Z

...re.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/BaseThingHandlerFactory.java

     *
     * @param componentContext
     *            component context (must not be null)
     */
    protected void deactivate(ComponentContext componentContext) {
-        for (ServiceRegistration<ThingHandler> serviceRegistration : this.thingHandlers.values()) {


Hm, isn't dropping the thingHander service registrations a problem here?
If the factory goes down (because some required services are not available anymore), this meant in the past that handlers were also unregistered and hence their Things go into UNINITIALIZED/HANDLER_MISSING status.

Now, it seems that the handlers would be kept, so a binding has no possibility to dispose them anymore?

There is no problem. If a factory goes all handlers are unregistered by the ThingManager. See method ThingManager.removeThingHandlerFactory().

This makes the implicit assumption that a ThingHandlerFactory does not have any dynamic dependencies, but that it is deactivated on any change of its dependent services. I think this must be clearly mentioned in the documentation - it is probably best if you could add a new section that explains how to deal with service dependencies in handlers (i.e. that they do not have a bundleContext anymore and thus should not themselves deal with their dependencies, but only get them reached in from the factory through their constructor).

This makes the implicit assumption that a ThingHandlerFactory does not have any dynamic dependencies, but that it is deactivated on any change of its dependent services.

Correct - if service references are handed over to the handlers (what will be the case in general). Services only used by the factory could be dynamic.

I think this must be clearly mentioned in the documentation

Yes, I need to make it obvious.

kaikreuzer · 2016-09-29T08:17:37Z

...re.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/BaseThingHandlerFactory.java

        ThingHandler thingHandler = createHandler(thing);
        if (thingHandler == null) {
            throw new IllegalStateException(this.getClass().getSimpleName()
                    + " could not create a handler for the thing '" + thing.getUID() + "'.");
        }
+        setHandlerContext(thingHandler);


since we do not treat the handler as an OSGi service anymore, I wonder if we really still need to provide the bundleContext to it? Actually, all code places that I found that are using it look at bit fishy to me, so this rather seems to provoke bad smells...

Correct! I will remove the BundleContext.

Removing the bundle context from the BaseThingHandler causes the following refactoring:

The BaseThingHandlerFactory must handle the tracking of the ThingRegistry and the ItemChannelLinkRegistry.

Due to the fact that the BaseThingHandlerFactory is an abstract class we can not use declarative service features. This would end in a crappy implementation (service tracker must be used, the factory must be unregistered if the ThingRegistry disappears, etc.)

This leads me to the following question: should a binding developer use core services like ThingRegistry, ItemChannelLinkRegistry and ItemRegistry?

My proposal would be:

A binding should not use ESH core services directly.

Required functionality of such core services could be provided by the framework.

E.g. the ThingHandlerCallback provides methods (currently used in the BaseThingHandler) like

ThingHandlerCallback.getBridge(ThingUID bridgeUID)

ThingHandlerCallback.isItemLinked(String channelId)

... further use cases TBD

BundleContext, ThingRegistry, ItemChannelLinkRegistry would be removed from the BaseThingHandler.

Problem:

This will break a lot of bindings, because BundleContext, ThingRegistry, ItemChannelLinkRegistry are protected members in the BaseThingHandler.

ThingHandlerCallback.getBridge(ThingUID bridgeUID) and ThingHandlerCallback.isItemLinked(String channelId) are the obvious use cases covered by the BaseThingHandler. Further uses cases must be analyzed (which bindings are using the protected members for what?).

Due to the fact the this refactoring will break a lot of bindings, I would like to provide this refactoring in a separate PR. The changes of this PR are quite enough.

@kaikreuzer what do you think?

BundleContext, ThingRegistry, ItemChannelLinkRegistry would be removed from the BaseThingHandler.

This imho makes sense as these services should not be directly available to binding developers.

This will break a lot of bindings

I hope that it doesn't affect to many bindings after all - from a quick check in the ESH+OH2 repos I only found 4 that would need to be changed.

I would like to provide this refactoring in a separate PR.

If this is something that is pretty isolated from the other changes, doing it in a separate PR is fine for me - I'd just like to have your confirmation that you'll nonetheless continue to work on it :-)

As discussed with @kaikreuzer: BundleContext, ThingRegistry and ItemChannelLinkRegistry are removed from the BaseThingHandler in a separate PR.

kaikreuzer · 2016-09-29T08:26:00Z

...marthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandler.java

-     * Handles a command for a given channel.
+     * Disposes the thing handler, e.g. deallocate resources.
+     * </p>
+     * The framework expects this method to be non-blocking and return quickly. For longer running disposals,


Really? For a dispose this is rather unexpected to me - I would have assumed that when the method returns, the instance can really be thrown away and that it does not do any further activities in the background.

In most of the cases dispose is a short running operation. The intention was to provide the possibility to handle also long running disposals.

I would not allow long running disposals. After all, this should NOT do any communication with the device, it should only clean up internal memory etc. It should be a valid assumption that the instance can be GC'ed immediately after dispose returns.

kaikreuzer · 2016-09-29T08:27:28Z

...marthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingHandler.java

-     * of this handler does not have a bridge, this method is never called.
-     *
-     * @param thingStatusInfo the status info of the bridge
+     * This method is called before a thing will be removed. An implementing class can handle the removal in order to


"before a thing is removed" instead of "before a thing will be removed"

lsafelix75 · 2016-10-09T07:06:56Z

Any guide how to get this feature to be tested on my OpenHab2 IDE environment?

kgoderis · 2016-10-25T15:02:09Z

Small friendly ping as to where are standing with this as it is a requirement to solve #1847?

kaikreuzer · 2016-10-25T18:20:44Z

afaik, we are still waiting for an update from @sbussweiler, is this right, Stefan?

sbussweiler · 2016-10-26T06:03:36Z

Correct, there is an ongoing discussion about a refactoring. I will add this as soon as possible.

sbussweiler · 2016-11-07T15:48:36Z

@kaikreuzer thanks for re-testing.

In general, code in this method is most likely not required anymore, since it all happens already in initialize() (since the handler is now always there first), correct?

Correct.

maggu2810 · 2016-11-07T16:08:00Z

You can also use this opportunity to again update the tests that are now shown in conflict again :-/

Didn't realize that we should not merge other stuff - but perhaps it would be the best if this one is nearly ready to merge.

kaikreuzer · 2016-11-07T16:23:49Z

Didn't realize that we should not merge other stuff

No, it is fully ok to merge other stuff - we just have to resolve conflicts of PRs afterwards that are waiting for CQ approval, that's life.

Signed-off-by: Stefan Bussweiler <s.bussweiler@external.telekom.de>

sbussweiler · 2016-11-08T07:14:36Z

Despite the fact that I asked you not to do any changes to your branch, it is actually ok to add a commit to it to adapt this line - just make sure that you keep the initial commit as is, i.e. do not squash anything. You can also use this opportunity to again update the tests that are now shown in conflict again :-/

Done. Resolved merge conflicts and changed bridgeStatusChanged() default behavior.

kaikreuzer · 2016-11-08T08:34:14Z

FTR: Once the CQ is approved, we should merge this with keeping the 3 commits in place.

kaikreuzer · 2016-11-11T13:44:17Z

Alright, we have check-in approval - now it counts @sbussweiler ;-)

See eclipse-archived/smarthome#2087 Signed-off-by: Kai Kreuzer <kai@openhab.org>

sbussweiler mentioned this pull request Aug 31, 2016

Bridge(Handler) and Thing(Handler) relationship #1479

Closed

kaikreuzer mentioned this pull request Sep 4, 2016

Binding initialization stalls during startup (intermittently) #1847

Closed

maggu2810 mentioned this pull request Sep 6, 2016

Item initialization / item channel link handling #2121

Closed

This was referenced Sep 17, 2016

channelLinked not called by the thing manager #2183

Closed

[astro] Positional job not starting openhab/openhab-addons#1223

Closed

LIFX binding feature request: implement postCommand and UDP broadcast #2082

Closed

maggu2810 reviewed Sep 19, 2016

View reviewed changes

kaikreuzer reviewed Sep 29, 2016

View reviewed changes

kaikreuzer mentioned this pull request Oct 23, 2016

Things not correctly initializing at startup on slow hardware openhab/openhab-distro#306

Closed

sbussweiler added 3 commits November 7, 2016 18:06

Refactoring bridge/thing life cycle.

7c34863

Signed-off-by: Stefan Bussweiler <s.bussweiler@external.telekom.de>

Changed child thing default status behavior.

aa6ac23

Signed-off-by: Stefan Bussweiler <s.bussweiler@external.telekom.de>

Provide immutable copy of handlers.

ac5c410

kaikreuzer removed the CQ label Nov 11, 2016

kaikreuzer merged commit 9bf9cac into eclipse-archived:master Nov 11, 2016

kaikreuzer deleted the thing-bridge-lifecycle branch November 11, 2016 13:44

kaikreuzer mentioned this pull request Nov 11, 2016

add the isInitialized function to the thing itself #2022

Merged

paulianttila mentioned this pull request Nov 13, 2016

Bridge.getHandler() cause NoSuchMethodError exception #2455

Closed

svilenvul mentioned this pull request Nov 14, 2016

Adapt Binding tests to the new Bridge/Thing lifecycle openhab/openhab-addons#1425

Closed

kaikreuzer added a commit to openhab/openhab-addons that referenced this pull request Nov 16, 2016

adapted code to ESH ThingHandler API refactoring (#1394)

c4b71de

See eclipse-archived/smarthome#2087 Signed-off-by: Kai Kreuzer <kai@openhab.org>

This was referenced Nov 16, 2016

removed bridgeHandlerInitialized method as it has been removed in the ESH API openhab/org.openhab.binding.zwave#223

Merged

NPE when starting the ThingManager #2481

Closed

Improve Thing Handler Implementation documentation #2181

Open

andreacioni mentioned this pull request Nov 21, 2016

Binding issue related to recent updates on Smarthome API tobof/openhab-addons#40

Closed

sbussweiler mentioned this pull request Nov 25, 2016

refactoring of ThingManager #955

Closed

kaikreuzer added the APIBreaking label Nov 29, 2016

sjsf mentioned this pull request Dec 7, 2016

Add new binding for LIRC. #2537

Merged

Jamstah pushed a commit to Jamstah/openhab-addons that referenced this pull request Dec 12, 2016

adapted code to ESH ThingHandler API refactoring (openhab#1394)

45e2c67

See eclipse-archived/smarthome#2087 Signed-off-by: Kai Kreuzer <kai@openhab.org>

petarnv mentioned this pull request Mar 1, 2017

Improve pure Java OSGi test support #3078

Merged

sbussweiler mentioned this pull request Apr 28, 2017

Remove "bundleContext" (and similar) from BaseThingHandler #3327

Closed

sjsf mentioned this pull request Aug 17, 2017

[Documentation/API Doc] BaseThingHandler.getBridge().getHandler() #4069

Closed

kaikreuzer added this to the 0.9.0 milestone Nov 30, 2017

boc-tothefuture mentioned this pull request Oct 29, 2018

Remove ServiceTracker from BaseThingHandler #5182

Open

5 tasks

maggu2810 mentioned this pull request Nov 12, 2018

ThingHandler initialized before bridge initialize() completes #6509

Open

Refactoring bridge/thing life cycle. #2087

Refactoring bridge/thing life cycle. #2087

Conversation

sbussweiler commented Aug 31, 2016

maggu2810 commented Sep 5, 2016 • edited

kaikreuzer commented Sep 6, 2016

maggu2810 commented Sep 6, 2016

maggu2810 commented Sep 6, 2016

maggu2810 commented Sep 6, 2016

sbussweiler commented Sep 7, 2016

maggu2810 commented Sep 7, 2016

sbussweiler commented Sep 7, 2016 • edited

kaikreuzer commented Sep 7, 2016

maggu2810 commented Sep 7, 2016

sbussweiler commented Sep 8, 2016

maggu2810 commented Sep 8, 2016

kaikreuzer commented Sep 8, 2016

maggu2810 left a comment

Choose a reason for hiding this comment

maggu2810 Sep 19, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbussweiler Sep 29, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbussweiler commented Sep 27, 2016

Choose a reason for hiding this comment

sbussweiler Sep 29, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbussweiler Sep 30, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lsafelix75 commented Oct 9, 2016

kgoderis commented Oct 25, 2016

kaikreuzer commented Oct 25, 2016

sbussweiler commented Oct 26, 2016

sbussweiler commented Nov 7, 2016

maggu2810 commented Nov 7, 2016

kaikreuzer commented Nov 7, 2016

sbussweiler commented Nov 8, 2016

kaikreuzer commented Nov 8, 2016

kaikreuzer commented Nov 11, 2016

maggu2810 commented Sep 5, 2016 •

edited

sbussweiler commented Sep 7, 2016 •

edited

maggu2810 Sep 19, 2016 •

edited

sbussweiler Sep 29, 2016 •

edited

sbussweiler Sep 29, 2016 •

edited

sbussweiler Sep 30, 2016 •

edited