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 2015/09/01 08:05:20 UTC

svn commit: r963800 [7/16] - in /websites/staging/felix/trunk/content: ./ documentation/ documentation/community/ documentation/development/ documentation/faqs/ documentation/subprojects/ documentation/subprojects/apache-felix-commons/ documentation/su...

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="creating-instances">Creating instances</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="creating-instances">Creating instances<a class="headerlink" href="#creating-instances" title="Permanent link">&para;</a></h1>
 <div class="toc">
 <ul>
 <li><a href="#creating-instances">Creating instances</a></li>
@@ -207,7 +218,7 @@
 <li><a href="#creating-instances-with-declarations">Creating instances with declarations</a></li>
 </ul>
 </div>
-<h1 id="component-types-and-instances">Component types and instances</h1>
+<h1 id="component-types-and-instances">Component types and instances<a class="headerlink" href="#component-types-and-instances" title="Permanent link">&para;</a></h1>
 <p>iPOJO is a component model enforcing strictly the distinction between component types and instances. The relationship between types and instances is the same as the one between classes and objects in OOP. You can <em>instantiate</em> as many instances as you want from a component type. These instances can be configured with different properties. As a consequence, just using @Component or <component/> declares a component type, not an instance. So, at runtime, nothing will happen until you actually declare or create an instance.</p>
 <p>iPOJO provides several ways to create instances, this page presents these possibilities:</p>
 <ul>
@@ -218,7 +229,7 @@
 <li>using the OSGi Configuration Admin</li>
 <li>using the <code>DeclarationBuilderService</code></li>
 </ul>
-<h1 id="instantiate">@Instantiate</h1>
+<h1 id="instantiate">@Instantiate<a class="headerlink" href="#instantiate" title="Permanent link">&para;</a></h1>
 <p>The @Instantiate annotation is the simplest way to declare an instance. In a class annotated with @Component, you just add the @Instantiate annotation. It instructs iPOJO to declare an instance of the component type described by the current class. </p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Component</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Instantiate</span><span class="o">;</span>
@@ -249,7 +260,7 @@
 <li>you can't provide a configuration to the instance</li>
 <li>you can declare only one instance</li>
 </ul>
-<h2 id="declaring-a-singleton-instance">Declaring a singleton instance</h2>
+<h2 id="declaring-a-singleton-instance">Declaring a singleton instance<a class="headerlink" href="#declaring-a-singleton-instance" title="Permanent link">&para;</a></h2>
 <p>The @Instance annotation is particularly useful to declare singleton instances, i.e. a component type with only one instance. To create a singleton instance, combine the @Instantiate annotation and the <code>publicFactory</code> attribute of the @Component annotation:</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Component</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Instantiate</span><span class="o">;</span>
@@ -263,7 +274,7 @@
 
 
 <p>The <code>publicFactory=false</code> attribute makes the component type <em>private</em>, so invisible from other bundles. No one else would be able to create another instance of the component type.</p>
-<h1 id="configuration">@Configuration</h1>
+<h1 id="configuration">@Configuration<a class="headerlink" href="#configuration" title="Permanent link">&para;</a></h1>
 <p>This second annotation is used on classes to create one or several instances using a fluent API.</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.configuration.Configuration</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.configuration.Instance</span><span class="o">;</span>
@@ -307,7 +318,7 @@
 
 
 <p>Using this configuration DSL allows creating a set of instances that you can configure easily.</p>
-<h2 id="configuration-including-lists-and-maps">Configuration including lists and maps</h2>
+<h2 id="configuration-including-lists-and-maps">Configuration including lists and maps<a class="headerlink" href="#configuration-including-lists-and-maps" title="Permanent link">&para;</a></h2>
 <p>The <code>setto</code> method accepts any object. To ease creating collections, the API proposed two methods to handle lists and maps:</p>
 <div class="codehilite"><pre><span class="n">instance</span><span class="o">()</span>
         <span class="o">.</span><span class="na">of</span><span class="o">(</span><span class="n">Mycomponent</span><span class="o">.</span><span class="na">class</span><span class="o">)</span>
@@ -322,7 +333,7 @@
 </pre></div>
 
 
