Hi Lets take this to the list for a moment ..
Am 12.02.2014 um 05:40 schrieb Chetan Mehrotra (JIRA) <[email protected]>: > Chetan Mehrotra commented on SLING-3386: > ---------------------------------------- > > bq. treat logging specially in that we define a new "folder" which is handled > first by the bootstrap installer > > The patch takes a bit different route but aim is same i.e. enable influencing > the order in which bootstrap installer would install bundle files To a hammer (setting installation order) everything is a nail (all bundles). I would prefer to solve the actual problem at hand with functionality we have instead of inventing a non-standard wheel which is simulates something we can barely guarantee and which at the end depends on a concrete implementation of the framework as of 2014. > > bq. move all non-logging bundles from startlevel 1 to startlevel 2 > > That would be the proper and stable fix. However it would cause issue in case > of upgrades as we would have to change the bundle start levels. Such a change > would require lot more effort and we would need to ensure that all cases are > handled properly. Thats the reason I am taking the proposed approach as it is > a small change in current startup process. And yes this fix would also not > handle the upgrade scenario Lets target the proper fix and sort the start levels correctly. As for updates: The last release of Sling was Sling 6 which just had logging in start level 1 [1]. So, there is nothing going on in upgrading from a previous Sling 6 release. As for updating from self-cut intermediate builds: Yes, this might be a problem, but here you have an update situation where you will have zero to no control whatsoever what goes on. Hence, I would really prefer to get our start levels straight and reserve 1 to logging and move the install stuff to 2. Regards Felix [1] http://central.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad/6/org.apache.sling.launchpad-6-bundlelist.xml > > bq. The BundleStartLevelSorter.parseStartOrder may throw an exception if the > header happens to not be an Integer. > > I thought about that but then I preferred to have a fail fast approach where > if there is a problem in value then it gets noticed right away. > > bq. Also every reference to start order (or even start level in that method) > would have to be rephrased to install order. Also, I would call the header > "X-Sling-Bootstrap-Install-Order" to indicate it is just the bootstrap > installer respecting this as the installation order. > > Ack. Would change that. > > > > > >> Enable support starting bundle in custom oreder at start level 1 >> ---------------------------------------------------------------- >> >> Key: SLING-3386 >> URL: https://issues.apache.org/jira/browse/SLING-3386 >> Project: Sling >> Issue Type: Improvement >> Components: Launchpad >> Affects Versions: Launchpad Base 2.5.0 >> Reporter: Chetan Mehrotra >> Priority: Minor >> Attachments: SLING-3386.patch >> >> >> By default OSGi framework does not define the order in which bundles would >> be started in a given start level. The only way is to use to use start level. >> However in case of bundle like Logging its desriable that Log bundle is the >> first bundle to start in the system such that it does not miss any log >> message. The problem is described in more details at SLING-3340. >> As Sling uses Felix framework by default it is possible to control the start >> order by controlling the order in which bundles are installed on the >> framework. As per current Felix Framework implementation [1] bundle within >> same start level are started in the order of bundleId. >> The way patch works is >> 1. Bundle which start at start level 1 can define a header >> 'X-Sling-Start-Order' to provide a start order hint. Lower the level then >> earlier the bundle would be started >> 2. BootstrapInstaller would sort the files obtained from directly listing >> based on this header. >> 3. Sorted list would be used to install the bundles >> I understand that this is a very much implementation specific fix and might >> not work if Felix changes the internal logic. But then the feature is meant >> to be used in best effort basis!!. >> [1] >> https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L4873 > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160)
