Closed Alfiva closed 7 years ago
Original author: @michelegirolami (2013-04-29 09:43:46)
Karaf, similarly to Felix, restores the status from the cache. This behavior is not implemented by the MW2.0 rather by the OSGi container (in our case Karaf). If you don't specify the start level of the bundles, I guess they will have high priority during the restore from cache..maybe it happens that the ontologies start before MW. Could be? Moreover I think the same problem is with Felix.
Could you better describe the problem and the mechanism "importing ontologies"?
Original author: @amedranogil (2013-04-29 11:02:59)
I used the official features, the uaal-MW and uaal-UI, the ontologies not starting correctly are those described in the uaal-UI feature. Seems they do not have a defined start level.
In felix this used not to be a problem, because even though the start level was´t defined; the dependencies (and the ordered list of bundles) ensured the correct starting sequence after restart.
I'm guessing a correct way to solve this problem in karaf is to define features and dependencies between them, so if uaal-UI depended on uaal-ONT (deleting the onts, and other non-UI bundles from uaal-UI), which in turn depended on uaal-MW, karaf MUST know the correct order to reinstall the features, even if the bundles don't have run level defined.
issue cloed on 2013-09-17 16:13:40
Originally Opened: @amedranogil (2013-04-17 11:36:19) Originally Closed: 2013-09-17 16:13:40
when MW2.0 is restarted (without a clean install, IE: when karaf tries to restore the status before closing) ontologies are not started in the correct order, therefore critical classes don't get to get registered.
I suggest to use the existing mechanism of "importing ontologies" to synchronize correctly the ontology starting process.
--
From: this issue has been automatically imported from our old issue tracker