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 [5/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-gettingstarted/how-to-use-ipojo-annotations.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.html Tue Sep 1 06:05:17 2015
@@ -171,7 +171,18 @@
<div class="container">
<div class="content">
- <h1 id="how-to-use-ipojo-annotations">How to use iPOJO annotations</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="how-to-use-ipojo-annotations">How to use iPOJO annotations<a class="headerlink" href="#how-to-use-ipojo-annotations" title="Permanent link">¶</a></h1>
<p><em>You can use annotations to define your component types. This page presents supported annotations.</em></p>
<div class="toc">
<ul>
@@ -217,12 +228,12 @@
</li>
</ul>
</div>
-<h2 id="getting-ipojo-annotations">Getting iPOJO Annotations:</h2>
+<h2 id="getting-ipojo-annotations">Getting iPOJO Annotations:<a class="headerlink" href="#getting-ipojo-annotations" title="Permanent link">¶</a></h2>
<p>iPOJO Annotations are defines inside the <code>org.apache.felix.ipojo.annotations project</code>. You can download the Jar file of this project from the <a href="/documentation/subprojects/apache-felix-ipojo/download.html">download</a> page. Sources are available on the [Felix trunk|http://felix.apache.org/site/sourcecode.html].
Once added to your class path / build path / dependencies, you can use the annotations as normal annotations. These annotations are automatically processed by the iPOJO manipulator, and do <strong>not</strong> need to be deployed at runtime.</p>
-<h3 id="with-eclipse-or-any-other-ide">With Eclipse (or any other IDE)</h3>
+<h3 id="with-eclipse-or-any-other-ide">With Eclipse (or any other IDE)<a class="headerlink" href="#with-eclipse-or-any-other-ide" title="Permanent link">¶</a></h3>
<p>Add the org.apache.felix.ipojo.annotations jar file in your build path. Do not forget to use a Java compiler accepting annotations (1.5 or higher).</p>
-<h3 id="with-maven">With Maven</h3>
+<h3 id="with-maven">With Maven<a class="headerlink" href="#with-maven" title="Permanent link">¶</a></h3>
<p>Add the following dependency:</p>
<div class="codehilite"><pre><span class="nt"><dependency></span>
<span class="nt"><groupId></span>org.apache.felix<span class="nt"></groupId></span>
@@ -244,14 +255,14 @@ Once added to your class path / build pa
</pre></div>
-<h3 id="with-ant">With Ant</h3>
+<h3 id="with-ant">With Ant<a class="headerlink" href="#with-ant" title="Permanent link">¶</a></h3>
<p>Just add the org.apache.felix.ipojo.annotations jar file in your class path.</p>
-<h2 id="an-example-of-usage">An example of usage</h2>
+<h2 id="an-example-of-usage">An example of usage<a class="headerlink" href="#an-example-of-usage" title="Permanent link">¶</a></h2>
<p>To illustrate annotations usage, let taking the tutorial example. In this tutorial, there are two components:
<em> The first one provides the hello service
</em> The second one uses the provided hello service
You can download the archive containing the examples and a preconfigured version of Felix <a href="http://people.apache.org/~clement/ipojo/tutorials/annotations/annotation-tutorial.zip">here</a>.</p>
-<h3 id="hello-service-provider">Hello Service Provider</h3>
+<h3 id="hello-service-provider">Hello Service Provider<a class="headerlink" href="#hello-service-provider" title="Permanent link">¶</a></h3>
<p>The provider uses two annotations. The "component" annotation is mandatory and defines that the class defines a component type. Then the "provides" annotation just declare that the defined component type provides a service.</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">ipojo</span><span class="o">.</span><span class="na">example</span><span class="o">.</span><span class="na">hello</span><span class="o">.</span><span class="na">impl</span><span class="o">;</span>
@@ -273,7 +284,7 @@ You can download the archive containing
</pre></div>
-<h3 id="hello-service-consumer">Hello Service Consumer</h3>
+<h3 id="hello-service-consumer">Hello Service Consumer<a class="headerlink" href="#hello-service-consumer" title="Permanent link">¶</a></h3>
<p>The Hello Service Consumer use more annotations. First it used the component annotation. To defines its "immediate" behavior, it add the 'immediate' attribute.
Then, it uses the requires annotation to define a service dependency. Finally, it uses the validate and invalidate annotations to define lifecycle callbacks.</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">ipojo</span><span class="o">.</span><span class="na">example</span><span class="o">.</span><span class="na">hello</span><span class="o">.</span><span class="na">client</span><span class="o">;</span>
@@ -326,9 +337,9 @@ Then, it uses the requires annotation to
</pre></div>
-<h2 id="defined-annotations">Defined Annotations</h2>
+<h2 id="defined-annotations">Defined Annotations<a class="headerlink" href="#defined-annotations" title="Permanent link">¶</a></h2>
<p>This section lists defined annotations and how to use them.</p>
-<h3 id="component">@Component</h3>
+<h3 id="component">@Component<a class="headerlink" href="#component" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines a component type
<em>Target:</em> The component implementation class
<em>Attributes:</em></p>
@@ -341,7 +352,7 @@ Then, it uses the requires annotation to
<li>factoryMethod : set the factory-method. The specified method must be a static method and return a pojo object.(optional, default = iPOJO uses the 'regular' constructor). </li>
<li>publicFactory : set if the component type is public. (optional, default = true). </li>
</ul>
-<h3 id="provides">@Provides</h3>
+<h3 id="provides">@Provides<a class="headerlink" href="#provides" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines that the component type provide services
<em>Target:</em> The component implementation class
<em>Attributes:</em></p>
@@ -356,7 +367,7 @@ Then, it uses the requires annotation to
The <tt>SERVICE</tt> strategy refers to the OSGi service factory. So, one service object per asking bundle will be created.
</div>
-<h3 id="requires">@Requires</h3>
+<h3 id="requires">@Requires<a class="headerlink" href="#requires" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines a service dependency
<em>Target:</em> Field, Constructor Parameter
<em>Attributes:</em></p>
@@ -374,7 +385,7 @@ Then, it uses the requires annotation to
<li>proxy : enables / disables the proxy injection (enabled by default)</li>
<li>timeout : the timeout ins millisecond to wait before applying the <em>no service action</em></li>
</ul>
-<h3 id="serviceproperty">@ServiceProperty</h3>
+<h3 id="serviceproperty">@ServiceProperty<a class="headerlink" href="#serviceproperty" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines a service property
<em>Target:</em> Field
<em>Attributes:</em></p>
@@ -389,7 +400,7 @@ Then, it uses the requires annotation to
A mandatory property must receive a value either from the component type description (<tt>value</tt> attribute), or the instance configuration.
</div>
-<h3 id="servicecontroller">@ServiceController</h3>
+<h3 id="servicecontroller">@ServiceController<a class="headerlink" href="#servicecontroller" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Control the service exposition
<em>Target:</em> Field (Boolean)
<em>Attributes:</em></p>
@@ -397,7 +408,7 @@ A mandatory property must receive a valu
<li>value : the default value. If set to false, it disables the initial exposition</li>
<li>specification : set the target of the controller, must be an exposed service interface. By default, the controller targets all services.</li>
</ul>
-<h3 id="property">@Property</h3>
+<h3 id="property">@Property<a class="headerlink" href="#property" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines a property
<em>Target:</em> Field, Method, Constructor Parameter
<em>Attributes:</em></p>
@@ -412,10 +423,10 @@ A mandatory property must receive a valu
If another property with the same name is defined, the method or field or constructor argument is added to the existing property.
</div>
-<h3 id="updated">@Updated</h3>
+<h3 id="updated">@Updated<a class="headerlink" href="#updated" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines method called when a reconfiguration is completed.
<em>Target:</em> a method (receiving a dictionary in argument)</p>
-<h3 id="bind">@Bind</h3>
+<h3 id="bind">@Bind<a class="headerlink" href="#bind" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines a bind method
<em>Target:</em> Method
<em>Attributes:</em></p>
@@ -429,7 +440,7 @@ A mandatory property must receive a valu
<li>Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)</li>
<li>From : defines the specific provider to use</li>
</ul>
-<h3 id="unbind">@Unbind</h3>
+<h3 id="unbind">@Unbind<a class="headerlink" href="#unbind" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines an unbind method
<em>Target:</em> Method
<em>Attributes:</em></p>
@@ -443,7 +454,7 @@ A mandatory property must receive a valu
<li>Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)</li>
<li>From : defines the specific provider to use</li>
</ul>
-<h3 id="modified">@Modified</h3>
+<h3 id="modified">@Modified<a class="headerlink" href="#modified" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> Defines an <code>modified</code> method, called when a bound service is udpated.
<em>Target:</em> Method
<em>Attributes:</em></p>
@@ -457,26 +468,26 @@ A mandatory property must receive a valu
<li>Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)</li>
<li>From : defines the specific provider to use</li>
</ul>
-<h3 id="validate">@Validate</h3>
+<h3 id="validate">@Validate<a class="headerlink" href="#validate" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> defines a validate lifecycle callback
<em>Target:</em> method</p>
-<h3 id="invalidate">@Invalidate</h3>
+<h3 id="invalidate">@Invalidate<a class="headerlink" href="#invalidate" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> defines a validate lifecycle callback
<em>Target:</em> method</p>
-<h3 id="postregistration">@PostRegistration</h3>
+<h3 id="postregistration">@PostRegistration<a class="headerlink" href="#postregistration" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> defines a callback invoked after service registration. The callback must have the following signature : <code>public void name(ServiceReference ref)</code>
<em>Target:</em> method</p>
-<h3 id="postunregistration">@PostUnregistration</h3>
+<h3 id="postunregistration">@PostUnregistration<a class="headerlink" href="#postunregistration" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> defines a callback invoked after service unregistration. The callback must have the following signature : <code>public void name(ServiceReference ref)</code>
<em>Target:</em> method</p>
-<h3 id="instantiate">@Instantiate</h3>
+<h3 id="instantiate">@Instantiate<a class="headerlink" href="#instantiate" title="Permanent link">¶</a></h3>
<p><em>Goal:</em> declare a simple instance (this is equivalent to <code><instance component="..."></instance></code>
<em>Target:</em> class
<em>Attribute:</em></p>
<ul>
<li>name: the instance name (optional)</li>
</ul>
-<h3 id="temporal-dependencies-external-handler">Temporal Dependencies (external handler)</h3>
+<h3 id="temporal-dependencies-external-handler">Temporal Dependencies (external handler)<a class="headerlink" href="#temporal-dependencies-external-handler" title="Permanent link">¶</a></h3>
<p>The temporal dependency handler is an external handler. However, it can be used with an annotation defined in the iPOJO annotations jar file.
The annotation is <code>org.apache.felix.ipojo.handler.temporal.Requires</code> and targets a field.
<em>Attributes:</em></p>
@@ -487,7 +498,7 @@ The annotation is <code>org.apache.felix
<li>specification : the required service specification. This attribute is required for Collection field. (optional, default = annotated field type). </li>
<li>proxy : Inject a proxy instead of the real object. This allows passing this reference to collaborators. (Default = false) </li>
</ul>
-<h3 id="exposing-instances-as-a-jmx-mbean-external-handler">Exposing instances as a JMX MBean (external handler)</h3>
+<h3 id="exposing-instances-as-a-jmx-mbean-external-handler">Exposing instances as a JMX MBean (external handler)<a class="headerlink" href="#exposing-instances-as-a-jmx-mbean-external-handler" title="Permanent link">¶</a></h3>
<p>The JMX Handler allows exposing an instance as a JMX MBean. To configure the JMX handler directly from your code, three annotations are provided. They are in the <code>org.apache.felix.ipojo.handlers.jmx</code> package</p>
<p>The <code>@org.apache.felix.ipojo.handlers.jmx.Config</code> (<code>@Config</code> if the package it correctly imported) annotation is a type annotation (so placed on the <code>class</code> element. This annotation indicates that the instance will be exposed as an MBean. This annotation supports:</p>
<ul>
@@ -506,10 +517,10 @@ The annotation is <code>org.apache.felix
<ul>
<li>description: set the method description.</li>
</ul>
-<h2 id="advanced-topics-and-faq">Advanced topics and FAQ</h2>
-<h3 id="metadata-file-and-annotation-merge">Metadata file and annotation merge</h3>
+<h2 id="advanced-topics-and-faq">Advanced topics and FAQ<a class="headerlink" href="#advanced-topics-and-faq" title="Permanent link">¶</a></h2>
+<h3 id="metadata-file-and-annotation-merge">Metadata file and annotation merge<a class="headerlink" href="#metadata-file-and-annotation-merge" title="Permanent link">¶</a></h3>
<p>It is possible to defines component type both in the metadata file (in XML) and by using annotation. However, if a component type defined by using annotations has the same name than a type define in the XML file, the XML descriptor override the annotation defined type. However, a warning message is launched during the manipulation.</p>
-<h3 id="instance-creation">Instance creation</h3>
+<h3 id="instance-creation">Instance creation<a class="headerlink" href="#instance-creation" title="Permanent link">¶</a></h3>
<p>The @Instantiate annotation allows creating an instance, but this declaration is limited:</p>
<ul>
<li>it does not support configuration</li>
@@ -522,7 +533,7 @@ The annotation is <code>org.apache.felix
</pre></div>
-<h3 id="using-custom-annotations">Using Custom Annotations</h3>
+<h3 id="using-custom-annotations">Using Custom Annotations<a class="headerlink" href="#using-custom-annotations" title="Permanent link">¶</a></h3>
<p>External handlers can provides their own annotations. Using these annotations just requires to add them to your build path. To external handlers annotations, please refer to the external handler documentation.</p>
</div>
</div>
@@ -538,7 +549,7 @@ The annotation is <code>org.apache.felix
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1566569 by clement on Mon, 10 Feb 2014 10:30:20 +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-gettingstarted/ipojo-advanced-tutorial.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.html Tue Sep 1 06:05:17 2015
@@ -171,7 +171,18 @@
<div class="container">
<div class="content">
- <h1 id="the-ipojo-snack-bar">The iPOJO Snack Bar</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-ipojo-snack-bar">The iPOJO Snack Bar<a class="headerlink" href="#the-ipojo-snack-bar" title="Permanent link">¶</a></h1>
<p><em>This tutorial illustrates some advanced features of iPOJO</em></p>
<div class="toc">
<ul>
@@ -193,16 +204,16 @@
</li>
</ul>
</div>
-<h2 id="context">Context</h2>
+<h2 id="context">Context<a class="headerlink" href="#context" title="Permanent link">¶</a></h2>
<p>This tutorial is based on a very simple application; customers are using a vendor service to buy hot dog or pop corn according to the availability of appropriate providers. Both of the vendors implement (and provide) the vendor service. The hot dog vendor depends on two others services to get the ingredients (buns and wiener). To sell pop corn, the pop corn vendor requires having enough corn in stock.</p>
<p><img src="vendor.png"></p>
-<h2 id="preparing-the-tutorial">Preparing the tutorial</h2>
+<h2 id="preparing-the-tutorial">Preparing the tutorial<a class="headerlink" href="#preparing-the-tutorial" title="Permanent link">¶</a></h2>
<p>The tutorial archive is available <a href="http://people.apache.org/~clement/ipojo/tutorials/advanced/advanced.tutorial.zip">here</a>. This archive contains both the source code and a pre-configured version of Felix. First, unzip the archive. Then, launch <code>ant</code> to compile the bundles composing this tutorial. Once compiled, you can launch Felix and start the tutorial. To launch, Felix launch the following command from the <code>felix</code> directory:</p>
<div class="codehilite"><pre>java -jar bin/felix.jar
</pre></div>
-<h2 id="writing-a-component-providing-two-services">Writing a component providing two services</h2>
+<h2 id="writing-a-component-providing-two-services">Writing a component providing two services<a class="headerlink" href="#writing-a-component-providing-two-services" title="Permanent link">¶</a></h2>
<p>The sources of this project are inside the <em>vendor.buns-and-wieners</em> directory.
The hot dog vendor requires at the same time the bun service and the wiener service. In our application these services are provided by the same component. This component can be implemented as follows (src\org\apache\felix\ipojo\example\vendor\provider\BunWienerProvider.java):</p>
<div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">BunWienerProvider</span> <span class="kd">implements</span> <span class="n">BunService</span><span class="o">,</span> <span class="n">WienerService</span> <span class="o">{</span>
@@ -236,7 +247,7 @@ The hot dog vendor requires at the same
<p>iPOJO manages service publication and providing automatically at runtime. The <code><provides/></code> element means that the component provides services. If this element is not present, iPOJO will publish all implemented interfaces by the implementation class (and parent class too). In our case, it will publish the BunService and WienerService interfaces.</p>
<p>Finally, we create one instance of our component. The instance contains the component attribute describing the component type to use. We use the component type name to target the wanted component type. </p>
<p>At runtime, the bundle containing this component will create an instance which provides the BunService and the WienerService.</p>
-<h2 id="publishing-service-properties">Publishing service properties</h2>
+<h2 id="publishing-service-properties">Publishing service properties<a class="headerlink" href="#publishing-service-properties" title="Permanent link">¶</a></h2>
<p>The sources of this project are inside the <em>vendor.hotdog</em> directory.
The hot dog vendor only provides the Vendor service. To provide this service, it uses a bun service and a wiener service. The following code (contained in the <em>src/org/apache/felix/ipojo/example/vendor/hotdog/HotDogVendor.java</em> file) shows a very simple implementation of this component:</p>
<div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">HotDogVendor</span> <span class="kd">implements</span> <span class="n">Vendor</span> <span class="o">{</span>
@@ -300,7 +311,7 @@ The hot dog vendor only provides the Ven
<p>iPOJO then publishes the "product" property in the "vendor" service registration. This property has the "hotdog" value.</p>
-<h2 id="publishing-dynamic-properties">Publishing 'dynamic' properties</h2>
+<h2 id="publishing-dynamic-properties">Publishing 'dynamic' properties<a class="headerlink" href="#publishing-dynamic-properties" title="Permanent link">¶</a></h2>
<p>The bun service and the wiener service can also expose service properties. In our case, these service properties will describe the stock of ingredients. Each time the service is used, the property value is decreased.
To achieve this, we modify the current implementation to add a field representing the property:</p>
<div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">BunWienerProvider</span> <span class="kd">implements</span> <span class="n">BunService</span><span class="o">,</span> <span class="n">WienerService</span> <span class="o">{</span>
@@ -337,7 +348,7 @@ To achieve this, we modify the current i
<p>In the <code>provides</code> element, two properties are added. This property contains a <code>field</code> attribute aiming to attach the service property with a field of the implementation class. Then a default value is given. In the code, the property fields will obtain the initial value (10). Then each time the fields are modified, the service property is updated (as well as the OSGi⢠service registration). Notice that iPOJO support method injection for property too. In this case, a getter method is called to inject the property value.</p>
-<h2 id="configuring-instances">Configuring instances</h2>
+<h2 id="configuring-instances">Configuring instances<a class="headerlink" href="#configuring-instances" title="Permanent link">¶</a></h2>
<p>In the previous example, the properties were configured in the component type description. It is also possible to customize any property value in the instance declaration. This way, each instance can obtain different values.</p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
<span class="nt"><component</span>
@@ -358,7 +369,7 @@ To achieve this, we modify the current i
<p>The previous metadata shows how to push a configuration in instance declarations. The instance declaration contains two property elements containing the name of the value of the property. Instance configuration override component type initial value. Properties are optional by default ; that's means that they do not need to receive a value. In this case, default values are the same as the Java default fields values (boolean : false, int : 0, double : 0.0d, ...). You can specify that a property must receive a default value from either the component type description or the instance configuration by setting the <code>mandatory</code> attribute to <code>true</code>. </p>
-<h2 id="using-filter-in-service-requirements">Using filter in service requirements</h2>
+<h2 id="using-filter-in-service-requirements">Using filter in service requirements<a class="headerlink" href="#using-filter-in-service-requirements" title="Permanent link">¶</a></h2>
<p>Now that bun and wiener providers publish their remaining stock, the hot dog provider can look for a bun service and a wiener service with a non empty stock. To achieve this, we must describe an LDAP filter in the service requirement description. The following XML snipped shows this metadata:</p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
<span class="nt"><component</span>
@@ -383,7 +394,7 @@ To achieve this, we modify the current i
When an instance becomes invalid, all its provided services are withdrawn from the service registry. So, this instance is no more *accessible* from the service registry.
</div>
-<h2 id="immediate-component-instance">Immediate component instance</h2>
+<h2 id="immediate-component-instance">Immediate component instance<a class="headerlink" href="#immediate-component-instance" title="Permanent link">¶</a></h2>
<p>Now that we get the hot dog provider, we are going to implement customers. Customers are implemented in the <em>vendor.customer</em> project). A customer simply looks for a vendor service and buys a product:</p>
<div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">Customer</span> <span class="o">{</span>
@@ -421,7 +432,7 @@ When an instance becomes invalid, all it
There is a difference between immediate components and components with a <code>validate</code> lifecycle callback. Indeed, the callback is call at each time the instance becomes valid and calls the constructor only if no object already exists. On the other side, the immediate component's constructor is call only once.
</div>
-<h2 id="creating-instances-from-an-external-component-type">Creating instances from an external component type</h2>
+<h2 id="creating-instances-from-an-external-component-type">Creating instances from an external component type<a class="headerlink" href="#creating-instances-from-an-external-component-type" title="Permanent link">¶</a></h2>
<p>In the previous section we have declared a customer component type, which does not have the <code>public=false</code> attribute. This feature allows separate deployment from instance creation. Moreover, we didn't declare instances in the descriptor. </p>
<p>Another metadata file can be used to declare instances from the customer type, this descriptor being contained in another bundle. The following descriptor creates 10 customer instances (look at the <em>vendor.customer.creator\metadata.xml</em> file):</p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
@@ -460,7 +471,7 @@ There is a difference between immediate
<p>Once deployed, this bundle looks for the required factory. If it's not available the bundle waits for the factory. As soon as the required factory is available, all instances are created. When this bundle is stopped, all instances are destroyed. </p>
-<h2 id="deploying-the-application">Deploying the application</h2>
+<h2 id="deploying-the-application">Deploying the application<a class="headerlink" href="#deploying-the-application" title="Permanent link">¶</a></h2>
<p>Compile the bundles, by launching ant at the root of the tutorial. Then launch Felix is indicated above.
Once started, launch the following commands </p>
<div class="codehilite"><pre>start file:../vendor.services/output/vendor.services.jar
@@ -484,7 +495,7 @@ Customer customer-8 bought Hotdog from F
<p>Only 8 customers can buy a hot-dog, as the stock of wieners and buns can't supply more hot-dog. The remainder of this tutorial will try to solve the problem of these two hungry customers.</p>
-<h2 id="using-the-lifecycle-controller">Using the lifecycle controller</h2>
+<h2 id="using-the-lifecycle-controller">Using the lifecycle controller<a class="headerlink" href="#using-the-lifecycle-controller" title="Permanent link">¶</a></h2>
<p>Sometimes you want to invalidate your instance in the code (for example: to unregister a service). That's possible with the lifecycle controller handler.
Let's take the popcorn vendor with a corn stock from the <em>vendor.popcorn</em> project. Each time it sells some popcorn, its stock is decreased. When the stock reaches 0, it cannot sell popcorns any more (so the vendor service needs to be withdrawn).</p>
<p>The following implementation (<em>src\org\apache\felix\ipojo\example\vendor\popcorn\PopCornVendor.java</em>) uses a field to control the lifecycle.</p>
@@ -555,7 +566,7 @@ Customer customer-3 bought popcorn from
<p>To recreate new customers, just update the customer.creator bundle (bundle 10). So, now we have 7 customers hungry! There is neither popcorn nor hotdog!</p>
-<h2 id="reconfiguring-an-instance">Reconfiguring an instance</h2>
+<h2 id="reconfiguring-an-instance">Reconfiguring an instance<a class="headerlink" href="#reconfiguring-an-instance" title="Permanent link">¶</a></h2>
<p>OSGi specified the Configuration Admin mechanism aiming to handler service and bundle configuration. This section will describe how you can use the Configuration Admin and iPOJO to add corn inside our popcorn vendor.
First, we will change the pop corn vendor to add a method reinjecting the new stock:</p>
<div class="codehilite"><pre><span class="cm">/**</span>
@@ -647,7 +658,7 @@ Customer customer-4 bought popcorn from
<p>That's it!</p>
-<h2 id="conclusion">Conclusion</h2>
+<h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">¶</a></h2>
<p>This small tutorial has presented some of of the iPOJO features. Subscribe to the Felix users mailing list by sending a message to <a href="mailto:users-subscribe@felix.apache.org">users-subscribe@felix.apache.org</a>; after subscribing, email questions or feedback to <a href="mailto:users@felix.apache.org">users@felix.apache.org</a>.</p>
</div>
</div>
@@ -663,7 +674,7 @@ Customer customer-4 bought popcorn from
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1443557 by clement on Thu, 7 Feb 2013 15:34:03 +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-gettingstarted/ipojo-composition-tutorial.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.html Tue Sep 1 06:05:17 2015
@@ -171,7 +171,18 @@
<div class="container">
<div class="content">
- <h1 id="ipojo-composition-tutorial">iPOJO Composition Tutorial</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-composition-tutorial">iPOJO Composition Tutorial<a class="headerlink" href="#ipojo-composition-tutorial" title="Permanent link">¶</a></h1>
<p><em>This page describes how works the composition mechanisms provided by iPOJO and how to use it. this feature allows you to design applications that will natively support the dynamism and the evolution.</em></p>
<div class="toc">
<ul>
@@ -198,7 +209,7 @@
</li>
</ul>
</div>
-<h2 id="why-providing-a-composition-layer">Why providing a composition layer?</h2>
+<h2 id="why-providing-a-composition-layer">Why providing a composition layer?<a class="headerlink" href="#why-providing-a-composition-layer" title="Permanent link">¶</a></h2>
<p>iPOJO aims to simplify the creation of OSGi (dynamic) applications. Creating such as applications is basically a two steps process:</p>
<ul>
<li>Developing services and components</li>
@@ -210,18 +221,18 @@
<li>Assert service isolation inside a composition</li>
<li>Hide/Abstract implementations </li>
</ul>
-<h3 id="what-about-privacy">What about privacy?</h3>
+<h3 id="what-about-privacy">What about privacy?<a class="headerlink" href="#what-about-privacy" title="Permanent link">¶</a></h3>
<p>Service or component composition has a stringent requirement. How to isolate components and services of an application to avoid side effects as an unexpected access to a used service ...iPOJO composites just provide an isolation mechanism. Services provided inside a composite ARE NOT published globally (inside the OSGi service registry). So, only the component instances living in the same composite can access to those services.
However, it is also possible to import a service from the parent/global service registry, as well as to export a service to the parent (i.e. superior) composite.</p>
-<h2 id="the-different-types-of-composition-in-the-osgi-world">The different types of composition in the OSGi world</h2>
+<h2 id="the-different-types-of-composition-in-the-osgi-world">The different types of composition in the OSGi world<a class="headerlink" href="#the-different-types-of-composition-in-the-osgi-world" title="Permanent link">¶</a></h2>
<p>Basically there is two types of composition in OSGi:</p>
<ul>
<li>The intra-bundle composition</li>
<li>The service-based composition</li>
</ul>
-<h3 id="intra-bundle-composition">Intra-bundle composition</h3>
+<h3 id="intra-bundle-composition">Intra-bundle composition<a class="headerlink" href="#intra-bundle-composition" title="Permanent link">¶</a></h3>
<p>The intra-bundle composition is the policy followed by Spring-DM. Each bundle contains components. These components can require and provide services from the global (OSGi) registry. Moreover, these components can collaborate together inside the bundle without providing/requiring services. So the isolation scope of intra-bundle composition is the <em>bundle</em>. This type of composition allows providing coarse-grain services provided by the collaboration of several components. However, it is not possible to update one of those components, as the update unity is the bundle.</p>
-<h3 id="service-based-composition">Service-based composition</h3>
+<h3 id="service-based-composition">Service-based composition<a class="headerlink" href="#service-based-composition" title="Permanent link">¶</a></h3>
<p>There are two types of service composition. The behavioral service composition is like <a href="http://www.ibm.com/developerworks/library/specification/ws-bpel/">BPEL</a> for the web services. An orchestrator supervises the execution and the collaboration of services like:</p>
<ol>
<li>Call service A</li>
@@ -234,13 +245,13 @@ However, it is also possible to import a
<li>Allows the evolution of used services and components at runtime</li>
</ul>
<p>This is also the way followed by <a href="http://www.ibm.com/developerworks/library/specification/ws-sca/">SCA</a>. However, SCA does not specify how the dynamism should be handled.</p>
-<h2 id="the-ipojo-composition-theory-for-the-dummies">The iPOJO composition theory for the dummies</h2>
+<h2 id="the-ipojo-composition-theory-for-the-dummies">The iPOJO composition theory for the dummies<a class="headerlink" href="#the-ipojo-composition-theory-for-the-dummies" title="Permanent link">¶</a></h2>
<p>The distinction between component types and instances
When you declare a <code><component></code> (or a <code><composite></code>) in your metadata, you're declaring a component type. Then you declare instances from these component types. This mechanism is critic for the iPOJO composition. Indeed, inside a composite, you're able to create instances from any (public) component types (Refer to the <a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.html">Factory</a> web page for further details).
On the top of this mechanism, we can define the concept of service implementation. A service implementation is just a component type where the instances provide a service. For example, if the instance from a component type provides the service S, the component type is a service implementation of S, and so can be used to create a provider of S. </p>
-<h2 id="the-service-context-concept">The service context concept</h2>
+<h2 id="the-service-context-concept">The service context concept<a class="headerlink" href="#the-service-context-concept" title="Permanent link">¶</a></h2>
<p>The service context is the concept allowing service isolation. OSGi bundle context allows accessing both to bundle-based functionality (like <code>loadClass</code>) and to the service registry. However, OSGi defines only one service registry, accessible by any bundles. iPOJO splits these two interaction types. Instances receive an iPOJO Bundle Context delegating bundle-related methods to the "regular" bundle context, and service-related methods to a service context. This service context can access to the OSGi service registry or to a new one. Each composition instances have a service registry. Instances creates inside the composition used this service registry through received the iPOJO Bundle Context. </p>
-<h2 id="downloads">Downloads</h2>
+<h2 id="downloads">Downloads<a class="headerlink" href="#downloads" title="Permanent link">¶</a></h2>
<p>Download the <a href="http://people.apache.org/~clement/ipojo/tutorials/composite/composite-tutorial.zip">archive</a>. This archive contains:</p>
<ul>
<li>The different applications and component types implemented in this tutorial</li>
@@ -248,7 +259,7 @@ On the top of this mechanism, we can def
<li>Deployment scripts</li>
</ul>
<p>Launch <code>ant</code> from the base directory of the unzipped archive to create every bundles. Then, you can test the different examples by copying and pasting commands from the <code>script.txt</code> file (in the felix folder) in the Felix shell.</p>
-<h2 id="lets-start-with-a-first-composition">Let's start with a first composition</h2>
+<h2 id="lets-start-with-a-first-composition">Let's start with a first composition<a class="headerlink" href="#lets-start-with-a-first-composition" title="Permanent link">¶</a></h2>
<p>In the <a href="/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.html">iPOJO in 10 minutes</a> tutorial, we created an application checking a sentence against dictionaries. We'll reuse this simple application in this tutorial.
So first, we need to implements several component types:</p>
<ul>
@@ -375,7 +386,7 @@ org.apache.felix.ipojo.Factory, org.osgi
<p>Then, the application also supports component type update. However the component type name must not change. We will see later how we can avoid this issue by abstracting implementations.</p>
-<h2 id="importing-a-service-inside-a-composite">Importing a service inside a composite</h2>
+<h2 id="importing-a-service-inside-a-composite">Importing a service inside a composite<a class="headerlink" href="#importing-a-service-inside-a-composite" title="Permanent link">¶</a></h2>
<p>Let's imagine a second version of the checker service implementation (spell.checker-v2). This implementation removes the trace when wrong words are detected. Indeed, this implementation uses a log service to store such kind of errors. </p>
<p>If we use this implementation, we need to make a log service available inside the composite. Else, the checker will not be valid. To achieve this, use the following composite:</p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
@@ -434,7 +445,7 @@ To tackle implementation service depende
</p>
</div>
-<h2 id="abstracting-implementation-composing-services">Abstracting implementation... Composing services</h2>
+<h2 id="abstracting-implementation-composing-services">Abstracting implementation... Composing services<a class="headerlink" href="#abstracting-implementation-composing-services" title="Permanent link">¶</a></h2>
<p>We saw in the first composition that we depend on specific component types. This can be avoided by specifying the composition in term of services instead of component types. So, every available service implementation can be used. Moreover, if the used one disappears, another one can be immediately used to replace the missing service. Let's illustrate this.</p>
<p>In the first composition, we create an instance of the English dictionary service implementation. We can remove this coupling to this specific implementation. To do this, we will target any implementation of the dictionary service regardless the language. </p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
@@ -500,7 +511,7 @@ Now deploy another implementation of the
<p>Write <code>welcome</code> in the GUI, and check. The word is misspelled! Try to write <code>bienvenue</code> and check. The word is correctly spelled. This means that the composite has substitutes the previous English dictionary by the French one. This one will be use until it disappears. If you stop the bundle containing this implementation, the composite becomes invalid.</p>
-<h2 id="publishing-services">Publishing services</h2>
+<h2 id="publishing-services">Publishing services<a class="headerlink" href="#publishing-services" title="Permanent link">¶</a></h2>
<p>A composition can also provide services. iPOJO composites support two methods to provide services :</p>
<ul>
<li>The service export: re-export a service from the composite to the parent context</li>
@@ -592,7 +603,7 @@ service.id <span class="o">=</span> 41
</pre></div>
-<h2 id="hierarchical-composites">Hierarchical composites</h2>
+<h2 id="hierarchical-composites">Hierarchical composites<a class="headerlink" href="#hierarchical-composites" title="Permanent link">¶</a></h2>
<p>A composition can also contain others compositions. Let's imagine a variation of the latest application. In this case, we define a composite containing the GUI and the previous composite.</p>
<div class="codehilite"><pre><span class="nt"><ipojo></span>
@@ -643,7 +654,7 @@ start file:../example5/output/compositio
<p>You can check that the composite does no more publish the spell checker service in the OSGi service registry.</p>
-<h2 id="conclusion">Conclusion</h2>
+<h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">¶</a></h2>
<p>This page has presented how to use iPOJO composition model. Several topics were not addressed and will be added shortly:</p>
<ul>
<li>Dynamic service implementation</li>
@@ -666,7 +677,7 @@ start file:../example5/output/compositio
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1443557 by clement on Thu, 7 Feb 2013 15:34:03 +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-gettingstarted/ipojo-hello-word-maven-based-tutorial.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.html Tue Sep 1 06:05:17 2015
@@ -171,22 +171,33 @@
<div class="container">
<div class="content">
- <h1 id="ipojo-hello-world">iPOJO Hello World</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-hello-world">iPOJO Hello World<a class="headerlink" href="#ipojo-hello-world" title="Permanent link">¶</a></h1>
<p><em>This page presents how to use the iPOJO runtime and its associated service component model. The concepts of the service component model are introduced, followed by a simple example that demonstrates the features of iPOJO.</em></p>
-<h2 id="introduction">Introduction</h2>
+<h2 id="introduction">Introduction<a class="headerlink" href="#introduction" title="Permanent link">¶</a></h2>
<p>iPOJO aims to simplify service-oriented programming on OSGi frameworks; the name iPOJO is an abbreviation for <em>injected POJO</em>. iPOJO provides a new way to develop OSGi service components with the main goal being to simplify service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements. The iPOJO framework allows developers to more clearly separate functional code (i.e., the POJO) from the non-functional code (i.e., dependency management, service provision, configuration, etc.). iPOJO combines the functional and non-functional aspects at run time. To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.</p>
-<h2 id="the-pojo-concept">The POJO concept</h2>
+<h2 id="the-pojo-concept">The POJO concept<a class="headerlink" href="#the-pojo-concept" title="Permanent link">¶</a></h2>
<p>POJO is an acronym for Plain Old Java Object, but it embodies a concept that the simpler and less intrusive the design of a given framework, the better. The name is used to emphasize that a given object is not somehow special, but is an ordinary Java Object. Martin Fowler, Rebecca Parsons and Josh Mackenzie coined the term POJO in September 2000: "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely." From the developer's perspective, the iPOJO framework strives to only require POJOs in as much as it is possible.</p>
-<h2 id="ipojo-service-component-overview">iPOJO service component overview</h2>
+<h2 id="ipojo-service-component-overview">iPOJO service component overview<a class="headerlink" href="#ipojo-service-component-overview" title="Permanent link">¶</a></h2>
<p>A service component is able to provide and/or require services, where a service is an object that implements a given service interface embodied as a Java interface. In addition, iPOJO introduces a callback concept to notify a component about various state changes.</p>
<p>The component is the central concept in iPOJO. In the core iPOJO model, a component describes service dependencies, provided services, and callbacks; this information is recorded in the component's metadata. Then, the second important concept in iPOJO is component instances. A component instances is a special <em>version</em> of the component. By merging component metadata and instance configuration, the iPOJO runtime is able to manage the component, i.e., manage its life cycle, inject required services, publish provided services, discover needed services.</p>
-<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">¶</a></h2>
<p>The following is a simple example illustrating how to use the core iPOJO concepts. The example is comprised of two components, one providing a <em>Hello</em> service and one requiring any number of <em>Hello</em> services. The components are packaged into three different bundles using Maven. The <em>hello.service</em> bundle contains the service interface. The <em>hello.impl</em> bundle contains a component implementing the service. The <em>hello.client</em> bundle contains the consumer component.</p>
<p>Download the tutorial archive <a href="http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.distribution.maventutorial/1.12.1/org.apache.felix.ipojo.distribution.maventutorial-1.12.1.zip">here</a>. This archive contains a version of Felix (configured with iPOJO), and the projects explained below.</p>
-<h3 id="preparing-maven-installing-the-tutorial">Preparing Maven & Installing the tutorial</h3>
+<h3 id="preparing-maven-installing-the-tutorial">Preparing Maven & Installing the tutorial<a class="headerlink" href="#preparing-maven-installing-the-tutorial" title="Permanent link">¶</a></h3>
<p>The first step is to download and install Maven; the example was created using Maven 2.1+. Once maven is installed on your machine, you can compile the tutorial by unzipping the archive, and by launching the <code>mvn clean install</code> command at the root of tutorial.</p>
<p><em>Be aware that Maven outputs a lot of information while it executes and often downloads a lot of required JAR files into its local repository.</em></p>
-<h3 id="hello-service">Hello Service</h3>
+<h3 id="hello-service">Hello Service<a class="headerlink" href="#hello-service" title="Permanent link">¶</a></h3>
<p>The first project is the <em>hello.service</em> project. This project contains only the <em>hello</em> service interface. Look at the <code>src/main/java/ipojo/example/hello/Hello.java</code> file:</p>
<div class="codehilite"><pre><span class="cm">/**</span>
<span class="cm"> * Hello Interface.</span>
@@ -242,7 +253,7 @@
<p>Maven should report that the build was a success; if an error was reported then verify the previous steps. Upon success the <em>Hello</em> service component JAR file is installed into the local Maven repository. A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.</p>
-<h3 id="hello-service-provider">Hello Service Provider</h3>
+<h3 id="hello-service-provider">Hello Service Provider<a class="headerlink" href="#hello-service-provider" title="Permanent link">¶</a></h3>
<p>The component implementation of the service is a simple Java class implementing the <em>Hello</em> service interface. The implementation is in the <em>hello.impl</em> project. The file <code>src/main/java/ipojo/example/hello/impl/HelloImpl.java</code> contains the following service implementation:</p>
<div class="codehilite"><pre><span class="cm">/**</span>
<span class="cm"> * Component implementing the Hello service.</span>
@@ -335,7 +346,7 @@
<p>Maven should report that the build was a success; if an error was reported then verify the previous steps. Upon success the <em>Hello</em> service component JAR file is installed into the local Maven repository. A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.</p>
-<h3 id="hello-service-client">Hello Service Client</h3>
+<h3 id="hello-service-client">Hello Service Client<a class="headerlink" href="#hello-service-client" title="Permanent link">¶</a></h3>
<p>The Hello service consumer is inside the <em>hello.client</em> project. The file <code>src/main/java/ipojo/example/hello/client/HelloClient.java</code> contains the following <em>Hello</em> service client:</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">ipojo</span><span class="o">.</span><span class="na">example</span><span class="o">.</span><span class="na">hello</span><span class="o">.</span><span class="na">client</span><span class="o">;</span>
@@ -488,7 +499,7 @@ After the skeleton "pom.xml" file is mod
<p>Maven should report that the build was a success; if an error was reported then verify the previous steps. Upon success the <em>Hello</em> service component JAR file is installed into the local Maven repository. A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.</p>
-<h2 id="running-the-example">Running the example</h2>
+<h2 id="running-the-example">Running the example<a class="headerlink" href="#running-the-example" title="Permanent link">¶</a></h2>
<p>To run the example, start Felix. A distribution of Felix is provided in the felix-1.0.3 directory. This version is configured to launch iPOJO automatically. From the Felix directory, launch the following command to start the framework</p>
<div class="codehilite"><pre>java -jar bin/felix.jar
</pre></div>
@@ -554,7 +565,7 @@ instance name="ipojo.example.hello.clien
handler name="org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler" state="valid"<br>
handler name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler" state="valid"</p></div>
-<h2 id="conclusion">Conclusion</h2>
+<h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">¶</a></h2>
<p>We saw how to use easily iPOJO to build service-oriented components. Subscribe to the Felix users mailing list by sending a message to <a href="mailto:users-subscribe@felix.apache.org">users-subscribe@felix.apache.org</a>; after subscribing, email questions or feedback to <a href="mailto:users@felix.apache.org">users@felix.apache.org</a>.</p>
</div>
</div>
@@ -570,7 +581,7 @@ instance name="ipojo.example.hello.clien
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1566571 by clement on Mon, 10 Feb 2014 10:39: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-gettingstarted/ipojo-in-10-minutes.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.html Tue Sep 1 06:05:17 2015
@@ -171,29 +171,40 @@
<div class="container">
<div class="content">
- <h1 id="ipojo-in-10-minutes">iPOJO in 10 minutes</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-in-10-minutes">iPOJO in 10 minutes<a class="headerlink" href="#ipojo-in-10-minutes" title="Permanent link">¶</a></h1>
<p>This page presents how to use the iPOJO runtime and its associated service component model. The concepts of the service component model are introduced, followed by a simple example that demonstrates the features of iPOJO. This tutorial uses annotations to describe components. However, you can also use XML or a programmatic API to create iPOJO applications.</p>
-<h2 id="introduction">Introduction</h2>
+<h2 id="introduction">Introduction<a class="headerlink" href="#introduction" title="Permanent link">¶</a></h2>
<p>iPOJO aims to simplify service-oriented programming on OSGi frameworks; the name iPOJO is an abbreviation for <em>injected POJO</em>. iPOJO provides a new way to develop OSGi service components, simplifying service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements. The iPOJO framework allows developers to more clearly separate functional code (i.e., POJOs) from the non-functional code (i.e., dependency management, service provision, configuration, etc.). At run time, iPOJO combines the functional and non-functional aspects. To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.</p>
-<h2 id="the-pojo-concept">The POJO concept</h2>
+<h2 id="the-pojo-concept">The POJO concept<a class="headerlink" href="#the-pojo-concept" title="Permanent link">¶</a></h2>
<p>"POJO" is just an acronym for Plain Old Java Object, but it embodies a concept that the simpler and less intrusive the design of a given framework, the better. The name is used to emphasize that a given object is not somehow special, but is an ordinary Java Object. Martin Fowler, Rebecca Parsons and Josh Mackenzie coined the term POJO in September 2000: "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely." From a developer's perspective, the iPOJO framework strives as much as possible to only require POJOs.</p>
-<h2 id="ipojo-service-component-overview">iPOJO service component overview</h2>
+<h2 id="ipojo-service-component-overview">iPOJO service component overview<a class="headerlink" href="#ipojo-service-component-overview" title="Permanent link">¶</a></h2>
<p>A service component is able to provide and/or require services, where a service is an object that implements a given Java interface. In addition, iPOJO introduces a callback concept to notify a component about various state changes.</p>
<p>The component is a central concept in iPOJO. In the core iPOJO model, a component describes service dependencies, provided services, and callbacks; this information is recorded in the component's metadata. After components, the next most important concept in iPOJO is the component instance. A component instance is a special <em>version</em> of a component. By merging component metadata and instance configuration, the iPOJO runtime is able to discover and inject required services, publish provided services, and manage the component's life cycle.</p>
-<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">¶</a></h2>
<p>In this tutorial we will present how to:</p>
<ul>
<li>Publish an OSGi service</li>
<li>Require an OSGi service</li>
<li>Use lifecycle callbacks to activate and deactivate components</li>
</ul>
-<h3 id="presentation-of-the-spell-application">Presentation of the <em>Spell</em> application</h3>
+<h3 id="presentation-of-the-spell-application">Presentation of the <em>Spell</em> application<a class="headerlink" href="#presentation-of-the-spell-application" title="Permanent link">¶</a></h3>
<p>To illustrate iPOJO features, we will implement a very simple application. This application is composed by three components:
<em> A component implementing a dictionary service
</em> A component requiring the dictionary service and providing a spellchecker service
* A component requiring the spellchecker and providing an user interface</p>
<p><img src="spell.png"></p>
-<h3 id="preparing-the-tutorial">Preparing the tutorial</h3>
+<h3 id="preparing-the-tutorial">Preparing the tutorial<a class="headerlink" href="#preparing-the-tutorial" title="Permanent link">¶</a></h3>
<p>This tutorial is based on Ant. So, you need to have the Ant program accessible in your path (see <a href="http://ant.apache.org/">here</a> to download and install Ant). Download the tutorial archive available <a href="http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.distribution.10mintutorial/1.12.1/org.apache.felix.ipojo.distribution.10mintutorial-1.12.1.zip">here</a> and then unzip it. The archive contains seven directories:</p>
<ul>
<li>spell.services contains service interfaces used by the applications</li>
@@ -204,7 +215,7 @@
<li>The solution directory contains an already developed version of the application.</li>
<li>Finally, the felix folder contains a configured version of the Felix runtime</li>
</ul>
-<h3 id="the-spellservices-project">The spell.services project</h3>
+<h3 id="the-spellservices-project">The spell.services project<a class="headerlink" href="#the-spellservices-project" title="Permanent link">¶</a></h3>
<p>The spell.services project contains only service interfaces. It is not an iPOJO powered bundle.</p>
<p>Go inside the spell.services directory and open the file "src/spell/services/DictionaryService.java". It's a very simple service interface with one method:</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">spell</span><span class="o">.</span><span class="na">services</span><span class="o">;</span>
@@ -268,7 +279,7 @@ Total <span class="nb">time</span>: 0 se
<p>The created bundle is inside the output directory (spell.services.jar). The build process uses <a href="http://www.aqute.biz/Code/Bnd">BND</a>. The bundle manifest is described in the spell.services.bnd file.</p>
<p>Once this project is done, we are able to implement a Dictionary service.</p>
-<h3 id="the-spellenglish-project-providing-an-osgi-service">The spell.english project: Providing an OSGi service</h3>
+<h3 id="the-spellenglish-project-providing-an-osgi-service">The spell.english project: Providing an OSGi service<a class="headerlink" href="#the-spellenglish-project-providing-an-osgi-service" title="Permanent link">¶</a></h3>
<p>The spell.english project is a simple dictionary implementation of the Dictionary service. It contains few English words. This implementation is an iPOJO component.</p>
<p>The first step is to implement the service. Go in the spell.english directory and open the "src/spell/english/EnglishDictionary.java" file. Replace its content with:</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">spell</span><span class="o">.</span><span class="na">english</span><span class="o">;</span>
@@ -348,7 +359,7 @@ Total <span class="nb">time</span>: 0 se
<p>The created bundle is inside the output directory (spell.english.jar). The build process is based on BND and on the iPOJO Ant task. The manifest of the bundle is described in the <code>spell.english.bnd</code> file.</p>
-<h3 id="the-spellchecker-project-requiring-an-osgi-service">The spell.checker project: Requiring an OSGi service</h3>
+<h3 id="the-spellchecker-project-requiring-an-osgi-service">The spell.checker project: Requiring an OSGi service<a class="headerlink" href="#the-spellchecker-project-requiring-an-osgi-service" title="Permanent link">¶</a></h3>
<p>The spell.checker project aims to provide a <em>spell checker</em> service. However, to serve this service, this implementation requires a <em>dictionary</em> service. During this step, we will create an iPOJO component requiring a Dictionary service and providing the Spell Checker service.</p>
<p>First, go the the spell.checker directory and open the file <code>src/spell/checker/SpellCheck.java</code>. Replace its content with:</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">spell</span><span class="o">.</span><span class="na">checker</span><span class="o">;</span>
@@ -417,7 +428,7 @@ Total <span class="nb">time</span>: 0 se
<p>This class implements the SpellChecker service interface as it provides it. Moreover, it has a <em>special</em> field <code>dictionary</code>. This field represents the required service. iPOJO injects a Dictionary service when needed. So, the class can use it directly. Notice that this class as no OSGi specific code, both the service providing and the requiring are managed by iPOJO and described using annotations. When the used dictionary service leaves, iPOJO tries to find another provider. If no more providers are available, the instance is invalidated, and the provided service is withdrawn from the service registry.</p>
<p>The @Component, @Instantiate and @Provides annotations were already presented. The <code>@Requires</code> annotation specifies a service dependency. This example shows field injection, but iPOJO also supports constructor injection and method injection (with <code>@Bind</code> and <code>@Unbind</code>).</p>
<p>Finally, we are able to build the bundle. As for previous projects, launch Ant from the project directory.</p>
-<h3 id="the-spellcheckergui-project">The spell.checker.gui project</h3>
+<h3 id="the-spellcheckergui-project">The spell.checker.gui project<a class="headerlink" href="#the-spellcheckergui-project" title="Permanent link">¶</a></h3>
<p>The spell.check.gui project contains a very simple user interface (in Swing) allowing a user to interact with a <em>spell checker</em> service.</p>
<p>Go to the spell.checker.gui directory. Open the <code>src\spell\gui\SpellCheckerGui.java</code>. Replace its content with:</p>
<div class="codehilite"><pre><span class="kn">package</span> <span class="n">spell</span><span class="o">.</span><span class="na">gui</span><span class="o">;</span>
@@ -545,7 +556,7 @@ Total <span class="nb">time</span>: 0 se
<p>Look at the three last methods. The <em>check</em> methods collects the user input and uses a <em>Check speller</em> service to check this input. The speller is injected into the <code>checker</code> field thanks to the <code>@Requires</code> annotation. This method is called when the user presses the button. The <em>start</em> and <em>stop</em> methods are lifecycle callbacks. As we display the user interface when the instance is created and to dispose it when the instance stops, we need a way to be notified when we need to execute these actions. iPOJO provides an easy way to do this. The component provides two callback methods for its activation and deactivation. Callbacks are used when the component needs to be informed about a component state change. In iPOJO, the component state is either <em>INVALID</em> (i.e., not all of the component's constraints are satisfied) or <em>VALID</em> (i.e., all of the component's constraints are satisfied). In this example, the start callback
method sets the GUI visibility to true; the stop callback method deletes the GUI. The <code>@Validate</code> and <code>@Invalidate</code> annotations are used to specify these callbacks.</p>
<p>Once this file is created, you can compile the project by launching <em>ant</em> in the spell.checker.gui directory.</p>
-<h2 id="running-the-application">Running the application</h2>
+<h2 id="running-the-application">Running the application<a class="headerlink" href="#running-the-application" title="Permanent link">¶</a></h2>
<p>We have all the bundles required to start playing with the application.</p>
<p>To run the example, start Felix. A distribution of Felix is provided in the felix-framework-VERSION directory. This version is configured to launch iPOJO automatically. From the Felix directory, launch the following command to start the framework. Then enter a profile name.</p>
<div class="codehilite"><pre>java -jar bin/felix.jar
@@ -628,7 +639,7 @@ Instance spell.english.EnglishDictionary
</pre></div>
-<h2 id="conclusion">Conclusion</h2>
+<h2 id="conclusion">Conclusion<a class="headerlink" href="#conclusion" title="Permanent link">¶</a></h2>
<p>We saw how to use easily iPOJO to build service-oriented component. In this tutorial, we have demonstrated how to:</p>
<ul>
<li>Publish OSGi services</li>
@@ -650,7 +661,7 @@ Instance spell.english.EnglishDictionary
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1531562 by clement on Sat, 12 Oct 2013 17:19: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-junit4osgi.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.html Tue Sep 1 06:05:17 2015
@@ -171,9 +171,20 @@
<div class="container">
<div class="content">
- <h1 id="the-junit4osgi-framework-a-simple-test-framework-for-osgi">The JUnit4OSGi framework: a simple test framework for OSGi</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-junit4osgi-framework-a-simple-test-framework-for-osgi">The JUnit4OSGi framework: a simple test framework for OSGi<a class="headerlink" href="#the-junit4osgi-framework-a-simple-test-framework-for-osgi" title="Permanent link">¶</a></h1>
<p><em>JUnit4OSGi is a test framework executing JUnit tests on an OSGi runtime. JUnit4OSGi provides a JUnit++ environment specialized for OSGi, several runners and a maven plugin executing your tests during your build process</em></p>
-<h2 id="why-junit4osgi">Why JUnit4OSGi ?</h2>
+<h2 id="why-junit4osgi">Why JUnit4OSGi ?<a class="headerlink" href="#why-junit4osgi" title="Permanent link">¶</a></h2>
<p>OSGi is a great technology to create modular and dynamic applications. However, creating modular applications raise the need of integration tests: How to be sure that all my modules/services... collaborate correctly. Unit test is great, but does not really check my whole system and the relation between my modules.
Junit4OSGi is a framework allowing the execution of JUnit tests in an OSGi environment ! It stems from the fact that testing applications on top on OSGi is quite complex compared to classic Java unitary tests. With junit4osgi you will be able to test all your bundles together and check that everything works correctly (integration tests).</p>
<p>The goal of JUnit4OSGi is to provide the same mechanisms as unitary tests in an OSGi context. It allows using the JUnit concepts, although tests are run in an OSGi framework, using all of its distinctiveness. The JUnit4OSGi framework allows you to :
@@ -199,7 +210,7 @@ Junit4OSGi is a framework allowing the e
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1441864 by fmeschbe on Sun, 3 Feb 2013 06:44:40 +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-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.html Tue Sep 1 06:05:17 2015
@@ -171,12 +171,22 @@
<div class="container">
<div class="content">
- <h1 id="junit4osgi-framework-architecture">junit4osgi framework 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="junit4osgi-framework-architecture">junit4osgi framework architecture<a class="headerlink" href="#junit4osgi-framework-architecture" title="Permanent link">¶</a></h1>
<p><em>This page describes the architecture of the junit4osgi framework. This does not include the maven-junit4osgi-plugin.</em></p>
-<p>{div:class=toc}
-[TOC]
-{div}</p>
-<h2 id="global-architecture">Global architecture</h2>
+<p div="div">{div:class=toc}
+[TOC]</p>
+<h2 id="global-architecture">Global architecture<a class="headerlink" href="#global-architecture" title="Permanent link">¶</a></h2>
<p>!junit4osgi-arch.png|align=center, width=50%, height=50%!</p>
<p>A system tested with junit4OSGi is divide in three parts:
1. The tested system composed by bundles/services/... composing the system under tests. This can be the <code>true</code> application.
@@ -192,7 +202,7 @@
</em> Swing runner: executing test from a Swing application (works for Felix, Equinox and Knopflerfish)
<em> Immediate runner: executing test as soon the runner arrives in the framework (works for Felix, Equinox and Knopflerfish)
</em> Maven runner: launching an embedded Felix with required bundle and launching test automatically during the Maven build process.</p>
-<h2 id="why-junit-3">Why junit 3 ?</h2>
+<h2 id="why-junit-3">Why junit 3 ?<a class="headerlink" href="#why-junit-3" title="Permanent link">¶</a></h2>
<p>The junit4OSGi framework use junit 3 because it was design and developed to test embedded systems. So, the junit4OSGi framework runs on a J2ME Foundation Profile 1.1 virtual machine (such as Mika). However, soon, junit4OSGi will evolve to support Junit4 and TestNG.</p>
</div>
</div>
@@ -208,7 +218,7 @@
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1441864 by fmeschbe on Sun, 3 Feb 2013 06:44:40 +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-junit4osgi/apache-felix-ipojo-junit4osgi-maven.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.html (original)
+++ websites/staging/felix/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.html Tue Sep 1 06:05:17 2015
@@ -171,12 +171,22 @@
<div class="container">
<div class="content">
- <h1 id="the-maven-junit4osgi-plugin">The Maven-junit4OSGi-plugin</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-maven-junit4osgi-plugin">The Maven-junit4OSGi-plugin<a class="headerlink" href="#the-maven-junit4osgi-plugin" title="Permanent link">¶</a></h1>
<p><em>junit4OSGi tests can also be executed automatically during the <code>integration-test</code> phase of a maven build process. This page describes the maven-junit4osgi-plugin allowing a seamless maven integration.</em> </p>
-<p>{div:class=toc}
-[TOC]
-{div}</p>
-<h2 id="what-does-the-maven-junit4osgi-plugin-provide">What does the maven-junit4osgi-plugin provide?</h2>
+<p div="div">{div:class=toc}
+[TOC]</p>
+<h2 id="what-does-the-maven-junit4osgi-plugin-provide">What does the maven-junit4osgi-plugin provide?<a class="headerlink" href="#what-does-the-maven-junit4osgi-plugin-provide" title="Permanent link">¶</a></h2>
<div class="codehilite"><pre><span class="o">*</span> <span class="n">Allows</span> <span class="n">testing</span> <span class="n">OSGi</span> <span class="n">applications</span>
<span class="o">*</span> <span class="n">Integrated</span> <span class="n">in</span> <span class="n">a</span> <span class="n">Maven</span><span class="o">-</span><span class="n">based</span> <span class="n">build</span> <span class="n">process</span>
<span class="o">*</span> <span class="n">Provides</span> <span class="n">the</span> <span class="n">same</span> <span class="n">output</span> <span class="n">as</span> <span class="n">Surefire</span>
@@ -184,8 +194,8 @@
</pre></div>
-<h2 id="using-the-plug-in">Using the plug-in</h2>
-<h3 id="download-and-building-the-plug-in">Download and building the plug-in</h3>
+<h2 id="using-the-plug-in">Using the plug-in<a class="headerlink" href="#using-the-plug-in" title="Permanent link">¶</a></h2>
+<h3 id="download-and-building-the-plug-in">Download and building the plug-in<a class="headerlink" href="#download-and-building-the-plug-in" title="Permanent link">¶</a></h3>
<p>The plug-in sources are available in the iPOJO trunk.
However the junit4osgi and iPOJO runtime are also required. So, download the source of iPOJO:
<code>svn co http://svn.apache.org/repos/asf/felix/trunk/ipojo/</code>
@@ -195,7 +205,7 @@ To compile it, run the following command
</pre></div>
-<h2 id="simple-configuration">Simple configuration</h2>
+<h2 id="simple-configuration">Simple configuration<a class="headerlink" href="#simple-configuration" title="Permanent link">¶</a></h2>
<p>So, first the project using the plug-in is not the project under test. It's another project containing either only integration-test packaged in a bundle, or is empty (and so depends on other bundles containing integration tests).
Tests contained in the project are developed with junit4osgi, and are packaged in a bundle with the maven-bundle-plugin.
In the pom file, add the following plugin configuration to use the maven-junit4osgi-plugin:</p>
@@ -216,9 +226,9 @@ In the pom file, add the following plugi
</pre></div>
-<h2 id="plugin-parameter">Plugin parameter</h2>
+<h2 id="plugin-parameter">Plugin parameter<a class="headerlink" href="#plugin-parameter" title="Permanent link">¶</a></h2>
<p>The plug-in has only one parameter. The <code>deployProjectArtifact</code> parameter enables or disables the current artifact deployment. If the current project contains tests, the plug-in can deploy the built artifact (as illustrated in this pom). Otherwise, the current project artifact is not deployed. This can be useful if the project just depends on other test bundles and sets the test configuration (as this pom).</p>
-<h3 id="configuring-the-set-of-bundles-to-deploy">Configuring the set of bundles to deploy</h3>
+<h3 id="configuring-the-set-of-bundles-to-deploy">Configuring the set of bundles to deploy<a class="headerlink" href="#configuring-the-set-of-bundles-to-deploy" title="Permanent link">¶</a></h3>
<p>There is two different ways to configure the plug-in to deploy other bundles. If the bundle to deploy is a maven artifact, just add this artifact as a maven project dependency. Here is an example:</p>
<div class="codehilite"><pre><span class="nt"><dependency></span>
<span class="nt"><artifactid></span>tests.manipulation.metadata<span class="nt"></artifactid></span>
@@ -239,7 +249,7 @@ In the pom file, add the following plugi
<p>Set bundles are installed and started. You can depend on bundle that does not contain test as well as bundle containing tests.</p>
-<h3 id="configuring-felix">Configuring Felix</h3>
+<h3 id="configuring-felix">Configuring Felix<a class="headerlink" href="#configuring-felix" title="Permanent link">¶</a></h3>
<p>It is also possible to set Felix properties in the configuration:</p>
<div class="codehilite"><pre><span class="nt"><configuration></span>
<span class="nt"><configuration></span>
@@ -249,7 +259,7 @@ In the pom file, add the following plugi
</pre></div>
-<h3 id="showinghiding-test-trace">Showing/hiding test trace</h3>
+<h3 id="showinghiding-test-trace">Showing/hiding test trace<a class="headerlink" href="#showinghiding-test-trace" title="Permanent link">¶</a></h3>
<p>The plugin collects System.out, System.err and logged messages to write them in the test report. Moreover, the plugin allows hiding traces when tests are executed. To achieve this just add the <code>hideOutputs</code> parameter.</p>
<div class="codehilite"><pre><span class="nt"><configuration></span>
<span class="nt"><hideOutputs></span>true<span class="nt"></hideOutputs></span>
@@ -257,25 +267,25 @@ In the pom file, add the following plugi
</pre></div>
-<h3 id="disablingenabling-the-log-service">Disabling/Enabling the Log Service</h3>
+<h3 id="disablingenabling-the-log-service">Disabling/Enabling the Log Service<a class="headerlink" href="#disablingenabling-the-log-service" title="Permanent link">¶</a></h3>
<p>The plugin exposed a LogService in the OSGi framework to collects logged messaged. This service enabled by default. You can diable it by launching the plugin with the <code>logService</code> property set to <code>false</code></p>
<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">clean</span> <span class="n">integration</span><span class="o">-</span><span class="n">test</span> <span class="o">-</span><span class="n">DlogService</span><span class="p">=</span><span class="n">false</span>
</pre></div>
-<h3 id="skipping-integration-test">Skipping integration-test</h3>
+<h3 id="skipping-integration-test">Skipping integration-test<a class="headerlink" href="#skipping-integration-test" title="Permanent link">¶</a></h3>
<p>Sometimes you want to skip tests :-(. The plugin uses the <code>maven.test.skip</code> property to skip tests such as </p>
<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">clean</span> <span class="n">install</span> <span class="o">-</span><span class="n">Dmaven</span><span class="p">.</span><span class="n">test</span><span class="p">.</span><span class="n">skip</span><span class="p">=</span><span class="n">true</span>
</pre></div>
-<h3 id="ignoring-failures">Ignoring failures</h3>
+<h3 id="ignoring-failures">Ignoring failures<a class="headerlink" href="#ignoring-failures" title="Permanent link">¶</a></h3>
<p>If tests throws errors or have failures, the plugin breaks the Maven build. You can by-pass this behavior by ignoring errors and failures. This is useful during test generation. </p>
<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">clean</span> <span class="n">install</span> <span class="o">-</span><span class="n">Dmaven</span><span class="p">.</span><span class="n">test</span><span class="p">.</span><span class="n">failure</span><span class="p">.</span><span class="n">ignore</span><span class="p">=</span><span class="n">true</span>
</pre></div>
-<h2 id="executing-the-plug-in">Executing the plug-in</h2>
+<h2 id="executing-the-plug-in">Executing the plug-in<a class="headerlink" href="#executing-the-plug-in" title="Permanent link">¶</a></h2>
<p>To execute test, just launch the <code>mvn clean integration-test</code> command.</p>
<div class="codehilite"><pre><span class="p">[</span><span class="n">INFO</span><span class="p">]</span> <span class="n">Scanning</span> <span class="k">for</span> <span class="n">projects</span><span class="p">...</span>
<span class="p">[</span><span class="n">INFO</span><span class="p">]</span> <span class="o">------------------------------------------------------------------------</span>
@@ -336,7 +346,7 @@ In the pom file, add the following plugi
<p>Failures and errors are reported in the plugin output.</p>
-<h2 id="generating-the-report-web-page">Generating the report web page</h2>
+<h2 id="generating-the-report-web-page">Generating the report web page<a class="headerlink" href="#generating-the-report-web-page" title="Permanent link">¶</a></h2>
<p>When test are executed, the plug-in generates XML reports (int the target/junit4osgi-reports directory) using the same convention as Surefire. So, it is possible to configure Surefire to generate the web page with test results.
To do this, add the following report configuration to the project executing tests:</p>
<div class="codehilite"><pre><span class="nt"><reporting></span>
@@ -388,7 +398,7 @@ mvn org.apache.maven.plugins:maven-suref
may be trademarks or registered trademarks of their respective owners.
</div>
<div class="timestamp span3 offset2">
- Rev. 1441864 by fmeschbe on Sun, 3 Feb 2013 06:44:40 +0000
+ Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
</div>
</div>
</footer>