You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@felix.apache.org by bu...@apache.org on 2013/09/22 21:52:16 UTC
svn commit: r879469 - in /websites/staging/felix/trunk/content: ./
documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-using-annotations/dependencymanager-annotations-lifecycle.html
Author: buildbot
Date: Sun Sep 22 19:52:15 2013
New Revision: 879469
Log:
Staging update by buildbot for felix
Modified:
websites/staging/felix/trunk/content/ (props changed)
websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-using-annotations/dependencymanager-annotations-lifecycle.html
Propchange: websites/staging/felix/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Sep 22 19:52:15 2013
@@ -1 +1 @@
-1525384
+1525418
Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-using-annotations/dependencymanager-annotations-lifecycle.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-using-annotations/dependencymanager-annotations-lifecycle.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-using-annotations/dependencymanager-annotations-lifecycle.html Sun Sep 22 19:52:15 2013
@@ -87,10 +87,10 @@ or when the bundle is stopped. Unless th
and reactivated, depending on the departure and arrival of required dependencies. The
manager which is in charge of maintaining the state of components is implemented in the
DM Runtime bundle (org.apache.felix.dm.runtime bundle).</p>
-<h2 id="lifecycle-callbacks">Lifecycle Callbacks</h2>
+<h2 id="lifecycle-callbacks">Lifecycle callbacks</h2>
<h3 id="component-activation">Component Activation</h3>
<p>Activating a component consists of the following steps:</p>
-<ol>
+<ul>
<li>
<p>Wait for all required dependencies to be available. When all required dependencies are available:</p>
</li>
@@ -117,16 +117,18 @@ Alternatively, you can also configure so
<p>Start tracking optional dependencies applied on method callbacks (useful for the whiteboard pattern). <em>Notice that NullObject pattern is not applied to optional callback dependencies</em>. In other words, if the dependency is not there, your callback won't be invoked at all. If you need the NullObject pattern, then apply optional dependencies on class fields, not on callback methods.</p>
</li>
<li>
-<p>Else do nothing because the component will trigger itself the startup using the lifecycle controller.</p>
+<p>Else do nothing because the component will trigger itself the startup using the lifecycle controller.</p>
</li>
-</ol>
+</ul>
<h3 id="component-deactivation">Component Deactivation</h3>
-<p>Deactivating a component consists of the following steps:
-1. If the bundle is stopped or if some required dependencies are unavailable, or if the component is deactivated by a factorySet, then:
-1. * Unbind optional dependencies (defined on callback methods). Notice that any optional dependency unavailability does not trigger the component deactivation: the <em>removed</em> callbacks are just invoked, if declared in the annotation.
-1. * Invoke the stop method (annotated wit <em>@Stop</em>), and unregister some OSGi services (if the components provides some services).
-1. * invoke destroy method (annotated with <em>@Destroy</em>).
-1. * invoke <em>removed</em> callbacks for required dependencies, if any.</p>
+<p>Deactivating a component consists of the following steps:</p>
+<ul>
+<li>If the bundle is stopped or if some required dependencies are unavailable, or if the component is deactivated by a factorySet, then:</li>
+<li>Unbind optional dependencies (defined on callback methods). Notice that any optional dependency unavailability does not trigger the component deactivation: the <em>removed</em> callbacks are just invoked, if declared in the annotation.</li>
+<li>Invoke the stop method (annotated wit <em>@Stop</em>), and unregister some OSGi services (if the components provides some services).</li>
+<li>invoke destroy method (annotated with <em>@Destroy</em>).</li>
+<li>invoke <em>removed</em> callbacks for required dependencies, if any.</li>
+</ul>
<h3 id="example">Example</h3>
<p>The following example shows a basic component, which uses the @Start, @Stop, annotation:</p>
<div class="codehilite"><pre><span class="cm">/**</span>
@@ -153,8 +155,8 @@ Alternatively, you can also configure so
</pre></div>
-<h3 id="dynamic-dependency-configuration">Dynamic Dependency Configuration</h3>
-<h4 id="rationale">Rationale</h4>
+<h2 id="dynamic-dependency-configuration">Dynamic Dependency Configuration</h2>
+<h3 id="rationale">Rationale</h3>
<p>We have seen that a component may declare some dependencies and is started when all required dependencies are available. But there are some cases when you may need to define some dependencies filters dynamically, possibly from data picked up from other dependencies (like a configuration dependency for instance).</p>
<p>So, all this is possible using <em>named</em> dependencies: When you assign a name to a dependency; for instance <em>@ServiceDependency(name="foo")</em>, then this has an impact on how the dependency is handled. Indeed, all named dependencies are calculated <em>after</em> the @Init method returns. So from your @Init method, you can then configure your named dependencies, using data provided by already injected dependencies.</p>
<p>To do so, your @Init method is allowed to return a Map containing the filters and required flags for each named dependencies. For a given named dependency, the corresponding filter and required flag must be stored in the Map, using the "<em>filter</em>" and "<em>required</em>" keys, prefixed with the name of the dependency.</p>
@@ -173,7 +175,7 @@ Alternatively, you can also configure so
<p>So, after the init method returns, the map will be used to configure the dependency named "foo", which will then be evaluated. And once the dependency is available, then your @Start callback will be invoked.</p>
-<h4 id="usage-example">Usage example:</h4>
+<h3 id="usage-example">Usage example:</h3>
<p>This is an example of a component X whose dependency "foo" filter is configured from ConfigAdmin. First, we defined a ConfigurationDependency in order to get injected with our configuration. Next, we define a dependency on the <em>FooService</em>, but this time, we declare the annotation like this: <em>@ServiceDependency(</em>{<em>}{</em>}name="foo"<em>{</em>}<em>)</em>. As explained above, The ConfigurationDependency will be injected <em>before</em> the @Init method, and the named dependency ("foo") will be calculated <em>after</em> the @Init method returns. So, from our Init method, we just return a map which contains the filter and required flag for the "foo" dependency, and we actually use the configuration which has already been injected:</p>
<div class="codehilite"><pre><span class="cm">/**</span>
<span class="cm"> * A component whose FooService dependency filter is configured from ConfigAdmin</span>
@@ -217,7 +219,10 @@ Alternatively, you can also configure so
<h2 id="controlling-the-lifecycle">Controlling the Lifecycle</h2>
-<p>As explained in the <em>Component Activation</em> section, a component which provides a service is automatically registered into the OSGi registry, after the @Start method returns. But it is sometimes required to control when the service is really started/published or unpublished/stopped.</p>
+<p>As explained in the <em>Component Activation</em> section, a component which provides a service
+is automatically registered into the OSGi registry, after the @Start method returns.
+But it is sometimes required to control when the service is really started/published or<br />
+unpublished/stopped.</p>
<p>This can be done using the @LifecycleController annotation. This annotation injects a Runnable object that can be invoked once you want to trigger your service startup and publication.</p>
<p>For instance, imagine that your component publishes an OSGi service, but before, it needs to register into a DHT (Distributed Hash Table), whose API is asynchronous: that is: the DHT API will callback you once you are inserted into a node in the DHT. In this case, what you would like to do is to publish your OSGi service, but only after you are inserted into the DHT (when the DHT callbacks you) ... Such a case is supported using the @LifecyceController annotation, which gives you full control of when your component is <em>started/published</em> and <em>unpublished/stopped</em>.</p>
<p>Let's illustrate this use case with a concrete example: First here is the DHT asynchronous API:</p>
@@ -268,7 +273,8 @@ Alternatively, you can also configure so
<h2 id="dynamic-service-properties">Dynamic Service Properties</h2>
-<p>When a component provides an OSGi Service, the service properties are calculated as the following:</p>
+<p>When a component provides an OSGi Service, the service properties are calculated as the
+following:</p>
<ul>
<li>Any properties specified in the @Component annotation are used to provide the OSGi Service</li>
<li>Any properties provided by a FactorySet are also inserted in the published service</li>
@@ -300,9 +306,10 @@ Alternatively, you can also configure so
<li>foo2=bar2 (propagated by our ConfigurationDependency dependency)</li>
<li>foo3=bar3 (specified dynamically in the map returned from our start method)</li>
</ul>
-<p>Notice that properties returned by the Map take precedence over other properties, and may override some of them.</p>
+<p>Notice that properties returned by the Map take precedence over other properties, and may
+override some of them.</p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1525384 by pderop on Sun, 22 Sep 2013 15:57:38 +0000
+ Rev. 1525418 by pderop on Sun, 22 Sep 2013 19:52:06 +0000
</div>
<div class="trademarkFooter">
Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project