DSL files are not loaded upon startup

[openhab]

DSL files are not loaded upon startup

[dvanherbergen]

A similar issue exists with the online distro. After first start, it doesn't completely install the demo package. It does on the second start.

[kaikreuzer]

The problem is not that the demo package is not installed (for the offline distro). The problem is that when it is installed, the dsl files are not loaded at (a second) startup.

[kaikreuzer]

Restarting bundle org.eclipse.smarthome.model.core makes the files being read. So I guess we have to tweak the start levels for solving this issue.

[kaikreuzer]

After first start, it doesn't completely install the demo package.

Do you refer to this log message?

2016-01-07 19:18:21.792 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-package-demo': Unable to acquire the state change lock for the module: osgi.identity; osgi.identity="org.openhab.core"; type="osgi.bundle"; version:Version="2.0.0.201601070020" [id=137] STOPPED [STARTED]

I just saw it for the first time with the latest build - previous builds did not have this problem, but installed the demo-package successfully.

[dvanherbergen]

I noticed it wasn't started using feature:list, but I was focussed on something else, so I didn't check the logs at the time. Then after restart it was available.

[kaikreuzer]

I think I have a fix for this, which does not require tweaking any start level. Will create a PR for ESH shortly.

[kaikreuzer]

Hm, I was too optimistic. Doing it the clean way with proper component dependencies is a rather big refactoring, which I do not dare to do right now for fixing this issue. For who is interested, here is what I did so far: kaikreuzer/smarthome@fc219c6

So for the moment, I would prefer to simply set the start-level of org.eclipse.smarthome.model.core to 85 - this works well.
@maggu2810 I am struggling finding the best way to do this. As this bundle is part of the feature esh-core, which is defined in the ESH repo and we do not want to specify any start level information in there, how can I nonetheless achieve it? I tried adding this bundle to the openhab-runtime-base feature, but this is ignored, since the bundle seems to be installed through the esh-core dependency already. And good suggestion?

[dvanherbergen]

Maybe define it in the karaf/etc/startup.properties?

[kaikreuzer]

Doesn't seem to work... It now has bundleId 10, but the start-level still shows 80 instead of 85.

[maggu2810]

Hm, I was too optimistic. Doing it the clean way with proper component
dependencies is a rather big refactoring, which I do not dare to do right
now for fixing this issue. For who is interested, here is what I did so
far: kaikreuzer/smarthome@fc219c6

In L75 you called activator.getExtensionName() without storing the return
value.
In L82 you called it again.
Was your intension to reuse the already assigned value there?

A first look at this change seems to make some stuff clearer, but I need to
have a deeper look at this.

[kaikreuzer]

Was your intension to reuse the already assigned value there?

The first line was just a left over, which can be removed.

A first look at this change seems to make some stuff clearer, but I need to
have a deeper look at this.

Please let us go into this another time. I need a fix for the start-level asap as this is a blocking issue for the distribution.

[maggu2810]

Please let us go into this another time. I need a fix for the start-level
asap as this is a blocking issue for the distribution.

I got your point. But would you like to start adding star levels to the esh
histed feature now?
Perhaps the simplest solution for the release is to copy the feature to oh
and add start levels there.

[kaikreuzer]

But would you like to start adding star levels to the esh histed feature now?

Well, I didn't do this because I expected you to shout at me ;-)

Perhaps the simplest solution for the release is to copy the feature to oh
and add start levels there.

Does that easily work? We would have two esh-core features defined in two different feature.xmls then. Or do you mean I should copy the complete feature.xml over? That does not sound good either.

[maggu2810]

As long as you are only using the ESH feature hostet in a OH repo it doesn't matter and you can change ESH stuff for OH as much as you want.

ATM all ESH bundles are using the same startlevel (60) [undefined in the XML but set by the global preference set in the pom].
Suggestion:

• change the one bundle to use a higher start level (e.g. 61) in the ESH repo
• do your release
• add the removal of the explicit start level to your PR you mentioned above
• create the PR...

[maggu2810]

Was your intension to reuse the already assigned value there?

The first line was just a left over, which can be removed.

As the second call is placed in a loop and the return value is always the same it would prefer to leave the first call and store the result to a local variable. Using the local variable in the loop will save multiple function calls.

[kaikreuzer]

ATM all ESH bundles are using the same startlevel (60)

Why do all those bundles show start-level 80 in the openHAB distribution?

[maggu2810]

It seems the setting in the pom is not used, so the default on (setting of your dist.) is used. That is IMHO okay, as we do not force any start level at all (but will check at which place this property is used another time).

[kaikreuzer]

But this means that setting the bundle startlevel in the ESH repo to 61 probably won't help? Or shall I set it to 85 in there?

[maggu2810]

Yes, I think so (61 => 85).

[kaikreuzer]

Yes, this works!