Fix logging related errors #104
Comments
|
I thought I had fixed the dev-launcher issues (1) and (2) by removing the logback bundles from the "felix" directory and replacing them with *.cfg files pointing to the bundles' locations under ~/.m2. I thought that by doing this I was making sure the logback bundles would start only after logging-appender is resolved. Unfortunately it turned out none of this mattered. The fact that things worked after my change was merely a coincidence. After I changed the names of the *.cfg files things suddenly stopped working. It seems that somehow the file names help determine the order in which bundles are resolved/installed/started. The whole thing is very indeterministic. I noticed that not only changing the file names of the *.cfg files, but even moving the whole "target" directory to a different location can have an effect. On the other hand, whatever start levels I give the logback and logging-appender bundles, the result is always the same. I'm afraid I have too little understanding of OSGi to grasp what's going on when Felix boots up. I've tried a lot of different things today but haven't gotten much wiser :( I guess this is also very much related to the other startup issues we've been having with the braille modules for some time (services randomly not being available after a (re)start). I think this is indeed related because I've never experienced these startup issues with the dev-launcher, and apart from the way the bundles are started there are no differences between the two launchers. I haven't tried controlling the start levels of the different braille modules yet, that might help. Although that'll require some guess work too. And if I already knew which bundles are the problem, I would probably try to fix them instead. Because people say it is better to not rely on start levels. The problem is that I have no idea what kind of things make a bundle rely on a start level and how you would avoid it. Moreover, I'm not sure where in this whole story fragment and host bundles come into play. Anyone's help on this would be highly appreciated! Need to get this sorted out because at the moment I can't package and deploy my system and be sure it starts up the way I want, which makes it pretty useless :'( |
|
@rdeltour Could we talk about this tomorrow at the team meeting? |
|
Some more information that might help:
|
…ncher EDIT: this was only a coincidence, see #104 (comment)
in order to solve startup issues. It doesn't make sense to use file install for these bundles because they can not be reloaded dynamically without breaking things. see #104
in order to solve startup issues. It doesn't make sense to use file install for these bundles because they can not be reloaded dynamically without breaking things. see daisy/pipeline-assembly#104
in order to solve startup issues. It doesn't make sense to use file install for these bundles because they can not be reloaded dynamically without breaking things. see #104
in order to solve startup issues. It doesn't make sense to use file install for these bundles because they can not be reloaded dynamically without breaking things. see #104
in order to solve startup issues. It doesn't make sense to use file install for these bundles because they can not be reloaded dynamically without breaking things. see #104
|
This issue has been addressed in 1.11.0 but I'm not sure if all the errors are gone now. |
There are a couple of logging related errors when you launch the system. Two of them only show up in the dev-launcher, the third shows up in both the dev-launcher and regular launcher. I'm using Java 8. The dev-launcher is of course less important then the regular one, but it would still be good to understand what is happening.
The text was updated successfully, but these errors were encountered: