incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Sling Website > OSGi Installer
Date Tue, 11 Oct 2011 12:00:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/1/_/styles/combined.css?spaceKey=SLINGxSITE&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer">OSGi
Installer</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~cziegeler@apache.org">Carsten
Ziegeler</a>
    </h4>
        <br/>
                         <h4>Changes (4)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >h2. Artifact Handling <br> <br></td></tr>
            <tr><td class="diff-changed-lines" >Once an artifact is detected by
a transformer, it gets a unique id. By default a bundle gets the symbolic name <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">and
version</span> as the unique identifier and a configuration the PID. <br></td></tr>
            <tr><td class="diff-unchanged" >In addition to this id, an artifact
gets a priority information from the provider. The priority is used if an artifact with the
same id is provided several times from different locations. For example if a file system provider
is scanning two directories and an artifact with the same id (like a configuration) is added
to both directories, one should have precedence over the other. This is handled by the priority.
<br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">Artifacts
with the same unique id are grouped and then sorted by priority and maybe other artifact dependent
metadata like the bundle version. Only the first artifact in this sorted group is tried to
be applied! <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h2. Bundle Handling <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >If an installed bundle is managed
via any other OSGi tooling, like uninstalling it through the web console, the OSGi installer
does no action at all! <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">If
a failure occurs during bundle installation or update, the OSGi installer will retry this
as soon as another bundle has been installed. The common use case is an application installation
with several bundles where one bundle depends on another. As they are installed in arbitrary
order, this mechanism ensures that in the end all bundles are properly wired and installed.
<br> <br>When all artifacts have been processed (either install, update or delete),
a package refresh is automatically called. <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h3. Versions and Snapshots <br>
<br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >h2. Configuration Handling <br>
<br></td></tr>
            <tr><td class="diff-changed-lines" >In general the OSGi installer
installs the configuration with the highes priority. <span class="diff-added-words"style="background-color:
#dfd;">For example in combination with the JCR installer provider, a configuration from
_/apps_ is preferred over a configuration for the same service from _/libs_.</span>
<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="OSGiInstaller-Overview"></a>Overview</h1>

<p>The OSGi installer is a central service for handling installs, updates and uninstall
of "artifacts". By default, the installer supports bundles and has an extension for handling
configurations for the OSGi configuration admin.</p>

<p><span class="image-wrap" style=""><img src="/confluence/download/attachments/27828602/Slide14.jpg?version=1&amp;modificationDate=1318322150593"
style="border: 1px solid black" /></span></p>

<p>The OSGi installer itself is "just" the central service managing the tasks and states
of the artifacts. The artifacts can be provided through various providers, e.g. through a
file system provider reading artifacts from configured directories or the jcr provider reading
artifacts from a JCR repository.</p>

<p>A provider is just scanning for artifacts and their removal. It informs the OSGi
installer about new artifacts and removed artifacts. The provider itself has usually no knowledge
about the contents of an artifact. It does not know about bundles, configurations etc.</p>

<p>As the OSGi installer itself is not performing the actual install, update or removal
of an artifact, its possible to install transformers and installer factories. A transformer
inspects the artifacts and tries to detect its type. By default, detecting of bundles and
configurations is supported. The final service is an installer factory creating the actual
task, like install this bundle, update that bundle etc.</p>

<p>It's possible to add own providers, transformers and installer factories to support
custom scenarios.</p>

<h2><a name="OSGiInstaller-ArtifactHandling"></a>Artifact Handling</h2>

<p>Once an artifact is detected by a transformer, it gets a unique id. By default a
bundle gets the symbolic name as the unique identifier and a configuration the PID.<br/>
In addition to this id, an artifact gets a priority information from the provider. The priority
is used if an artifact with the same id is provided several times from different locations.
For example if a file system provider is scanning two directories and an artifact with the
same id (like a configuration) is added to both directories, one should have precedence over
the other. This is handled by the priority.</p>

<p>Artifacts with the same unique id are grouped and then sorted by priority and maybe
other artifact dependent metadata like the bundle version. Only the first artifact in this
sorted group is tried to be applied!</p>

<h2><a name="OSGiInstaller-BundleHandling"></a>Bundle Handling</h2>

<p>In general, the OSGi installer always tries to install the highest version of a bundle
if several bundles with the same symbolic name are provided. In this case higher version wins
over priority.<br/>
If an installed bundle is removed by a provider, for example deleted in the repository, the
OSGi installer uninstall the bundle.<br/>
If a bundle is removed from a provider which is currently not installed, this has no effect
at all.<br/>
If an installed bundle is removed and another version of this bundle is provided (a lower
version), than this one is installed instead. This is basically a downgrade of the bundle.<br/>
If a bundle is installed and a higher version is provided, an upgrade is performed.<br/>
If an installed bundle is managed via any other OSGi tooling, like uninstalling it through
the web console, the OSGi installer does no action at all!</p>

<p>If a failure occurs during bundle installation or update, the OSGi installer will
retry this as soon as another bundle has been installed. The common use case is an application
installation with several bundles where one bundle depends on another. As they are installed
in arbitrary order, this mechanism ensures that in the end all bundles are properly wired
and installed.</p>

<p>When all artifacts have been processed (either install, update or delete), a package
refresh is automatically called.</p>

<h3><a name="OSGiInstaller-VersionsandSnapshots"></a>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><a name="OSGiInstaller-ConfigurationHandling"></a>Configuration Handling</h2>

<p>In general the OSGi installer installs the configuration with the highes priority.
For example in combination with the JCR installer provider, a configuration from <em>/apps</em>
is preferred over a configuration for the same service from <em>/libs</em>.</p>
    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=27828602&revisedVersion=6&originalVersion=5">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message