ChannelItemProvider depends on bundle start order

[maggu2810]

#1288 introduced the ChannelItemProvider

If I understand the mechanism correctly, the "virtual" items are now created (createItemForLink) if a Thing or a ItemChannelLink has been added.

It seems to me that (at least) on startup it is possible that "createItemForLink" is called before all the bundle XMLs are completely parsed (see: #1519 (comment)).

I can reproduce the error here in a Karaf container where the most ESH bundles are using the same start-level (I am using the our karaf and karaf-tp features).
I can workaround that startup behavior if I increase the start-level of the core.thing bundle.

[maggu2810]

Continue from: #1519 (comment)

Hm, you are right, although it does not matter if items are created before the binding is up, this provider reads the information from the channels, so it is a problem if they are not yet there...

So, what can we do to solve this?

[kaikreuzer]

Unfortunately it is not possible to subscribe to the ThingTypeRegistry as a listener to be informed when new thing types become available. I could instead directly depend on ThingTypeProviders and refresh the constructed item list if there is any change. But it is probably cleaner to add a listener possibility to the registry, what do you think?

[maggu2810]

With PR https://github.com/eclipse/smarthome/pull/1419/files we have a mechanismus to be informed if a bundle loading has been finished.
Perhaps we could use this mechanism to process thing types only if the whole bundle is loaded.
Also I assume we need to be informed about new thing types, so we can re-trigger the item creation.
Items for links that thing-type or channel information is not available (incomplete) should be skipped.

WDYT?

[maggu2810]

Steps to reproduce the problem: #1661 (comment)

[kaikreuzer]

Ok, you are right. I actually misunderstood #1419 - my expectation was that the XMLThingTypeProvider is also only added once all xmls are processed. Instead it is registered and provides an empty result list, which is then silently filled later on. So my fix indeed misses the point here. :-(
As I won't be able to come up with anything more clever tonight, I suggest to release 0.8.0 as is - there is simply no time left for further fixes.

[kaikreuzer]

Sorry, I meant to close the PR, not the issue.

[triller-telekom]

I think this issue was fixed in PR #3423

which will finally be restructured by #4203. @SJKA Am I right that this is fixed due to our ReadyMarkers?

[maggu2810]

Seems to be fixed.