-<h2 id="methods-returning-instance-objects">Methods returning Instance objects</h2>
+<h2 id="methods-returning-instance-objects">Methods returning Instance objects<a class="headerlink" href="#methods-returning-instance-objects" title="Permanent link">&para;</a></h2>
 <p>The class annotated with @Configuration does not only handle fields, but also handles methods returning Instance object. These methods can have either no arguments or the BundleContext as unique argument.</p>
 <div class="codehilite"><pre><span class="n">Instance</span> <span class="nf">instance1</span><span class="o">()</span> <span class="o">{</span>
     <span class="k">return</span> <span class="nf">instance</span><span class="o">().</span><span class="na">of</span><span class="o">(</span><span class="n">MyComponent</span><span class="o">.</span><span class="na">class</span><span class="o">);</span>
@@ -336,7 +347,7 @@
 
 <p>As for fields, the method name is used as instance name except if the instance already received a name.</p>
 <p><em>Note</em>: the injected BundleContext is the BundleContext of the bundle containing the annotated class.</p>
-<h1 id="declaring-instances-in-xml">Declaring instances in XML</h1>
+<h1 id="declaring-instances-in-xml">Declaring instances in XML<a class="headerlink" href="#declaring-instances-in-xml" title="Permanent link">&para;</a></h1>
 <p>You can declare instances using the iPOJO XML descriptor. If you use XML to describe you component type, you probably want to use this way to create your instances.</p>
 <div class="codehilite"><pre>    <span class="nt">&lt;instance</span> <span class="na">component=</span><span class="s">&quot;factory.name&quot;</span><span class="nt">&gt;</span>
     <span class="nt">&lt;property</span> <span class="na">name=</span><span class="s">&quot;property&quot;</span> <span class="na">value=</span><span class="s">&quot;value&quot;</span><span class="nt">/&gt;</span>
@@ -348,7 +359,7 @@
 <p>The <em>component</em> attribute specifies the targeted component type. Generally it's the qualified classname of the component class, but can also be the name of the factory if one is specified.</p>
 <p>The <em>property</em> elements have a mandatory <code>name</code> attribute to set the property name, and a <code>value</code> attribute to specify the String form of the property's value.</p>
 <p>You can declare as many as you want instances in the XML descriptor. They can targets component types declared within the same bundles or not.</p>
-<h2 id="setting-the-instance-name">Setting the instance name</h2>
+<h2 id="setting-the-instance-name">Setting the instance name<a class="headerlink" href="#setting-the-instance-name" title="Permanent link">&para;</a></h2>
 <p>To set the instance name you can use the <em>name</em> attribute of the <em>instance</em> element or the <em>instance.name</em> property:</p>
 <div class="codehilite"><pre><span class="nt">&lt;instance</span> <span class="na">component=</span><span class="s">&quot;…MyComponent&quot;</span> <span class="na">name=</span><span class="s">&quot;my-instance&quot;</span><span class="nt">/&gt;</span>
 <span class="nt">&lt;instance</span> <span class="na">component=</span><span class="s">&quot;…MyComponent&quot;</span><span class="nt">&gt;</span>
@@ -357,7 +368,7 @@
 </pre></div>
 
 
-<h2 id="describing-complex-properties-in-xml">Describing complex properties in XML</h2>
+<h2 id="describing-complex-properties-in-xml">Describing complex properties in XML<a class="headerlink" href="#describing-complex-properties-in-xml" title="Permanent link">&para;</a></h2>
 <p>The <em>property</em> element can be used to configure complex types such as arrays, lists and maps.</p>
 <div class="codehilite"><pre><span class="c">&lt;!--Creates a string array--&gt;</span>
 <span class="nt">&lt;property</span> <span class="na">name=</span><span class="s">&quot;array&quot;</span> <span class="na">type=</span><span class="s">&quot;array&quot;</span><span class="nt">&gt;</span> 
@@ -397,10 +408,10 @@
 </pre></div>
 
 
-<h1 id="creating-instances-using-the-factory-service">Creating instances using the Factory service</h1>
+<h1 id="creating-instances-using-the-factory-service">Creating instances using the Factory service<a class="headerlink" href="#creating-instances-using-the-factory-service" title="Permanent link">&para;</a></h1>
 <p>In previous technics to create instances were declarative. You declare an instance. This instance is going to be created as soon as the component type becomes available, and disappears as soon as the component type leaves. The technic presented here is a programatic way.</p>
 <p>Each (non private) component types are exposed as an OSGi service. You can use this OSGi service to create, reconfigure and dispose instances from your code.</p>
-<h2 id="the-factory-service">The Factory service</h2>
+<h2 id="the-factory-service">The Factory service<a class="headerlink" href="#the-factory-service" title="Permanent link">&para;</a></h2>
 <p>The published service interface is <code>[org.apache.felix.ipojo.Factory](http://felix.apache.org/ipojo/api/1.12.1/org/apache/felix/ipojo/Factory.html)</code> and provides the following methods:</p>
 <div class="codehilite"><pre><span class="cm">/**</span>
 <span class="cm"> * Creates an instance manager (i.e. component type instance).</span>
@@ -429,7 +440,7 @@
 
 
 <p>If you grab all factories, you can check their names using the <code>getName()</code> method.</p>
-<h2 id="creating-instances_1">Creating instances</h2>
+<h2 id="creating-instances_1">Creating instances<a class="headerlink" href="#creating-instances_1" title="Permanent link">&para;</a></h2>
 <p>Once you have the right Factory service, you can create instances using <code>createComponentInstance</code> method. This method returns a reference on the created instance. This method receives an optional configuration containing key-value pairs. Values are either objects (of the adequate type) or Strings used to create objects. This configuration can be 'null' if no properties have to be pushed.</p>
 <p>You can set the instance name using the 'instance.name' property can be used to specify the instance name.</p>
 <p>Instances are automatically started when created. However, the instance can be invalid, if at least one handler is not valid. </p>
@@ -453,13 +464,13 @@
 </pre></div>
 
 
-<h2 id="disposing-created-instance">Disposing created instance</h2>
+<h2 id="disposing-created-instance">Disposing created instance<a class="headerlink" href="#disposing-created-instance" title="Permanent link">&para;</a></h2>
 <p>You can only disposed instances that you created. To dispose an instance, just call the <code>dispose</code> method on the ComponentInstance object (returned by the createComponentInstance method).</p>
 <div class="codehilite"><pre><span class="n">instance</span><span class="o">.</span><span class="na">dispose</span><span class="o">();</span>
 </pre></div>
 
 
-<h2 id="reconfiguring-instance">Reconfiguring instance</h2>
+<h2 id="reconfiguring-instance">Reconfiguring instance<a class="headerlink" href="#reconfiguring-instance" title="Permanent link">&para;</a></h2>
 <p>To reconfigure an instance, call the 'reconfigure' method on the ComponentInstance object. This method receives the new set of properties. Be aware that the 'instance.name' property cannot be changed.</p>
 <div class="codehilite"><pre><span class="n">Properties</span> <span class="n">props2</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Properties</span><span class="o">();</span>
 <span class="n">props2</span><span class="o">.</span><span class="na">put</span><span class="o">(</span><span class="s">&quot;foo&quot;</span><span class="o">,</span> <span class="s">&quot;abc&quot;</span><span class="o">);</span>
@@ -467,14 +478,14 @@
 </pre></div>
 
 
-<h2 id="following-the-factory-state">Following the factory state</h2>
+<h2 id="following-the-factory-state">Following the factory state<a class="headerlink" href="#following-the-factory-state" title="Permanent link">&para;</a></h2>
 <p>Factories can becomes invalid if one of the handler they require is not available. Basically, handlers are pieces of iPOJO containers. </p>
 <p>You can check the factory state using the <code>Factory.getState()</code> method. This method returns <code>1</code> if the factory is valid, <code>0</code> if not.</p>
 <p>You can also register a <code>org.apache.felix.ipojo.FactoryStateListener</code> object on the factory to be notified of the changes.</p>
-<h1 id="creating-instances-using-the-osgi-configuration-admin">Creating instances using the OSGi Configuration Admin</h1>
+<h1 id="creating-instances-using-the-osgi-configuration-admin">Creating instances using the OSGi Configuration Admin<a class="headerlink" href="#creating-instances-using-the-osgi-configuration-admin" title="Permanent link">&para;</a></h1>
 <p>The configuration admin service is a standard service specified by the OSGi Alliance to handle configurations. It allows an operator to configured the deployed bundles, and so iPOJO instances. </p>
 <p>iPOJO supports the configuration admin and you can create, reconfigure and dispose instanced using this service.</p>
-<h2 id="creating-instances_2">Creating instances</h2>
+<h2 id="creating-instances_2">Creating instances<a class="headerlink" href="#creating-instances_2" title="Permanent link">&para;</a></h2>
 <p>Creating an instance is done by creating a <em>factory</em> configuration:</p>
 <div class="codehilite"><pre><span class="n">ConfigurationAdmin</span> <span class="n">admin</span> <span class="o">=</span> <span class="o">...</span><span class="c1">// Let&#39;s assume with have the configuration admin</span>
 <span class="n">Configuration</span> <span class="n">conf</span> <span class="o">=</span> <span class="n">admin</span><span class="o">.</span><span class="na">createFactoryConfiguration</span><span class="o">(</span><span class="s">&quot;...MyComponent&quot;</span><span class="o">,</span> <span class="s">&quot;?&quot;</span><span class="o">);</span>
@@ -490,12 +501,12 @@
 
 <p>To create the <em>factory</em> configuration, use the <code>createFactoryConfiguration</code> method on the Configuration Admin object. The first argument is the factory name. The second is the location binding. Using "?" is a wildcard, for more details, check the configuration admin specification.</p>
 <p>You populate this configuration with a dictionary. The configuration is actually created using the <code>update</code> method. </p>
-<h2 id="reconfiguring-instances">Reconfiguring instances</h2>
+<h2 id="reconfiguring-instances">Reconfiguring instances<a class="headerlink" href="#reconfiguring-instances" title="Permanent link">&para;</a></h2>
 <p>If the instance was created using the Configuration Admin and you own the Configuration object used for the creation, the reconfiguration is done by calling the <code>update</code> method with the new properties.</p>
 <p>If the instance was already created, you can configure it using a <em>regular</em> configuration. The pid given to this configuration is the instance name.</p>
-<h2 id="disposing-instances">Disposing instances</h2>
+<h2 id="disposing-instances">Disposing instances<a class="headerlink" href="#disposing-instances" title="Permanent link">&para;</a></h2>
 <p>To dispose an instance, just call the <code>delete</code> method on the configuration object you used to configure the instance.</p>
-<h1 id="creating-instances-with-declarations">Creating instances with declarations</h1>
+<h1 id="creating-instances-with-declarations">Creating instances with declarations<a class="headerlink" href="#creating-instances-with-declarations" title="Permanent link">&para;</a></h1>
 <p>Declarations offer a nice way to declares instances in a programmatic way. If not retracted by hand,
 they're bound to the declaring bundle lifecycle (i.e. are unregistered when the bundle is not <code>ACTIVE</code>
 anymore).</p>
@@ -546,7 +557,7 @@ declarations: service publication and un
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1571278 by guillaume on Mon, 24 Feb 2014 13:20:49 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.html Tue Sep  1 06:05:17 2015
@@ -171,9 +171,20 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="describing-your-ipojo-components">Describing your iPOJO components</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="describing-your-ipojo-components">Describing your iPOJO components<a class="headerlink" href="#describing-your-ipojo-components" title="Permanent link">&para;</a></h1>
 <p><em>This section describes the different features supported by iPOJO. This page aims to answer to the following question: "What can I write in my iPOJO component descriptor?"</em></p>
-<h2 id="core-features">Core features</h2>
+<h2 id="core-features">Core features<a class="headerlink" href="#core-features" title="Permanent link">&para;</a></h2>
 <p>Core features are provided with the iPOJO runtime bundles. You can use it directly, as soon as the iPOJO runtime is deployed.</p>
 <ul>
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.html">How to require a service</a></li>
@@ -183,7 +194,7 @@
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.html">How to enable/disable instance introspection</a></li>
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.html">How to act on the instance state from the implementation</a></li>
 </ul>
-<h2 id="extensions">Extensions</h2>
+<h2 id="extensions">Extensions<a class="headerlink" href="#extensions" title="Permanent link">&para;</a></h2>
 <p>Extensions <em>extend</em> the iPOJO model to add a specific functionality. This is made thanks to the external handler mechanism. So before using one of these features, deploy the attached external handler.</p>
 <ul>
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.html">How to receive and send events with the Event Admin</a></li>
@@ -192,7 +203,7 @@
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/white-board-pattern-handler.html">How to implement a whiteboard pattern</a></li>
 <li><a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/temporal-service-dependency.html">How to wait for services and inject proxies</a></li>
 </ul>
-<h2 id="a-missing-functionality">A missing functionality ?</h2>
+<h2 id="a-missing-functionality">A missing functionality ?<a class="headerlink" href="#a-missing-functionality" title="Permanent link">&para;</a></h2>
 <p>iPOJO component model is extensible. So, you can implement your own handler managing you specific requirement. Refer the handler development guide (<a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.html">How to write your own handler</a>) for more details.</p>
         </div>
     </div>
@@ -208,7 +219,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1445489 by clement on Wed, 13 Feb 2013 07:25:24 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="introspection-and-architecture">Introspection and Architecture</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="introspection-and-architecture">Introspection and Architecture<a class="headerlink" href="#introspection-and-architecture" title="Permanent link">&para;</a></h1>
 <p><em>The architecture feature allows obtaining an architectural / component view of your systems. It exposes a snapshot of the present instances &amp; factories, the state of these instances... Moreover; iPOJO defines an 'arch' command displaying this architecture in Felix. You need to install <a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.html">the arch command</a>.</em></p>
 <div class="toc">
 <ul>
@@ -184,16 +195,16 @@
 </li>
 </ul>
 </div>
-<h2 id="reflection-on-component-instances">Reflection on component instances</h2>
+<h2 id="reflection-on-component-instances">Reflection on component instances<a class="headerlink" href="#reflection-on-component-instances" title="Permanent link">&para;</a></h2>
 <p>The architecture feature does "reflection" on the iPOJO containers. It gathers information about the component (state, class name ...), requirement (state, multiple, optional ...), provided services (state, properties) ... Each handler can participate to the architecture. This information allows you to know why an instance does not start, or why the component does not publish / provide a service.</p>
-<h2 id="metadata">Metadata</h2>
+<h2 id="metadata">Metadata<a class="headerlink" href="#metadata" title="Permanent link">&para;</a></h2>
 <p>The architecture (i.e. instance introspection) is activated by default. To disable it, you need to add an attribute <code>architecture="false"</code> to the component element:</p>
 <div class="codehilite"><pre><span class="nt">&lt;component</span> <span class="na">classname=</span><span class="s">&quot;org.apache.felix.ipojo.hello.impl.HelloServiceImpl&quot;</span> <span class="na">architecture=</span><span class="s">&quot;false&quot;</span><span class="nt">&gt;</span>
 </pre></div>
 
 
 <p>By default, the architecture feature is enabled.</p>
-<h2 id="the-arch-command">The "arch" command</h2>
+<h2 id="the-arch-command">The "arch" command<a class="headerlink" href="#the-arch-command" title="Permanent link">&para;</a></h2>
 <p>The Gogo commands are the following:</p>
 <ul>
 <li><code>ipojo:instances</code> (or just <code>instances</code>) lists the instances and state</li>
@@ -222,7 +233,7 @@ instance component.type<span class="o">=
 
 
 <p>More info on the <code>arch</code> command are available <a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.html">here</a>.</p>
-<h2 id="technical-information">Technical information</h2>
+<h2 id="technical-information">Technical information<a class="headerlink" href="#technical-information" title="Permanent link">&para;</a></h2>
 <p>In fact, when a component enables the architecture introspection, its container exposes an <code>Architecture</code> service. Any architecture requester can obtain information about the instance. For example, the arch command requests all the architecture services and prints the information.</p>
         </div>
     </div>
@@ -238,7 +249,7 @@ instance component.type<span class="o">=
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1475720 by clement on Thu, 25 Apr 2013 12:13:11 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="configuration-handler">Configuration Handler</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="configuration-handler">Configuration Handler<a class="headerlink" href="#configuration-handler" title="Permanent link">&para;</a></h1>
 <p><em>This page presents how to configure component instances. This is managed by the configuration handler. This handler allows the configuration and dynamic reconfiguration of instances. A configuration is basically a set of couple (name, value). The name can be a field name or a property name associated to a field or/and a method. iPOJO also supports complex properties composed by maps, dictionaries, lists and arrays.</em></p>
 <div class="toc">
 <ul>
@@ -185,9 +196,9 @@
 </li>
 </ul>
 </div>
-<h2 id="configurable-properties">Configurable Properties</h2>
+<h2 id="configurable-properties">Configurable Properties<a class="headerlink" href="#configurable-properties" title="Permanent link">&para;</a></h2>
 <p>To support configuration, the component type needs to declare which properties are configurable. These properties are not necessarily service properties but can be internal component properties.</p>
-<h2 id="examples">Examples</h2>
+<h2 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">&para;</a></h2>
 <p>The following code depicts a simple configurable component. The 'm_foo' field will be injected using the 'foo' property, and will also be exposed as a service property. The <code>updateArray</code> method is a 'setter' method where the 'array' property will be injected. Properties injected into field are available in the constructor, setter method are available only after the constructor.</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Provides</span>
@@ -248,7 +259,7 @@
 </pre></div>
 
 
-<h2 id="exposing-a-managed-service">Exposing a Managed Service</h2>
+<h2 id="exposing-a-managed-service">Exposing a Managed Service<a class="headerlink" href="#exposing-a-managed-service" title="Permanent link">&para;</a></h2>
 <p>The ManagedService is a service specified in the OSGi Compendium. It allows reconfiguring an instance with the Configuration Admin. There is two way for an iPOJO instance to expose a Managed Service.</p>
 <ul>
 <li>In the <code>@Component</code> annotation the <code>managedservice</code> attribute defines the managed service PID. In XML this is done using the <code>pid</code> attribute in the properties element (XML)</li>
@@ -286,9 +297,9 @@
 
 <p>The managed service pid is the identifier used by the Configuration Admin to attach configuration to Managed Services. First this pid must be unique (as any pid in OSGi). Moreover, this pid cannot be the same one that the pid used in the Managed Service Factory to create the instance (if you use this way to create your instance).</p>
 <p>When an instance is reconfigured with the Managed Service, the configuration is propagated if the propagation is enabled.</p>
-<h2 id="dynamic-reconfiguration-using-factories-or-managedservicefactories">Dynamic Reconfiguration using Factories or ManagedServiceFactories</h2>
+<h2 id="dynamic-reconfiguration-using-factories-or-managedservicefactories">Dynamic Reconfiguration using Factories or ManagedServiceFactories<a class="headerlink" href="#dynamic-reconfiguration-using-factories-or-managedservicefactories" title="Permanent link">&para;</a></h2>
 <p>iPOJO instances support dynamic reconfiguration. To reconfigure an instance you can use both iPOJO <code>Factory</code> and the <code>ManagedServiceFactory</code> services exposed by the factory of the targeted instance. By calling the method <em>reconfigure</em> or <em>update</em> (according of the service you use), the handler receive the new configuration and apply it. If the propagation is activated, the service registrations are updated too. If there is an  <code>updated</code> callback, the callback is invoked.</p>
-<h2 id="being-notified-when-a-reconfiguration-is-completed">Being notified when a reconfiguration is completed</h2>
+<h2 id="being-notified-when-a-reconfiguration-is-completed">Being notified when a reconfiguration is completed<a class="headerlink" href="#being-notified-when-a-reconfiguration-is-completed" title="Permanent link">&para;</a></h2>
 <p>Sometimes you need to be notified when a reconfiguration is done (all setter method called). This can be done thanks to the <code>updated</code> attribute. This attribute specifies a method claeed when a configuration/reconfiguration is completed. This method receives a <code>Dictionary</code> containing the properties (pair <key,value>). Properties with no value are not in the received configuration.</p>
 <p>Updated callback are declared as follow using annotations:</p>
 <div class="codehilite"><pre><span class="nd">@Updated</span>
@@ -329,7 +340,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1531515 by clement on Sat, 12 Oct 2013 08:32:37 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="lifecycle-controller-handler">Lifecycle Controller Handler</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="lifecycle-controller-handler">Lifecycle Controller Handler<a class="headerlink" href="#lifecycle-controller-handler" title="Permanent link">&para;</a></h1>
 <p><em>The lifecycle controller allows a component implementation to participate to the instance lifecycle. So, you can immediately decide to stop an instance if the configuration is incorrect (correct properties, accessible resources...). The licecyel controller impacts the instance lifecycle, if you want to impact only the registered service, have a look to the service controller (<a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html">service providing</a>.</em></p>
 <div class="toc">
 <ul>
@@ -182,10 +193,10 @@
 </li>
 </ul>
 </div>
-<h2 id="ipojo-instance-lifecycle-lifecycle-controller">iPOJO instance lifecycle &amp; Lifecycle controller</h2>
+<h2 id="ipojo-instance-lifecycle-lifecycle-controller">iPOJO instance lifecycle &amp; Lifecycle controller<a class="headerlink" href="#ipojo-instance-lifecycle-lifecycle-controller" title="Permanent link">&para;</a></h2>
 <p>Once started, iPOJO instances can be either valid or invalid. The decision comes from handlers. An instance is valid if every plugged handler are valid. Basically it means that all required services are available. As soon as one handler becomes invalid, the instance becomes invalid.</p>
 <p>The lifecycle controller just monitors a field inside the POJO class. When this field becomes <code>false</code>, the handler becomes invalid, and so the instance becomes invalid. When the field get the <code>true</code> value, the handler becomes valid, and if all handlers are valid, the instance becomes valid.</p>
-<h2 id="an-example">An example</h2>
+<h2 id="an-example">An example<a class="headerlink" href="#an-example" title="Permanent link">&para;</a></h2>
 <p>Imagine the following component :</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="kd">public</span> <span class="kd">class</span> <span class="nc">LifecycleControllerTest</span> <span class="o">{</span>
@@ -232,7 +243,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1475720 by clement on Thu, 25 Apr 2013 12:13:11 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="event-admin-handlers">Event Admin Handlers</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="event-admin-handlers">Event Admin Handlers<a class="headerlink" href="#event-admin-handlers" title="Permanent link">&para;</a></h1>
 <p><em>The goal of the Event Admin Handlers is to allow event communications between iPOJO component instances. The implementation of these handlers relies on an event admin services. It enables the iPOJO component to listen to a list of topics and to receive all related events. It also allows components to send events in an easy way.</em></p>
 <div class="toc">
 <ul>
@@ -209,7 +220,7 @@
 <p>The <code>@Publisher</code> annotation is now deprecated and replaced by <code>@Publishes</code>.</p>
 </div>
 
-<h2 id="an-example">An example</h2>
+<h2 id="an-example">An example<a class="headerlink" href="#an-example" title="Permanent link">&para;</a></h2>
 <p>Hereafter is presented a small example :</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Instantiate</span>
@@ -250,14 +261,14 @@
 
 
 <p>In XML, you need to specify the namespace of the Handler. You can find here one event subscriber (named mySubscriber) and one event publisher (named myPublisher). In these handler configurations, the name parameter is mandatory. The topics parameter is optional as it can be specified in the instance configuration. The callback parameter of the mySubscriber element is mandatory and indicates the method that handles received events. In this case, this method must have a single argument of type org.osgi.service.event.Event. The field parameter of the myPublisher element indicates the field (of type org.apache.felix.ipojo.handlers.event.publisher.Publisher) that is used by the POJO to send events on the specified topics. All type compliance will be checked by the handler at component instantiation time.</p>
-<h2 id="download">Download</h2>
+<h2 id="download">Download<a class="headerlink" href="#download" title="Permanent link">&para;</a></h2>
 <p>The event admin handlers (to send and receive events) are available in the Felix trunk in the iPOJO project. See the <a href="/documentation/subprojects/apache-felix-ipojo/download.html">Download</a> page to download and compile these sources.</p>
-<h2 id="how-does-it-work">How does it work?</h2>
+<h2 id="how-does-it-work">How does it work?<a class="headerlink" href="#how-does-it-work" title="Permanent link">&para;</a></h2>
 <p>The handler will parse the description provided in the metadata, and register for you the EventHandler in the OSGi Registry. On one hand, your POJO will receive each event through the handler. With this handler you can specify different callback methods for different topics. On the other side, the handler instantiates and injects configured Publisher references in your POJO, so you can send events transparently through these publishers.</p>
-<h2 id="eventhandler-specification">EventHandler Specification</h2>
+<h2 id="eventhandler-specification">EventHandler Specification<a class="headerlink" href="#eventhandler-specification" title="Permanent link">&para;</a></h2>
 <p>Here you can find all configuration options of the EventAdmin handler. As seen before, the handler contains two components : the event subscriber and the event publisher. These components can be configured, using several attributes, as described below. Some of these attributes can be (re)defined in the instance configuration.</p>
 <p><em>Handler namespace :</em> <em>org.apache.felix.ipojo.handlers.event</em></p>
-<h3 id="event-subscriber-attributes">Event subscriber attributes</h3>
+<h3 id="event-subscriber-attributes">Event subscriber attributes<a class="headerlink" href="#event-subscriber-attributes" title="Permanent link">&para;</a></h3>
 <table class="table table-bordered">
     <thead>
         <tr>
@@ -300,7 +311,7 @@
     </tbody>
 </table>
 
-<h3 id="event-publisher-attributes">Event publisher attributes</h3>
+<h3 id="event-publisher-attributes">Event publisher attributes<a class="headerlink" href="#event-publisher-attributes" title="Permanent link">&para;</a></h3>
 <p><table class="table table-bordered">
     <thead>
         <tr>
@@ -337,24 +348,24 @@
         </tr>
     </tbody>
 </table></p>
-<h3 id="instance-configuration">Instance configuration</h3>
+<h3 id="instance-configuration">Instance configuration<a class="headerlink" href="#instance-configuration" title="Permanent link">&para;</a></h3>
 <p>Some of the described attributes can be (re)defined in the instance configuration section of your metadata file. Its permits to configure event management instance by instance. The following properties are used by the handler :</p>
 <ul>
 <li><em>event.topics</em> : overrides <em>topics</em> attribute, available for both subscribers and publishers configuration</li>
 <li><em>event.filter</em> : overrides <em>filter</em> attribute, available for subscribers configuration only.</li>
 </ul>
-<h3 id="publisher-interface">Publisher interface</h3>
+<h3 id="publisher-interface">Publisher interface<a class="headerlink" href="#publisher-interface" title="Permanent link">&para;</a></h3>
 <p>The Publisher interface is the link between the component code and the handler. It permits to publish events on the topics specified in the component's description (or instance configuration). The implemented methods are :</p>
 <ul>
 <li><code>public void send(Dictionary content)</code> : This method is used to send a    standard event, with the specified content. Some specific properties may be added in the content to satisfy EventAdmin specification (e.g., event.topic).</li>
 <li><code>public void sendData(Object  o)</code> : This method is the easier way to send data. The given object is placed in the event dictionary according  to the <em>data-key</em> attribute (or its default value). Then, this  dictionary is sent as a regular event.</li>
 </ul>
-<h2 id="handler-architecture">Handler Architecture</h2>
+<h2 id="handler-architecture">Handler Architecture<a class="headerlink" href="#handler-architecture" title="Permanent link">&para;</a></h2>
 <p>Here is shown the global architecture of the EventHandler : the interactions between the user components (i.e., POJO), the handler and the OSGi runtime environment.</p>
 <p><img src="handler-arch.png"></p>
-<h2 id="eventhandler-features">EventHandler Features</h2>
+<h2 id="eventhandler-features">EventHandler Features<a class="headerlink" href="#eventhandler-features" title="Permanent link">&para;</a></h2>
 <p>In this section, you will find some examples of the handler's features.</p>
-<h3 id="instance-customization">Instance customization</h3>
+<h3 id="instance-customization">Instance customization<a class="headerlink" href="#instance-customization" title="Permanent link">&para;</a></h3>
 <p>As described in the 'Instance configuration' section, you can (re)define some of the subscribers or publishers attributes. You can notice that required attributes that are not defined in the component description must be defined in the instance configuration section. Hereafter is an example of an instance configuration of this handler :</p>
 <div class="codehilite"><pre><span class="nt">&lt;ipojo&gt;</span>
     <span class="nt">&lt;instance</span> <span class="na">component=</span><span class="s">&quot;...MyComponent&quot;</span><span class="nt">&gt;</span>
@@ -371,7 +382,7 @@
 </pre></div>
 
 
-<h3 id="data-events">Data events</h3>
+<h3 id="data-events">Data events<a class="headerlink" href="#data-events" title="Permanent link">&para;</a></h3>
 <p>One of the most important features of the EventHandler is the capability of sending and receiving data events. You may know that the OSGi EventAdmin Service allows bundles to send custom objects in events, inserting them in the event's dictionary. The EventHandler hides the dictionary manipulation and allows iPOJO components to receive custom objects at any time.</p>
 <p>First, you have define the <em>data-key</em> attribute in the publisher configuration (<code>dataKey</code> in annotations). Sent objects will be contained in the event dictionary and are accessible with the "user.data" key. </p>
 <div class="codehilite"><pre><span class="nt">&lt;ipojo</span>
@@ -438,12 +449,12 @@
 <li>data-key is replaced by <code>dataKey</code></li>
 <li>data-type is replaced by <code>dataType</code></li>
 </ul>
-<h3 id="note-on-synchronous-event-sending">Note on synchronous event sending</h3>
+<h3 id="note-on-synchronous-event-sending">Note on synchronous event sending<a class="headerlink" href="#note-on-synchronous-event-sending" title="Permanent link">&para;</a></h3>
 <p>By default, events are sent using asynchronous sending (a.k.a.<em>post</em> in OSGi EventAdmin). You can use synchronous sending by defining the <em>synchronous</em> attribute of your publisher to true.</p>
 <p>The behavior of synchronous event sending is particular when you specify several topics in the publisher description. The event is synchronously sent to each topic, one by one. So when you return from this function, you can be sure that the event has been delivered to each topic.</p>
-<h3 id="publisher-instance-information">Publisher instance information</h3>
+<h3 id="publisher-instance-information">Publisher instance information<a class="headerlink" href="#publisher-instance-information" title="Permanent link">&para;</a></h3>
 <p>All events sent by a publisher contains the name of the component instance that sent them. Its enables to filter received events depending the sender instance. The instance name is accessible in the event dictionary by the key <em>publisher.instance.name</em>. Despite it goes against MOM principles, this property is useful to trace events and especially event sources.</p>
-<h3 id="configuring-the-handler-with-annotations">Configuring the handler with annotations</h3>
+<h3 id="configuring-the-handler-with-annotations">Configuring the handler with annotations<a class="headerlink" href="#configuring-the-handler-with-annotations" title="Permanent link">&para;</a></h3>
 <p>It is possible to configure the handler with a simple annotations available in the annotation pack ('annotation' project in the iPOJO trunk). Here is an example of usage:</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Component</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.handlers.event.Subscriber</span><span class="o">;</span>
@@ -493,7 +504,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1477520 by clement on Tue, 30 Apr 2013 09:43:18 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="the-extender-pattern-handler">The extender pattern handler</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="the-extender-pattern-handler">The extender pattern handler<a class="headerlink" href="#the-extender-pattern-handler" title="Permanent link">&para;</a></h1>
 <p><em>The objective of this handler is to simplify the development of extender-based architecture. This architecture-style is based on two different entities:</em></p>
 <ul>
 <li><em>The extender (also called host)</em> </li>
@@ -189,7 +200,7 @@
 </li>
 </ul>
 </div>
-<h2 id="the-extender-pattern">The Extender pattern</h2>
+<h2 id="the-extender-pattern">The Extender pattern<a class="headerlink" href="#the-extender-pattern" title="Permanent link">&para;</a></h2>
 <p>This architecture-style is based on two different roles:</p>
 <ul>
 <li>The extender </li>
@@ -200,7 +211,7 @@
 Implementing an extender pattern could be complex as the extender needs to track these marks dynamically. When a bundle starts, it needs to look at the mark. Then a bundle leave, the extender must release all object created from this bundle.
 This handler tracks bundle for you based on the specified required mark. At each time a matching bundle appears or disappears, a callback is invoked. The mark is currently a header in the bundle manifest.
 Nowadays, a lot of frameworks use this pattern such as iPOJO it-self (to find both bundles containing components and bundles adding a new implementation type), Spring-DM ...</p>
-<h2 id="using-the-handler">Using the handler</h2>
+<h2 id="using-the-handler">Using the handler<a class="headerlink" href="#using-the-handler" title="Permanent link">&para;</a></h2>
 <p>First of all, you need to configure the component type to use the handler such as:</p>
 <div class="codehilite"><pre><span class="nt">&lt;ipojo</span> <span class="na">xmlns:extender=</span><span class="s">&quot;org.apache.felix.ipojo.extender&quot;</span><span class="nt">&gt;</span>
     <span class="nt">&lt;component</span>
@@ -264,7 +275,7 @@ In the previous example, these methods c
 
 
 <p>Notice the different signatures of the methods. The arrival method is called with the arriving bundle and the matching header value (i.e. the value of the My-Extension header of the bundle manifest). The departure method just receives the leaving bundle.</p>
-<h2 id="configuration">Configuration</h2>
+<h2 id="configuration">Configuration<a class="headerlink" href="#configuration" title="Permanent link">&para;</a></h2>
 <p>The handler has only three mandatory attributes:</p>
 <ul>
 <li>Extension: declaring the looked manifest header.</li>
@@ -278,7 +289,7 @@ In the previous example, these methods c
     </p>
 </div>
 
-<h2 id="configuring-the-handler-with-annotations">Configuring the handler with annotations</h2>
+<h2 id="configuring-the-handler-with-annotations">Configuring the handler with annotations<a class="headerlink" href="#configuring-the-handler-with-annotations" title="Permanent link">&para;</a></h2>
 <p>It is possible to configure the handler with a simple annotation available in the annotation pack ('annotations' project in the iPOJO trunk). Here is an example of usage:</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Component</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.osgi.framework.Bundle</span><span class="o">;</span>
@@ -299,7 +310,7 @@ In the previous example, these methods c
 
 
 <p>The <code>extension</code> attribute allows setting the bundle filter.</p>
-<h2 id="a-more-realistic-example">A more realistic example</h2>
+<h2 id="a-more-realistic-example">A more realistic example<a class="headerlink" href="#a-more-realistic-example" title="Permanent link">&para;</a></h2>
 <p>The Junit4OSGi framework, available <a href="https://svn.apache.org/repos/asf/felix/trunk/ipojo/examples/junit4osgi">here</a>, uses this handler to track Junit Test Suite offered by the installed bundles. The Junit4Osgi bundle has a component using this handler to be notified when a bundle with the <code>Test-Suite</code> header appears or leaves.</p>
         </div>
     </div>
@@ -315,7 +326,7 @@ In the previous example, these methods c
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1444686 by clement on Mon, 11 Feb 2013 09:16:09 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="accessing-the-bundle-context">Accessing the bundle context</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="accessing-the-bundle-context">Accessing the bundle context<a class="headerlink" href="#accessing-the-bundle-context" title="Permanent link">&para;</a></h1>
 <p><em>Despite iPOJO hides most of the OSGi mechanisms, you often need to access the <code>Bundle Context</code>. This page explains how you can access to the bundle context from your component code.</em></p>
 <div class="toc">
 <ul>
@@ -183,10 +194,10 @@
 </li>
 </ul>
 </div>
-<h2 id="bundle-context">Bundle Context</h2>
+<h2 id="bundle-context">Bundle Context<a class="headerlink" href="#bundle-context" title="Permanent link">&para;</a></h2>
 <p>The <code>BundleContext</code> is an object provided by the OSGi Framework to access services as well as resources contained in bundles. Using the bundle context is often required in the later case, i.e. loading files contained in the bundle.
 The API of the bundle context is available <a href="http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html">here</a>.</p>
-<h2 id="retrieving-the-bundle-context-as-constructor-parameter">Retrieving the Bundle Context as constructor parameter</h2>
+<h2 id="retrieving-the-bundle-context-as-constructor-parameter">Retrieving the Bundle Context as constructor parameter<a class="headerlink" href="#retrieving-the-bundle-context-as-constructor-parameter" title="Permanent link">&para;</a></h2>
 <p>The first way to retrieve the bundle context is as a constructor parameter:</p>
 <div class="codehilite"><pre><span class="kd">public</span> <span class="nf">MyComponent</span><span class="o">(</span><span class="n">BundleContext</span> <span class="n">context</span><span class="o">)</span> <span class="o">{</span>
     <span class="c1">// context is the bundle context</span>
@@ -195,7 +206,7 @@ The API of the bundle context is availab
 
 
 <p>With such way, the bundle context of the bundle declaring the component is injected. Notice that such injection can be mixed with other constructor injection such as <code>@Requires</code> for service dependencies and <code>@Property</code> to configuration property.</p>
-<h2 id="using-context-version-1112">Using <code>@Context</code> (version 1.11.2+)</h2>
+<h2 id="using-context-version-1112">Using <code>@Context</code> (version 1.11.2+)<a class="headerlink" href="#using-context-version-1112" title="Permanent link">&para;</a></h2>
 <p>The second way to retrieve the <code>Bundle Context</code> uses a <em>bundle context handler</em> responsible for injecting the bundle context. This handler let you inject the bundle context in a field, in a setter method or as constructor parameter:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="kd">public</span> <span class="n">MyComponent</span> <span class="o">{</span>
@@ -247,7 +258,7 @@ The API of the bundle context is availab
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1575940 by clement on Mon, 10 Mar 2014 13:42:23 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="ipojo-jmx-handler">iPOJO JMX Handler</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="ipojo-jmx-handler">iPOJO JMX Handler<a class="headerlink" href="#ipojo-jmx-handler" title="Permanent link">&para;</a></h1>
 <p><em>This handler provides JMX management of component instance. It could be useful to manage instance remotely. As the handler exposes MBeans, you must have a MBean server running on your platform (as the platform MBean server or the MOSGi MBean Server).</em></p>
 <div class="toc">
 <ul>
@@ -195,18 +206,18 @@
 </li>
 </ul>
 </div>
-<h2 id="features">Features</h2>
+<h2 id="features">Features<a class="headerlink" href="#features" title="Permanent link">&para;</a></h2>
 <p>The handler allows to:</p>
 <ul>
 <li>Expose attributes accessible via JMX (with right management).</li>
 <li>Expose methods to be called through JMX.</li>
 <li>Get notifications when attributes are modified .</li>
 </ul>
-<h2 id="prerequisites">Prerequisites</h2>
+<h2 id="prerequisites">Prerequisites<a class="headerlink" href="#prerequisites" title="Permanent link">&para;</a></h2>
 <p>To be functional this handler must register on an MBean Server,thus you obviously need it. Several servers are currently supported : the standard platform MBean server (included in the Java Virtual Machine since version 5), MOSGi (Apache Felix sub-project), ...</p>
-<h2 id="download">Download</h2>
+<h2 id="download">Download<a class="headerlink" href="#download" title="Permanent link">&para;</a></h2>
 <p>The JMX handler is available in the Felix trunk in the iPOJO project. See the <a href="/documentation/subprojects/apache-felix-ipojo/download.html">Download</a> page to download and compile these sources.</p>
-<h2 id="how-to-use-it">How to use it</h2>
+<h2 id="how-to-use-it">How to use it<a class="headerlink" href="#how-to-use-it" title="Permanent link">&para;</a></h2>
 <p>The handler needs to be added in the metadata.xml, you just add a namespace (e.g., jmx) :</p>
 <div class="codehilite"><pre><span class="nt">&lt;ipojo</span> <span class="na">xmlns:jmx=</span><span class="s">&quot;org.apache.felix.ipojo.handlers.jmx&quot;</span><span class="nt">&gt;</span>
     ...
@@ -229,9 +240,9 @@ tag.</p>
 <p>Be careful that the argument and return type of methods must be serializable. In case of several methods have the same name, each of them will be exposed.</p>
 </div>
 
-<h2 id="jmx-handler-options">JMX Handler options</h2>
+<h2 id="jmx-handler-options">JMX Handler options<a class="headerlink" href="#jmx-handler-options" title="Permanent link">&para;</a></h2>
 <p>Here you can find all configuration options of the JMX handler. There are two kinds of manageable elements : properties and methods. First is described the global configuration of the handler. Then elements can be configured, using several attributes, as described below.</p>
-<h2 id="global-handler-attributes">Global handler attributes</h2>
+<h2 id="global-handler-attributes">Global handler attributes<a class="headerlink" href="#global-handler-attributes" title="Permanent link">&para;</a></h2>
 <table class="table table-bordered">
 <thead>
     <tr>
@@ -273,7 +284,7 @@ tag.</p>
   </tbody>
 </table>
 
-<h2 id="properties-attributes">Properties attributes</h2>
+<h2 id="properties-attributes">Properties attributes<a class="headerlink" href="#properties-attributes" title="Permanent link">&para;</a></h2>
 <table class="table table-bordered">
 <thead>
     <tr>
@@ -314,7 +325,7 @@ tag.</p>
   </tbody>
 </table>
 
-<h2 id="methods-attributes">Methods attributes</h2>
+<h2 id="methods-attributes">Methods attributes<a class="headerlink" href="#methods-attributes" title="Permanent link">&para;</a></h2>
 <table class="table table-bordered">
 <thead>
     <tr>
@@ -338,9 +349,9 @@ tag.</p>
   </tbody>
 </table>
 
-<h2 id="examples">Examples</h2>
+<h2 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">&para;</a></h2>
 <p>In this part, we will give you a complete example of a component managed with JMX, using the JConsole provided by the SUN JDK.</p>
-<h3 id="exposing-attributes">Exposing Attributes</h3>
+<h3 id="exposing-attributes">Exposing Attributes<a class="headerlink" href="#exposing-attributes" title="Permanent link">&para;</a></h3>
 <p>In first time we create a simple component named MyComponent. We have add two fields named m<em>level (int) and m</em>message (String).</p>
 <div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">MyComponent</span> <span class="o">...</span> <span class="o">{</span>
     <span class="c1">// Exposed attributes</span>
@@ -377,7 +388,7 @@ tag in the metadata :</p>
 
 <p>Now, we could get and write the properties in the JConsole :</p>
 <p><img src="JMXHandler_1.png"></p>
-<h3 id="exposing-methods">Exposing Methods</h3>
+<h3 id="exposing-methods">Exposing Methods<a class="headerlink" href="#exposing-methods" title="Permanent link">&para;</a></h3>
 <p>We could now add methods in the initial class :</p>
 <div class="codehilite"><pre><span class="cm">/**</span>
 <span class="cm">Do something good</span>
@@ -415,7 +426,7 @@ tag in the metadata :</p>
 
 <p>Now the three methods are exposed in the operations tab of the JConsole. We can invoked these methods :</p>
 <p><img src="JMXHandler_2.png"></p>
-<h3 id="attribute-notifications">Attribute Notifications:</h3>
+<h3 id="attribute-notifications">Attribute Notifications:<a class="headerlink" href="#attribute-notifications" title="Permanent link">&para;</a></h3>
 <p>You could subscribe to attribute notification by adding the notification attribute in property tag. In our example if we want to be notified when m_level is modified, we change the property line in the metatada like this:</p>
 <div class="codehilite"><pre><span class="nt">&lt;jmx:property</span> <span class="na">field=</span><span class="s">&quot;m_level&quot;</span>
       <span class="na">name=</span><span class="s">&quot;The level&quot;</span>
@@ -426,7 +437,7 @@ tag in the metadata :</p>
 
 <p>So now if we change the string through JConsole (or in the VisualVM) or if the POJO is modified in other way, a notification will be sent to every listener. For example, we subscribe in the notification tab, and we get notification when the message changes :</p>
 <p><img src="JMXHandler_3.png"></p>
-<h2 id="configuring-the-handler-with-annotations">Configuring the handler with annotations</h2>
+<h2 id="configuring-the-handler-with-annotations">Configuring the handler with annotations<a class="headerlink" href="#configuring-the-handler-with-annotations" title="Permanent link">&para;</a></h2>
 <p>It is possible to configure the handler with simple annotations available with iPOJO annotations. Here is an example of usage:</p>
 <div class="codehilite"><pre><span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.annotations.Component</span><span class="o">;</span>
 <span class="kn">import</span> <span class="nn">org.apache.felix.ipojo.handlers.jmx.Config</span><span class="o">;</span>
@@ -487,7 +498,7 @@ tag in the metadata :</p>
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1498147 by clement on Sun, 30 Jun 2013 16:29:38 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="lifecycle-callbacks">Lifecycle callbacks</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="lifecycle-callbacks">Lifecycle callbacks<a class="headerlink" href="#lifecycle-callbacks" title="Permanent link">&para;</a></h1>
 <p><em>It is often necessary to create a POJO object as soon the instance becomes valid (i.e. required services are available). It is also often needed to be able to stop it nicely. This pages presents the iPOJO capabilities to achieve such actions. iPOJO allows you to invoke methods (callbacks) on the POJO object when instance's state changed. For example, it allows invoking a <code>start</code> method when the instance becomes valid and a <code>stop</code> method when the instance becomes invalid. It allows the creation of <code>immediate</code> component. This page presents how to use this handler.</em></p>
 <div class="toc">
 <ul>
@@ -187,14 +198,14 @@
 </li>
 </ul>
 </div>
-<h2 id="instance-lifecycle">Instance Lifecycle</h2>
+<h2 id="instance-lifecycle">Instance Lifecycle<a class="headerlink" href="#instance-lifecycle" title="Permanent link">&para;</a></h2>
 <p>iPOJO instances have a very simple lifecycle. This lifecycle contains two states: <code>INVALID</code> and <code>VALID</code>. Once an instance is created, this instance can only be valid if all its plugged handlers are valid. In the most basic case it means all required services are available. For example, an instance requiring a service (and so using the dependency handler) cannot be valid if the required service is unavailable. </p>
 <p>An instance starts and stops in the invalid state.</p>
 <p><img src="lifecycle.png" width="25%"></p>
-<h2 id="lifecycle-callback">Lifecycle callback</h2>
+<h2 id="lifecycle-callback">Lifecycle callback<a class="headerlink" href="#lifecycle-callback" title="Permanent link">&para;</a></h2>
 <p>This handler supports two kinds of callback. The INVALID=&gt;VALID callback are invoked when the instance becomes valid (at starting or when an event allows the instance to become valid). The VALID=&gt;INVALID callback are invoked when the instance becomes invalid (at stopping or when an event invalids the instance).</p>
 <p><img src="callback.png" width="10%"></p>
-<h2 id="an-example">An example</h2>
+<h2 id="an-example">An example<a class="headerlink" href="#an-example" title="Permanent link">&para;</a></h2>
 <p>Let's take an example. The following class requires a FooService and has two lifecycle callbacks: start and stop.</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Instantiate</span>
@@ -231,7 +242,7 @@
 
 <p>When an instance of this component type is created, the start method is called as soon as the <code>Foo</code> Service (service requirement) becomes available. If the <code>Foo</code> Service is no more available or when the instance is stopped, the stop method is called.</p>
 <p>The invoked methods have no argument, but could be private, protected or public. Public methods can be in parent classes too. Moreover, the <code>INVALID=&gt;VALID</code> (validate) method can use service dependencies (the instance becomes valid means that all required services are available); however, in the stop method (invalidate) it is possible that one of these dependency can be <code>null</code>. Indeed, the departure of a service can be the cause of the instance invalidation.</p>
-<h2 id="managing-threads">Managing threads</h2>
+<h2 id="managing-threads">Managing threads<a class="headerlink" href="#managing-threads" title="Permanent link">&para;</a></h2>
 <p>One usage of lifecycle callback is when the instance needs to create threads. Indeed, the thread can be created in the validate callback, and stopped in the invalidate method. The next class shows an example of a class handling a thread by using lifecycle callbacks.</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Instantiate</span>
@@ -271,7 +282,7 @@
 </pre></div>
 
 
-<h2 id="invalidate-callbacks-and-services">Invalidate callbacks and services</h2>
+<h2 id="invalidate-callbacks-and-services">Invalidate callbacks and services<a class="headerlink" href="#invalidate-callbacks-and-services" title="Permanent link">&para;</a></h2>
 <p>The invalidate callback has to be developed defensively. Indeed, inside this callback, it might be possible that a service is no more there (the departure of this service has thrown the instance invalidation, which calls the callback). So, you must check that the service is not <code>null</code> before using it:</p>
 <div class="codehilite"><pre><span class="nd">@Invalidate</span>
 <span class="kd">public</span> <span class="kt">void</span> <span class="nf">stop</span><span class="o">()</span> <span class="o">{</span>
@@ -284,7 +295,7 @@
 
 
 <p>Thanks to the iPOJO synchronization model, you can be sure that if the service is available, it will be there until the end of the method.</p>
-<h2 id="immediate-component">Immediate component</h2>
+<h2 id="immediate-component">Immediate component<a class="headerlink" href="#immediate-component" title="Permanent link">&para;</a></h2>
 <p>An instance of an <code>immediate</code> component type is instantiated as soon it becomes valid. It means that, when the instance becomes valid, the constructor of the implementation class is called. This can replace the validate callback. However, it stills a difference between the immediate and the validate callback. The constructor is call only once time. The validate callback is re-called each time the instance becomes valid. Components that do not provide services are automatically set as immediate.</p>
 <p><img src="constructor.png"></p>
 <p>To set a component as immediate you must add the <code>immediate</code> attribute to <code>component</code>:</p>
@@ -297,7 +308,7 @@
 
 
 <p>However as there is no 'destructor' in Java, the invalidate callback is necessary if some actions are needed when stopping.</p>
-<h2 id="callback-on-several-objects">Callback on several objects</h2>
+<h2 id="callback-on-several-objects">Callback on several objects<a class="headerlink" href="#callback-on-several-objects" title="Permanent link">&para;</a></h2>
 <p>If you instance has created several objects (called the implementation class constructor several times), the callback is called on each object in the creation order.</p>
         </div>
     </div>
@@ -313,7 +324,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1467884 by clement on Mon, 15 Apr 2013 07:43:52 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>

Modified: websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html Tue Sep  1 06:05:17 2015
@@ -171,7 +171,18 @@
 
     <div class="container">
         <div class="content">
-            <h1 id="providing-osgi-services">Providing OSGi services</h1>
+            <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="providing-osgi-services">Providing OSGi services<a class="headerlink" href="#providing-osgi-services" title="Permanent link">&para;</a></h1>
 <p><em>This pages explains how to publish OSGi services with iPOJO. It presents:</em></p>
 <ul>
 <li><em>service publication</em></li>
@@ -201,7 +212,7 @@
 </li>
 </ul>
 </div>
-<h2 id="a-simple-example">A simple example</h2>
+<h2 id="a-simple-example">A simple example<a class="headerlink" href="#a-simple-example" title="Permanent link">&para;</a></h2>
 <p>The following code snippet shows a simple class implementing the <code>FooService</code> interface:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Provides</span>
@@ -226,7 +237,7 @@
 
 <p><img src="ps-foo.png"></p>
 <p>The <code>&lt;provides/&gt;</code> or <code>@Provides</code> suffice to declare that each instance of this type will provide the FooService (for more info about instances see '<a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.html">How to use iPOJO factories</a>`). The provided specifications can be discovered by analyzing the implementation class. By default, all implemented interface are published in the same service registration. iPOJO looks down the entire inheritance tree.</p>
-<h2 id="service-publication">Service Publication</h2>
+<h2 id="service-publication">Service Publication<a class="headerlink" href="#service-publication" title="Permanent link">&para;</a></h2>
 <p>The provided service handler manages service publication. For each declared <code>&lt;provides/&gt;</code>, the handler registers a service. Since the <code>@Provides</code> annotation can be used only once, only one service is registered that provides all interfaces. The service is published as long as the instance is valid. If the instance becomes invalid, the service is removed from the service registry.</p>
 <p>By default, it publishes all interfaces implemented by the implementation class of the component class. It collects all super-interfaces (interfaces implemented by implemented interfaces and by the super class). However, it is possible to explicitly declare which service specifications are published with the <code>specifications</code> attribute, such as:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
@@ -247,7 +258,7 @@
 <p>If the implementation class does not implement any interface, you cannot provide a service. In this case, the handler throws an error.</p>
 </div>
 
-<h2 id="service-properties">Service Properties</h2>
+<h2 id="service-properties">Service Properties<a class="headerlink" href="#service-properties" title="Permanent link">&para;</a></h2>
 <p>You can also attach properties to a service registration. Service properties are attached to published service and allow consumer filtering/selecting providers. A property can be attached to a field (contained in the component implementation class), and so can be handle dynamically.</p>
 <p>Let's take a new example very closed of the last one:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
@@ -334,8 +345,8 @@
 <li><code>(name=myname, password=****)</code> is a valid configuration</li>
 <li><code>(password=****)</code> is an invalid configuration that will be rejected by iPOJO</li>
 </ul>
-<h2 id="advanced-features">Advanced features</h2>
-<h3 id="service-serving-object-creation">Service Serving &amp; Object Creation</h3>
+<h2 id="advanced-features">Advanced features<a class="headerlink" href="#advanced-features" title="Permanent link">&para;</a></h2>
+<h3 id="service-serving-object-creation">Service Serving &amp; Object Creation<a class="headerlink" href="#service-serving-object-creation" title="Permanent link">&para;</a></h3>
 <p>When a consumer requires the published service, the handler sends an object (from the component class) of the implementation class. By default, it is always the same POJO object. If no objects already exists, an instance is created.</p>
 <p>However, the handler supports the OSGi <em>Service Factory</em>. In this case, for each requester bundle, the handler sends a new object. To activate this policy, add the <code>strategy</code> attribute in the <code>provides</code> element:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
@@ -362,7 +373,7 @@
 </pre></div>
 
 
-<h3 id="providing-several-services-xml-only">Providing Several Services (XML only)</h3>
+<h3 id="providing-several-services-xml-only">Providing Several Services (XML only)<a class="headerlink" href="#providing-several-services-xml-only" title="Permanent link">&para;</a></h3>
 <p>In XML, you can declare several <code>provides</code> inside the same component. All those provided services will be managed individually, so will be published using several publication (i.e. <code>org.osgi.frameowrk.ServiceRegistration</code>). This case is useful when service properties are different for the different services.</p>
 <div class="codehilite"><pre><span class="nt">&lt;component</span> <span class="na">classname=</span><span class="s">&quot;...FooProviderType1&quot;</span><span class="nt">&gt;</span>
                 <span class="nt">&lt;provides</span> <span class="na">specifications=</span><span class="s">&quot;...Foo&quot;</span><span class="nt">/&gt;</span>
@@ -374,7 +385,7 @@
 
 
 <p><img src="ps-foobar2.png"></p>
-<h3 id="service-property-propagation">Service Property Propagation</h3>
+<h3 id="service-property-propagation">Service Property Propagation<a class="headerlink" href="#service-property-propagation" title="Permanent link">&para;</a></h3>
 <p>The configuration handler has the possibility to propagate received properties to service publication. So, when the propagation is activated (on the <code>properties</code> element or on the <code>@Component</code> annotation), all properties received by the configuration handler will be propagated to all published services. If some properties are mapped on methods, these methods are invoked with the new value in argument.</p>
 <p><img src="ps-propagation.png"></p>
 <p>If an instance configuration contains properties starting with <code>service.</code>, they are automatically propagated. In the following example, the <code>service.pid</code> is automatically propagated.</p>
@@ -384,7 +395,7 @@
 </pre></div>
 
 
-<h3 id="instance-reconfiguration">Instance reconfiguration</h3>
+<h3 id="instance-reconfiguration">Instance reconfiguration<a class="headerlink" href="#instance-reconfiguration" title="Permanent link">&para;</a></h3>
 <p>iPOJO supports instance reconfiguration. When an instance is dynamically reconfigured and if the instance published service properties, the values are updated with the new configuration. For example, let's take the following component.</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Instantiate</span>
@@ -401,7 +412,7 @@
 
 
 <p>The previous code also declares an instance (created without any configuration). This instance registers <code>MyService</code> with the service property <code>prop=initial</code>. If this instance is reconfigured using a configuration like: <code>{prop="my value"}</code>, the published properties will be updated with the new value, so <code>prop=my value</code>.</p>
-<h3 id="publishing-an-abstract-or-concrete-class-as-a-service">Publishing an abstract or concrete class as a Service</h3>
+<h3 id="publishing-an-abstract-or-concrete-class-as-a-service">Publishing an abstract or concrete class as a Service<a class="headerlink" href="#publishing-an-abstract-or-concrete-class-as-a-service" title="Permanent link">&para;</a></h3>
 <p>It is also possible to expose an abstract or concrete class as a service. To to this, just specify the published class in the <code>specifications</code> attribute:</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Provides</span><span class="o">(</span><span class="n">specifications</span><span class="o">=</span><span class="n">MyComponent</span><span class="o">.</span><span class="na">class</span><span class="o">)</span>
@@ -422,7 +433,7 @@
 
 
 <p>As illustrated with the example using annotation, the component can also publish itself as a service. However, such practice is not recommended.</p>
-<h3 id="controlling-the-service-exposition-from-the-implementation-class">Controlling the service exposition from the implementation class</h3>
+<h3 id="controlling-the-service-exposition-from-the-implementation-class">Controlling the service exposition from the implementation class<a class="headerlink" href="#controlling-the-service-exposition-from-the-implementation-class" title="Permanent link">&para;</a></h3>
 <p>To control the exposition of the published service, you can use a <code>service controller</code>. A service controller is a boolean field of the component class. The injected boolean field allows the code to impact the service publication. Setting the field to <code>false</code> unregisters the service from the service registry. Setting it back to <code>true</code> re-publishes the service.</p>
 <div class="codehilite"><pre><span class="nd">@Component</span>
 <span class="nd">@Provides</span>
@@ -511,7 +522,7 @@
 </pre></div>
 
 
-<h3 id="being-notified-of-the-service-registration-and-unregistration">Being notified of the service registration and unregistration</h3>
+<h3 id="being-notified-of-the-service-registration-and-unregistration">Being notified of the service registration and unregistration<a class="headerlink" href="#being-notified-of-the-service-registration-and-unregistration" title="Permanent link">&para;</a></h3>
 <p>You can also be notified when the service is published and unpublished. This is done by specifying the two callbacks in the <code>&lt;provides/&gt;</code> element:</p>
 <div class="codehilite"><pre><span class="nt">&lt;component</span>
      <span class="na">classname=</span><span class="s">&quot;org.apache.felix.ipojo.test.scenarios.component.callbacks.CallbacksCheckService&quot;</span>
@@ -558,7 +569,7 @@
                 may be trademarks or registered trademarks of their respective owners.
                 </div>
                 <div class="timestamp span3 offset2">
-                Rev. 1475720 by clement on Thu, 25 Apr 2013 12:13:11 +0000
+                Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
                 </div>
             </div>
         </footer>