sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r943139 - in /websites/staging/sling/trunk/content: ./ documentation/bundles/osgi-installer.html
Date Tue, 10 Mar 2015 11:33:37 GMT
Author: buildbot
Date: Tue Mar 10 11:33:37 2015
New Revision: 943139

Staging update by buildbot for sling

    websites/staging/sling/trunk/content/   (props changed)

Propchange: websites/staging/sling/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Tue Mar 10 11:33:37 2015
@@ -1 +1 @@

Modified: websites/staging/sling/trunk/content/documentation/bundles/osgi-installer.html
--- websites/staging/sling/trunk/content/documentation/bundles/osgi-installer.html (original)
+++ websites/staging/sling/trunk/content/documentation/bundles/osgi-installer.html Tue Mar
10 11:33:37 2015
@@ -118,6 +118,17 @@ If an installed bundle is managed via an
 <h3 id="versions-and-snapshots">Versions and Snapshots</h3>
 <p>The OSGi installer asumes that a symbolic name and version (not a snapshot version)
uniquely identifies a bundle. Obviously this is a common development requirement that a released
version of an artifact never changes over time. Therefore, once a bundle with a specific version
is installed, it will not be reinstalled if the corresponding artifact changes. For example,
if  bundle A with version 1.0 is put into the JCR repository, it gets installed. If now this
jar in the repository is overwritten either with the same contents or with a different one,
and this new artifact has again A as the symbolic name and version set to 1.0, nothing will
happen as this exact bundle is already installed.</p>
 <p>During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT (using
the Maven convention). If a bundle with a snapshot version is changed, it gets updated by
the OSGI installer.</p>
+<h2 id="start-level-handling">Start Level Handling</h2>
+<p>The OSGi installer supports handling of start levels for bundles. If the provided
bundle artifacts contain a start level information the bundle is installed with that start
level, otherwise the default start level is used.
+Therefore, for initial provisioning to make use of start levels, the OSGi installer and the
corresponding provider (see below) should run at a very low start level, probably at 1. This
ensure that the bundles with a start level are started with respect to the start level.</p>
+<p>When an update of bundles is performed through the installer, by default the installer
stays in the current start level and updates the bundles. However, if bundles at low start
levels are affected, this might result in a lot of churn going on. Therefore, the OSGi installer
can be configured to use a more intelligent start level handling:</p>
+<li>If the framework property "sling.installer.switchstartlevel" is set to "true" and</li>
+<li>there is no asynchronous install task in the list of tasks to perform, then</li>
+<li>the start level is set to (the lowest level of the bundles to be updated - 1) -
if the start level is lower than the level of the installer itself, the start level of the
installer is used.</li>
+<li>the bundles are updated/installed</li>
+<li>the start level is increased to the previous level</li>
 <h2 id="plugins">Plugins</h2>
 <h3 id="factories">Factories</h3>
 <p>An installer factory provides support for a specific artifact type, like a configuration
or a deployment package etc.</p>
@@ -132,7 +143,7 @@ If an installed bundle is managed via an
 <li><a href="/documentation/bundles/jcr-installer-provider.html">JCR Installer
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1648494 by cziegeler on Tue, 30 Dec 2014 09:45:30 +0000
+        Rev. 1665483 by cziegeler on Tue, 10 Mar 2015 11:33:30 +0000
       <div class="trademarkFooter"> 
         Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project

View raw message