felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject 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
Date Sun, 22 Sep 2013 19:52:16 GMT
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&nbsp; 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:&nbsp; 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:&nbsp; 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



Mime
View raw message