felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From clem...@apache.org
Subject svn commit: r1443557 - /felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/
Date Thu, 07 Feb 2013 15:34:04 GMT
Author: clement
Date: Thu Feb  7 15:34:03 2013
New Revision: 1443557

URL: http://svn.apache.org/viewvc?rev=1443557&view=rev
Log:
update pages to new CMS

Added:
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app1.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app2.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app3.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app4.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app5.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app6.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/design.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss-comp.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/vendor.png   (with props)
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/wsdl.png   (with props)
Modified:
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext
    felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext

Modified: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext?rev=1443557&r1=1443556&r2=1443557&view=diff
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext (original)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext Thu Feb  7 15:34:03 2013
@@ -8,29 +8,30 @@ Title: apache-felix-ipojo-dosgi
 *Distributed Service defines how to deal with remote services in OSGi. This page describes the CXF Distributed OSGi with iPOJO demo.This demo uses iPOJO to create a remote OSGi service from an iPOJO component. The consumer side also uses iPOJO to create a component that consumes the remote OSGi service. By using iPOJO, you don't need to write code to interact with the OSGi Service Registry at all. That's all handled through injection, which hugely simplifies the code. Moreover thanks to iPOJO's advanced features such as property propagation, the service is exported without any impact on its implementation.*
 
 In this demo, you will show how to use iPOJO:
+
 * to expose a service 
 * to propagate properties to make the service remotely accessible
 * to use a "remote" service
 
 This demo can be used with any DOSGi distribution, in this document the single-bundle distribution (1.1) is used with iPOJO 1.6.0 and Felix (2.0.5)
 
-{div:class=toc}
 [TOC]
-{div}
 
 ## Demo design
 This demo is quite similar to the DS demo of DOSGi demo in structure. It consists of 5 bundles:
+
 * An interface bundle defining the Adder Service interface. 
 * This bundle is deployed on both sides.
 * An Adder Service implementation bundle. (The service will be exported)
 * An Adder Service importer bundle containing the remote-service file explaining to DOSGi how to import and from where to import the Adder service.
 * An Adder Service consumer bundle.
 
-!design.png!
+<img src="design.png">
 
 The service implementation and consumer bundle are built using iPOJO.
 The Adder Service interface is as follows:
 
+    :::java
     public interface AdderService {
         int add(int a,int b);
     }
@@ -44,6 +45,7 @@ The service implementation is a simplist
 
 In the [metadata.xml](http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceProvider/src/main/resources/metadata.xml) file, an instance of the component type is declared. Note that this instance declaration defines three properties used by DOSGi to exports the service. These properties instruct Distributed OSGi into making the service available on http://localhost:9090/adder. Those properties are not declared in the component type itself. Indeed, the component type enables property propagation; so all defined properties will be published on exported services. This propagation also works with the configuration admin. This feature is pretty nice, as it does not impact the component implementation and its description.
 
+    :::xml
     <instance component="org.apache.felix.ipojo.remote.adder.impl.AdderServiceImpl">
         <property name="osgi.remote.interfaces"value="*"/>
         <property name="osgi.remote.configuration.type"value="pojo"/>
@@ -51,40 +53,43 @@ In the [metadata.xml](http://svn.apache.
     </instance>
 
 So let's install the server side in Felix. Launch Felix from the `felix` directory with:
-{div:class=shell}
-java -jar bin/felix.jar server
-{div}
+
+    :::sh
+    java -jar bin/felix.jar server
 
 Once the shell prompt appears, execute the following command in the shell:
-{div:class=shell}
-start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
-start file:../AdderServiceProvider/target/AdderServiceProvider-0.0.1-SNAPSHOT.jar
-{div}
+
+    :::sh
+    start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
+    start file:../AdderServiceProvider/target/AdderServiceProvider-0.0.1-SNAPSHOT.jar
 
 At this point, the service should be available remotely (wait until the console stops printing stuff), you can check this by obtaining the WSDL: [http://localhost:9090/adder?wsdl](http://localhost:9090/adder?wsdl)
 
-!wsdl.png|width=600px!
+<img src="wsdl.png" width="600px">
 
 ## The Adder Service Consumer
 The service consumer is also created using iPOJO. Thanks to DOSGi, iPOJO can inject the service as any regular OSGi service. So, the code is pretty simple:
-{code:java}
-@Component
-public class AdderConsumer {
-
-  @Requires
-  private AdderService adder;
-
-  public AdderConsumer() {
-    System.out.println("Using adder service: 1 + 1 = "+ adder.add(1, 1));
- }
-}
 
-    This implementation use iPOJO field injection to receive the AdderService. Then, it uses it as a regular field. This bundle also contains a [metadata.xml|http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceConsumer/src/main/resources/metadata.xml] file declaring an instance of this type without any special configuration:
-    {code:xml}
+    :::java
+    @Component
+    public class AdderConsumer {
+
+      @Requires
+      private AdderService adder;
+
+      public AdderConsumer() {
+        System.out.println("Using adder service: 1 + 1 = "+ adder.add(1, 1));
+     }
+    }
+
+This implementation use iPOJO field injection to receive the AdderService. Then, it uses it as a regular field. This bundle also contains a [metadata.xml|http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceConsumer/src/main/resources/metadata.xml] file declaring an instance of this type without any special configuration:
+
+    :::xml
     <instance component="org.apache.felix.ipojo.remote.consumer.AdderConsumer"/>
 
 However, now we have to tell to DOSGi to import our Adder service. To achieve that, we create a very simple bundle that just contains the [remote-services.xml](http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceImporter/src/main/resources/OSGI-INF/remote-service/remote-services.xml) file. This file is analyzed by CXF in order to import the service.
 
+    :::xml
     <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
       <service-description>
         <provide interface="org.apache.cxf.dosgi.samples.ds.AdderService"/>
@@ -94,30 +99,32 @@ However, now we have to tell to DOSGi to
       </service-description>
     </service-descriptions>
 
-
 Now, let's start another instance of Felix:
-{div:class=shell}
-java -jar bin/felix.jar client
-{div}
+
+    :::sh
+    java -jar bin/felix.jar client
+
 Then, execute the following command in the shell:
-{div:class=shell}
-start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
-start file:../AdderServiceConsumer/target/AdderServiceConsumer-0.0.1-SNAPSHOT.jar
-start file:../AdderServiceImporter/target/AdderServiceImporter-0.0.1-SNAPSHOT.jar
-
-... log messages may appear, after a little while the following message appears:
-Using adder service: 1 + 1 = 2
-{div}
+
+    :::sh
+    start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
+    start file:../AdderServiceConsumer/target/AdderServiceConsumer-0.0.1-SNAPSHOT.jar
+    start file:../AdderServiceImporter/target/AdderServiceImporter-0.0.1-SNAPSHOT.jar
+
+    ... log messages may appear, after a little while the following message appears:
+
+    Using adder service: 1 + 1 = 2
 
 The remote adder service has now been invoked. You will see the following line on the server side window:
 
+    :::sh
     Adder service invoked: 1 + 1 = 2
 
 That's it !
 
 ## Conclusion
 
-This tutorial has illustrated how to easily create remote services and consume them with iPOJO. Subscribe to the Felix users mailing list by sending a message to [mailto:users-subscribe@felix.apache.org]({{ refs.mailto-users-subscribe-felix-apache-org.path }}); after subscribing, email questions or feedback to [mailto:users@felix.apache.org].
+This tutorial has illustrated how to easily create remote services and consume them with iPOJO. Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org](mailto:users-subscribe@felix.apache.org); after subscribing, email questions or feedback to [users@felix.apache.org](mailto:users@felix.apache.org).
   
   
   

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app1.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app1.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app1.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app2.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app2.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app2.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app3.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app3.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app3.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app4.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app4.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app4.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app5.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app5.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app5.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app6.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app6.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app6.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/design.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/design.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/design.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext?rev=1443557&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext Thu Feb  7 15:34:03 2013
@@ -0,0 +1,374 @@
+translation_pending: true
+Title: How to use iPOJO Annotations
+
+
+
+# How to use iPOJO annotations
+
+*You can use annotations to define your component types. This page presents supported annotations.*
+
+[TOC]
+
+## Getting iPOJO Annotations:
+
+iPOJO Annotations are defines inside the org.apache.felix.ipojo.annotations project. You can download the Jar file of this project from the [download]({{ refs.download.path }}) 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.
+
+### In Eclipse
+
+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).
+
+### In Maven
+
+Add the following dependency:
+
+    :::xml
+    <dependency>
+          <groupId>org.apache.felix</groupId>
+          <artifactId>org.apache.felix.ipojo.annotations</artifactId>
+          <version>1.8.0</version>
+    </dependency>
+
+Moreover, you need to set that the source code and the target code are Java 1.5 code. To achieve this, just add the following plugin in your plugins section:
+
+    :::xml
+    <plugin>
+      <groupId>org.apache.maven.plugins</groupId>
+    	<artifactId>maven-compiler-plugin</artifactId>
+    	<configuration>
+    	  <source>1.5</source>
+    	  <target>1.5</target>
+    	</configuration>
+    </plugin>
+
+
+### In Ant
+
+Just add the org.apache.felix.ipojo.annotations jar file  in your class path.
+
+## An example of usage
+
+To illustrate annotations usage, let taking the tutorial example. In this tutorial, there are two components:
+* The first one provides the hello service
+* The second one uses the provided hello service
+You can download the archive containing the examples and a preconfigured version of Felix [here](http://people.apache.org/~clement/ipojo/tutorials/annotations/annotation-tutorial.zip).
+
+### Hello Service Provider
+
+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.
+
+    :::java
+    package ipojo.example.hello.impl;
+    
+    import ipojo.example.hello.Hello;
+    
+    import org.apache.felix.ipojo.annotations.Component;
+    import org.apache.felix.ipojo.annotations.Provides;
+    
+    /**
+      * Component implementing the Hello service.
+     **/
+    @Component
+    @Provides
+    public class HelloImpl implements Hello {
+        public String sayHello(String name) { 
+         return "hello " + name; 
+        }
+    }
+
+
+### Hello Service Consumer
+
+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.
+
+    :::java
+    package ipojo.example.hello.client;
+    
+    import org.apache.felix.ipojo.annotations.Component;
+    import org.apache.felix.ipojo.annotations.Invalidate;
+    import org.apache.felix.ipojo.annotations.Requires;
+    import org.apache.felix.ipojo.annotations.Validate;
+    
+    import ipojo.example.hello.Hello;
+    
+    @Component(name="AnnotedHelloClient", immediate=true)
+    public class HelloClient implements Runnable {
+    
+    @Requires
+    private Hello[] m_hello; // Service Dependency
+    
+    private final static int DELAY=10000;
+    private boolean end;
+    
+     public void run() {
+        while (!end) {
+                   try {
+    		invoke();
+                    Thread.sleep(DELAY);
+                  } catch (InterruptedException ie) { }
+                  /* will recheck end */
+         }
+    }
+    
+    public void invoke() {
+    	for (int i = 0; i < m_hello.length; i++) { 
+              System.out.println(m_hello[i].
+                 sayHello("Clement")); 
+            }
+    }
+    
+     @Validate
+     public void starting() {    
+        Thread T = new Thread(this);     
+        end = false;     
+        T.start(); 
+     }
+    
+     @Invalidate
+     public void stopping() {    
+         end = true; 
+     }
+    }
+
+
+## Defined Annotations
+
+This section lists defined annotations and how to use them.
+
+### @Component
+
+*Goal:* Defines a component type
+*Target:* The component implementation class
+*Attributes:*
+
+* name : defines the component type name (optional, default = the class name)
+* immediate: defines the component type as immediate (optional, default = "false")
+* architecture: enable the architecture exposition (optional, default = "false")
+* propagation: enable configuration property propagation (on provided services) (optional, default = "false")
+* managedservice : set the Managed Service PID. (optional, default = no PID (i.e. the managed service will not be exposed)). 
+* 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). 
+* publicFactory : set if the component type is public. (optional, default = true). 
+
+### @Provides
+
+*Goal:* Defines that the component type provide services
+*Target:* The component implementation class
+*Attributes:*
+
+* specifications: defines the provided interface (optional, default = all implemented interfaces)
+* strategy : the service object creation strategy. Possible values : SINGLETON, SERVICE, METHOD, INSTANCE or the strategy class name. With SINGLETON there is only one POJO per component instance, SERVICE means OSGi Service factory,  METHOD delegates the creation to the factory-method of the component, INSTANCE creates one service object per requiring instance. For other strategies, specify the qualified name of the CreationStrategy class. (optional, default =  SINGLETON) 
+* properties : array containing `@StaticServiceProperties` defining service properties not attached to fields.
+
+
+<div class="alert alert-warning">
+	<strong>OSGi Service Factory</strong>
+	<br/>
+  The <tt>SERVICE</tt> strategy refers to the OSGi service factory. So, one service object per asking bundle will be created.
+</div>
+
+### @Requires
+
+*Goal:* Defines a service dependency
+*Target:* Field
+*Attributes:*
+
+* Filter: defines the LDAP filter (optional)
+* Optional: defines if the dependency is optional (optional, default = "false")
+* Id: defines the dependency Id (useful to identify bind & unbind methods) (optional, default = field name) (if a dependency with the same id is already created (by a @bind or @unbind annotation), it merges the dependencies).
+* Nullable: enable or disable the Null Object injection when the dependency is optional and no providers are available (optional, default = "true")
+* Defaultimplementation: set the Default-Implmentation (optional, by default iPOJO uses a Null object)
+* Policy: defines the binding policy (accepted value : dynamic, static, dynamic-priority) (optional, default = "dynamic")
+* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
+* From : defines the specific provider to use
+* Specification : the required service specification. This attribute is required for Collection field. (optional, default = annotated field type). 
+* Proxy : enables / disables the proxy injection (enabled by default)
+
+### @ServiceProperty
+
+*Goal:* Defines a service property
+*Target:* Field
+*Attributes:*
+
+* name: property name (optional, default=field name
+* value: property value (optional, default=no value)
+* mandatory : is the property mandatory? (optional, default=false)
+
+
+<div class="alert alert-warning">
+		<strong>Mandatory property</strong>
+	 <br/>
+A mandatory property must receive a value either from the component type description (<tt>value</tt> attribute), or the instance configuration.
+</div>
+
+
+### @ServiceController
+
+*Goal:* Control the service exposition
+*Target:* Field (Boolean)
+*Attributes:*
+
+* value : the default value. If set to false, it disables the initial exposition
+* specification : set the target of the controller, must be an exposed service interface. By default, the controller targets all services.
+
+
+### @Property
+
+*Goal:* Defines a property
+*Target:* Field or Method
+*Attributes:*
+
+* name: property name (optional, default=field name computed by removing "set" from the method name (for instance setFoo(String ff) will get the Foo name))
+* value: property value (optional, default=no value)
+* mandatory : is the property mandatory? (optional, default=false)
+
+
+<div class="alert alert-warning">
+  <strong>Field and Method</strong>
+	<br/>
+  If another property with the same name is defined the method or the field is added to the existing property.
+</div>
+
+
+### @Updated
+*Goal:* Defines method called when a reconfiguration is completed.
+*Target:* a method (receiving a dictionary in argument)
+
+### @Bind
+
+*Goal:* Defines a bind method
+*Target:* Method
+*Attributes:*
+
+* Id: Dependency Id, if the id is already defines in a "@requires " or "@unbind" annotation, it adds this method as a bind method of the already created dependency. (optional, default= no id, compute an id if the method name begin by "bind" (for instance "bindFoo" will have the "Foo" id))
+* Specification : required dependency (optional)
+* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
+* Optional: is the dependency an optional dependency (optional, default= "false")
+* Filter: dependency LDAP filter (optional)
+* Policy: defines the binding policy (accepted value : dynamic, static, dynamic-priority) (optional, default = "dynamic")
+* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
+* From : defines the specific provider to use
+
+
+### @Unbind
+
+*Goal:* Defines an unbind method
+*Target:* Method
+*Attributes:*
+
+* Id: Dependency Id, if the id is already defines in a "@requires" or "@bind" annotation, it adds this method as an unbind method of the already created dependency. (optional, default= no id, compute an id if the method name begin by "unbind" (for instance "unbindFoo" will have the "Foo" id))
+* Specification : required dependency (optional)
+* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
+* Optional: is the dependency an optional dependency (optional, default= "false")
+* Filter: dependency LDAP filter (optional)
+* Policy: defines the binding policy (accepted value : dynamic, static, dynamic-priority) (optional, default = "dynamic")
+* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
+* From : defines the specific provider to use
+
+### @Modified
+
+*Goal:* Defines an `modified` method, called when a bound service is udpated.
+*Target:* Method
+*Attributes:*
+
+* Id: Dependency Id, if the id is already defines in a "@requires" or "@bind" annotation, it adds this method as an unbind method of the already created dependency. (optional, default= no id, compute an id if the method name begin by "unbind" (for instance "unbindFoo" will have the "Foo" id))
+* Specification : required dependency (optional)
+* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
+* Optional: is the dependency an optional dependency (optional, default= "false")
+* Filter: dependency LDAP filter (optional)
+* Policy: defines the binding policy (accepted value : dynamic, static, dynamic-priority) (optional, default = "dynamic")
+* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
+* From : defines the specific provider to use
+
+### @Validate
+
+*Goal:* defines a validate lifecycle callback
+*Target:* method
+
+### @Invalidate
+
+*Goal:* defines a validate lifecycle callback
+*Target:* method
+
+### @PostRegistration
+
+*Goal:* defines a callback invoked after service registration. The callback must have the following signature : `public void name(ServiceReference ref)`
+*Target:* method
+
+### @PostUnregistration
+
+*Goal:* defines a callback invoked after service unregistration. The callback must have the following signature : `public void name(ServiceReference ref)`
+*Target:* method
+
+### @Instantiate
+
+*Goal:* declare a simple instance (this is equivalent to `<instance component="..."></instance>`
+*Target:* class
+*Attribute:*
+
+* name: the instance name (optional)
+
+### Temporal Dependencies (external handler)
+
+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 `org.apache.felix.ipojo.handler.temporal.Requires` and targets a field. 
+*Attributes:*
+
+ * filter : specify the dependency filter
+ * timeout : specify the dependency timeout (optional)
+ * onTimeout : specify the onTimeout action (null, nullable, empty-array, default-implementation (specify the class name in this case) (optional).
+ * specification : the required service specification. This attribute is required for Collection field. (optional, default = annotated field type). 
+ * proxy :  Inject a proxy instead of the real object. This allows passing this reference to collaborators. (Default = false) 
+
+
+
+### Exposing instances as a JMX MBean (external handler)
+
+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 `org.apache.felix.ipojo.handlers.jmx` package
+
+The `@org.apache.felix.ipojo.handlers.jmx.Config` (`@Config` if the package it correctly imported) annotation is a type annotation (so placed on the `class` element. This annotation indicates that the instance will be exposed as an MBean. This annotation supports:
+
+* usesMOSGi: set to `true` to use MOSGi. Otherwise, the MBean will be exposed in the MBean Platform Server (default: `false`).
+* objectname: set the MBean objectname. The objectname must follow JMX specification. (default: `package-name:factory-name:instance-name`)
+* domain: set the MBean domain. (default: `package-name`)
+* name: set the MBean name. (default: `instance-name`).
+
+The `@org.apache.felix.ipojo.handlers.jmx.Property` (`@Property`) annotation is a field annotation indicating that the field is exposed in the MBean. The supported attributes are:
+
+* name: set the property name
+* rights: set the access permission. Possible values are `r` (read only) and `w` (read and write). By default, properties are in read-only mode.
+* notification: enables notification on this property. By default notifications are disabled.
+
+The `@org.apache.felix.ipojo.handlers.jmx.Method` (`@Method`) annotation is a method annotation indicating that the method is exposed in the MBean. Only one attribute can be customized:
+
+* description: set the method description.
+
+
+## Advanced topics and FAQ
+
+### Metadata file and annotation merge
+
+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.
+
+### Instance creation
+
+The @Instantiate annotation allows creating an instance, but this declaration is limited:
+
+* it does not support configuration
+* it does not allow naming
+* the instance is created in the global scope (so no composition)
+
+To define instances, you should use the XML descriptor. Instance can refer to annotated types by referring to their names.
+
+    ::xml
+    <instance component="ipojo.example.hello.impl.HelloImpl"/>
+    <instance component="AnnotedHelloClient"/>
+
+
+### Using Custom Annotations
+
+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.
+  
+  
+  
+  

Modified: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext?rev=1443557&r1=1443556&r2=1443557&view=diff
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext (original)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext Thu Feb  7 15:34:03 2013
@@ -7,16 +7,18 @@ Title: iPOJO Advanced Tutorial
 
 *This tutorial illustrates some advanced features of iPOJO*
 
-{div:class=toc}
 [TOC]
-{div}
+
 
 ## Context
 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.
-!vendor.png!
+
+<img src="vendor.png">
+
 ## Preparing the tutorial
 The tutorial archive is available [here](http://people.apache.org/~clement/ipojo/tutorials/advanced/advanced.tutorial.zip). This archive contains both the source code and a pre-configured version of Felix. First, unzip the archive. Then, launch `ant` 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 `felix` directory:
 
+    :::sh
     java -jar bin/felix.jar
 
 
@@ -24,20 +26,22 @@ The tutorial archive is available [here]
 The sources of this project are inside the *vendor.buns-and-wieners* 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):
 
-{code:java} 
-public class BunWienerProvider implements BunService, WienerService {
-    
-    public void getBun() {
-        System.out.println("Get a bun");
-    }
+    :::java
+    public class BunWienerProvider implements BunService, WienerService {
+        
+        public void getBun() {
+            System.out.println("Get a bun");
+        }
 
-    public void getWiener() {
-        System.out.println("Get a wiener");
+        public void getWiener() {
+            System.out.println("Get a wiener");
+        }
     }
-}
 
-    This class just implements the two service interfaces. Its descriptor (contained in the metadata.xml file) is:
-    {code:xml}
+
+This class just implements the two service interfaces. Its descriptor (contained in the metadata.xml file) is:
+
+    :::xml
     <ipojo>
     <component 
         classname="org.apache.felix.ipojo.example.vendor.provider.BunWienerProvider" 
@@ -49,11 +53,11 @@ public class BunWienerProvider implement
     </ipojo>
 
 
-In the descriptor, we declare a component type for this vendor which contains the implementation class. The "classname" attribute contains the qualified name of the component implementation. The "name" attribute is the component type name. It is only used to refer to this type.
+In the descriptor, we declare a component type for this vendor which contains the implementation class. The `classname` attribute contains the qualified name of the component implementation. The "name" attribute is the component type name. It is only used to refer to this type.
 
-The "public=false" attribute disables factory exposition. A component type publishing a factory provides a way to create instance of this type from outside this descriptor. In our case, we want to guarantee that only one instance (singleton) can be created, so we disable the factory mechanism.
+The `public=false` attribute disables factory exposition. A component type publishing a factory provides a way to create instance of this type from outside this descriptor. In our case, we want to guarantee that only one instance (singleton) can be created, so we disable the factory mechanism.
 
-iPOJO manages service publication and providing automatically at runtime. The "<provides/>" 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.
+iPOJO manages service publication and providing automatically at runtime. The `<provides/>` 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.
 
 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. 
 
@@ -64,36 +68,37 @@ At runtime, the bundle containing this c
 The sources of this project are inside the *vendor.hotdog* 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 *src/org/apache/felix/ipojo/example/vendor/hotdog/HotDogVendor.java* file) shows a very simple implementation of this component:
 
-{code:java}
-public class HotDogVendor implements Vendor {
-    
-    /**
-     * Bun provider (required service).
-     */
-    private Bun bunProvider;
-    
-    /**
-     * Wiener provider (required service). 
-     */
-    private Wiener wienerProvider;
-    
-    /**
-     * Sell method.
-     * To provide an hotdog, the vendor consume a bun and a wiener.
-     * This method is synchronized to avoid serving to client 
-     * at the same time.
-     * @return a hotdog.
-     * @see org.apache.felix.ipojo.example.vendor.service.Vendor#sell()
-     */
-    public synchronized Product sell() {
-        bunProvider.getBun();
-        wienerProvider.getWiener();
-        return new HotDog();
-    }
+    :::java
+    public class HotDogVendor implements Vendor {
+        
+        /**
+         * Bun provider (required service).
+         */
+        private Bun bunProvider;
+        
+        /**
+         * Wiener provider (required service). 
+         */
+        private Wiener wienerProvider;
+        
+        /**
+         * Sell method.
+         * To provide an hotdog, the vendor consume a bun and a wiener.
+         * This method is synchronized to avoid serving to client 
+         * at the same time.
+         * @return a hotdog.
+         * @see org.apache.felix.ipojo.example.vendor.service.Vendor#sell()
+         */
+        public synchronized Product sell() {
+            bunProvider.getBun();
+            wienerProvider.getWiener();
+            return new HotDog();
+        }
 
     
-    Once implemented, we need to describe this component type. The descriptor file is the _metadata.xml_ file. The field attributes in the "requires" elements are used to inject the required services. At runtime, iPOJO injects automatically a BunService provider in the "bunProvider" field and a WienerService provider in the "wienerProvider" field. The implementation uses these fields the same way it would have used any other fields (as illustrated in the sell method).
-    {code:xml}
+Once implemented, we need to describe this component type. The descriptor file is the _metadata.xml_ file. The field attributes in the "requires" elements are used to inject the required services. At runtime, iPOJO injects automatically a BunService provider in the "bunProvider" field and a WienerService provider in the "wienerProvider" field. The implementation uses these fields the same way it would have used any other fields (as illustrated in the sell method).
+
+    :::xml
     <ipojo>
     <component 
        classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor"
@@ -109,7 +114,7 @@ public class HotDogVendor implements Ven
 
 The component type declares a provided service (the Vendor Service). Then, the component declares the two service dependencies (using the "requires" element). However, we would like to add a service property on the Vendor service describing the sold product (here, "hotdog"). To achieve this, we just need to add a property element in the "provides" tags: 
 
-
+    :::xml
     <ipojo>
     <component 
        classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor" 
@@ -132,26 +137,26 @@ iPOJO then publishes the "product" prope
 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:
 
-{code:java}
-public class BunWienerProvider implements BunService, WienerService {
+    :::java
+    public class BunWienerProvider implements BunService, WienerService {
     
-    private int bunStock;
-    
-    private int wienerStock;
+        private int bunStock;
+        
+        private int wienerStock;
 
-    public synchronized void getBun() {
-        bunStock = bunStock - 1;
-    }
+        public synchronized void getBun() {
+            bunStock = bunStock - 1;
+        }
 
-    public synchronized void getWiener() {
-        wienerStock = wienerStock - 1;
+        public synchronized void getWiener() {
+            wienerStock = wienerStock - 1;
+        }
     }
-}
 
     
-    The stock accesses are synchronized to avoid multiple accesses at the same time. The component type metadata must also be modified in order to describe this property:
+The stock accesses are synchronized to avoid multiple accesses at the same time. The component type metadata must also be modified in order to describe this property:
     
-    {code:xml}
+    :::xml
     <ipojo>
     <component 
        classname="org.apache.felix.ipojo.example.vendor.provider.BunProvider" 
@@ -166,13 +171,13 @@ public class BunWienerProvider implement
     </ipojo>
 
 
-In the "provides" element, two properties are added. This property contains a "field" 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.
+In the `provides` element, two properties are added. This property contains a `field` 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.
 
 ## Configuring instances
 
 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.
 
-
+    :::xml
     <ipojo>
     <component 
        classname="org.apache.felix.ipojo.example.vendor.provider.BunProvider"
@@ -190,14 +195,14 @@ In the previous example, the properties 
     </ipojo>
 
 
-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 `mandatory` attribute to 'true'. 
+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 `mandatory` attribute to `true`. 
 
 
 ## Using filter in service requirements
 
 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:
 
-
+    :::xml
     <ipojo>
     <component 
        classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor"
@@ -216,16 +221,10 @@ Now that bun and wiener providers publis
 When a provider does no more matches with the LDAP filter, the provider is no more used, and another (matching with the filter) is tracked. If no provider fulfilling the constraint is found, the instance becomes invalid and waits a matching provider.
 
 
-<div class="box">
-	<div class="box-blue-header">
-	<div class="box-blue-title">
-		<img src="http://people.apache.org/~clement/ipojo/site/information.gif"> <b>Instance invalidation and services</b>
-	</div>
-	</div>
-	<div class="box-blue-content">
+<div class="alert alert-warning">
+	<strong>Instance invalidation and services</strong>
+	<br/>
 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>
-	<div class="box-blue-footer"></div>
 </div>
 
 
@@ -233,23 +232,24 @@ When an instance becomes invalid, all it
 
 Now that we get the hot dog provider, we are going to implement customers. Customers are implemented in the *vendor.customer* project). A customer simply looks for a vendor service and buys a product:
 
-{code:java}
-public class Customer {
-    
-    private VendorService vendor;
-    
-    private String name;
-    
-    public Customer() {
-        System.out.println("Customer " + name + " bought " 
-           +  vendor.sell() + " from " + vendor.getName());
-    }
+    :::java
+    public class Customer {
+        
+        private VendorService vendor;
+        
+        private String name;
+        
+        public Customer() {
+            System.out.println("Customer " + name + " bought " 
+               +  vendor.sell() + " from " + vendor.getName());
+        }
 
     
-    The previous code shows a possible implementation of a customer. However, the "sell" method is called in a constructor, and the constructor can only be called only if an object of the class is created. With iPOJO there are two different way to "activate" an instance as soon as it becomes valid. 
-    The first one uses the lifecycle callback (described in the previous tutorial).  The second one is by declaring the component as an immediate component. An immediate component instance creates an object of its implementation as soon as it becomes valid. 
+The previous code shows a possible implementation of a customer. However, the "sell" method is called in a constructor, and the constructor can only be called only if an object of the class is created. With iPOJO there are two different way to "activate" an instance as soon as it becomes valid. 
+
+The first one uses the lifecycle callback (described in the previous tutorial).  The second one is by declaring the component as an immediate component. An immediate component instance creates an object of its implementation as soon as it becomes valid. 
     
-    {code:xml}
+    :::xml
     <ipojo>
     <component 
         classname="org.apache.felix.ipojo.example.vendor.customer.Customer" 
@@ -262,30 +262,25 @@ public class Customer {
     </ipojo>
 
 
-To declare a component immediate, just add "immediate=true" in the component descriptor. Then as soon as the vendor service is available, the object is created. Moreover, this type declares a property (to give a name to the customers). This property is not a service property, but just an internal property. As for service properties, the name field will be injected by a value necessary given during the instance creation (i.e. contained inside the instance configuration).
+To declare a component immediate, just add `immediate=true` in the component descriptor. Then as soon as the vendor service is available, the object is created. Moreover, this type declares a property (to give a name to the customers). This property is not a service property, but just an internal property. As for service properties, the name field will be injected by a value necessary given during the instance creation (i.e. contained inside the instance configuration).
 
 By default, all all components that do not provide any service are immediate. Other components create call their constructors when they are used for the first time. 
 
 
-<div class="box">
-	<div class="box-blue-header">
-	<div class="box-blue-title">
-		<img src="http://people.apache.org/~clement/ipojo/site/information.gif"> <b>Difference between 'validate' and 'immediate'</b>
-	</div>
-	</div>
-	<div class="box-blue-content">
-There is a difference between immediate components and components with a 'validate' 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>
-	<div class="box-blue-footer"></div>
+<div class="alert alert-warning">
+	<strong>Difference between 'validate' and 'immediate'</strong>
+	<br/>
+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>
 
 
 ## Creating instances from an external component type
 
-In the previous section we have declared a customer component type, which does not have the "public=false" attribute. This feature allows separate deployment from instance creation. Moreover, we didn't declare instances in the descriptor. 
-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 *vendor.customer.creator\metadata.xml* file):
+In the previous section we have declared a customer component type, which does not have the `public=false` attribute. This feature allows separate deployment from instance creation. Moreover, we didn't declare instances in the descriptor. 
 
+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 *vendor.customer.creator\metadata.xml* file):
 
+    :::xml
     <ipojo>
     <instance component="customer">
     	<property name="name" value="customer-1"/>
@@ -321,18 +316,21 @@ Another metadata file can be used to dec
 
 
 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. 
+
 ## Deploying the application
 Compile the bundles, by launching ant at the root of the tutorial. Then launch Felix is indicated above. 
 Once started, launch the following commands 
-{code:none}
-start file:../vendor.services/output/vendor.services.jar
-start file:../vendor.buns-and-wieners/output/vendor.buns-and-wieners.jar
-start file:../vendor.hotdog/output/vendor.hotdog.jar
-start file:../vendor.customer/output/vendor.customer.jar
-start file:../vendor.customer.creator/output/vendor.customer.creator.jar
 
-    Something like this should appear:
-    {code:none}
+    :::sh
+    start file:../vendor.services/output/vendor.services.jar
+    start file:../vendor.buns-and-wieners/output/vendor.buns-and-wieners.jar
+    start file:../vendor.hotdog/output/vendor.hotdog.jar
+    start file:../vendor.customer/output/vendor.customer.jar
+    start file:../vendor.customer.creator/output/vendor.customer.creator.jar
+
+Something like this should appear:
+
+    :::sh
     Customer customer-1 bought Hotdog from Fenway Park
     Customer customer-2 bought Hotdog from Fenway Park
     Customer customer-3 bought Hotdog from Fenway Park
@@ -343,23 +341,24 @@ start file:../vendor.customer.creator/ou
     Customer customer-8 bought Hotdog from Fenway Park
 
 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.
+
 ## Using the lifecycle controller
 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 *vendor.popcorn* 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).
 
 The following implementation (*src\org\apache\felix\ipojo\example\vendor\popcorn\PopCornVendor.java*) uses a field to control the lifecycle.
 
-{code:java}
-/**
+    :::java
+    /**
      * The corn stock.
      */
-    private int m*corn*stock;
+    private int m_corn_stock;
     
     /**
      * Lifecycle controller.
      * If set to false, the instance becomes invalid. 
      */
-    private boolean m*can*sell = true;
+    private boolean m_can_sell = true;
 
     /**
      * The sell method.
@@ -369,27 +368,24 @@ The following implementation (*src\org\a
      * @return
      * @see org.apache.felix.ipojo.example.vendor.service.Vendor#sell()
      */
-
-
-
-
     public synchronized Product sell() {
-        m*corn*stock--;
-        if (m*corn*stock == 0 && m*can*sell) { // Last pop corn
-            m*can*sell = false;
+        m_corn_stock--;
+        if (m_corn_stock == 0 && m_can_sell) { // Last pop corn
+            m_can_sell = false;
             System.out.println("Stop selling popcorn 
                   ... Run out of stock");
             return new PopCorn();
-        } else if (m*corn*stock > 0) { // Normal case
+        } else if (m_corn_stock > 0) { // Normal case
             return new PopCorn();
         } else { // Cannot serve.
-            return PopCorn.NO*MORE*POPCORN;
+            return PopCorn.NO_MORE_POPCORN;
         }
     }
 
     
-    Once the field is set to "false", the instance is invalidated (the vendor service is no more available). To configure the controller, you can use the following metadata:
-    {code:xml}
+Once the field is set to "false", the instance is invalidated (the vendor service is no more available). To configure the controller, you can use the following metadata:
+
+    :::xml
     <ipojo>
     <component 
         classname="org.apache.felix.ipojo.example.vendor.popcorn.PopCornVendor"
@@ -403,13 +399,15 @@ The following implementation (*src\org\a
 
 The instance can be re-validated by setting the field to true.
 So, no deploy the pop corn vendor.
-{code:none}
--> start file:../vendor.popcorn/output/vendor.popcorn.jar
-Customer customer-10 bought popcorn from D & P
-Customer customer-9 bought popcorn from D & P
 
-    Our two last customers are no more hungry. However, new customers arrives, we have the following situation:
-    {code:none}
+    :::sh
+    -> start file:../vendor.popcorn/output/vendor.popcorn.jar
+    Customer customer-10 bought popcorn from D & P
+    Customer customer-9 bought popcorn from D & P
+
+Our two last customers are no more hungry. However, new customers arrives, we have the following situation:
+
+    :::sh
     -> update 10
     Customer customer-1 bought popcorn from D & P
     Customer customer-2 bought popcorn from D & P
@@ -417,26 +415,29 @@ Customer customer-9 bought popcorn from 
     Customer customer-3 bought popcorn from D & 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!
+
 ## Reconfiguring an instance
 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:
-{code:java}
-/**
-     * A transporter refills the stock of corn.
-     * This method is synchronized to avoid to client being served 
-     * during the update.
-     * @param newStock : the stock of corn to add to the current stock.
-     */
-    public synchronized void refillStock(int newStock) {
-        m*corn*stock += newStock;
-        System.out.println("Refill the stock : " + m*corn*stock);
-        if (m*corn*stock > 0) {
-            m*can*sell = true;
+
+    :::java
+    /**
+         * A transporter refills the stock of corn.
+         * This method is synchronized to avoid to client being served 
+         * during the update.
+         * @param newStock : the stock of corn to add to the current stock.
+         */
+        public synchronized void refillStock(int newStock) {
+            m_corn_stock += newStock;
+            System.out.println("Refill the stock : " + m_corn_stock);
+            if (m_corn_stock > 0) {
+                m_can_sell = true;
+            }
         }
-    }
 
-    Once added, we need to update the component type descriptor to use this method:
-    {code:xml}
+Once added, we need to update the component type descriptor to use this method:
+
+    :::xml
     <ipojo>
     <component 
         classname="org.apache.felix.ipojo.example.vendor.popcorn.PopCornVendor" 
@@ -456,42 +457,46 @@ First, we will change the pop corn vendo
 We add two different things. First we add a "stock" property attached to the *refillStock* method. When this instance is configured or reconfigured, this method is called to push the new stock value. Then we add the *managed.service.pid* property inside the instance creation. This property will be used by the Configuration Admin to attach configuration to instances. The property value must be unique.
 So now, our popcorn vendor can be reconfigured dynamically to get increments its corn stock.
 However, we need to create something refilling the stock ... a corn transporter !
+
 Inside the *vendor.corn.transporter* project, we have a component dealing with the ConfigurationAdmin to push the new pop corn vendor configuration.
 The implementation is contained in the *src\org\apache\felix\ipojo\example\vendor\corn\transporter\CornTransporter.java* file.
-{code:java}
-public class CornTransporter {
-    
-    private ConfigurationAdmin m_configAdmin;
-    
-    
-    /**
-     * Reconfigure the popcorn vendor with the configuration admin. 
-     */
-    public void refillStock() {
-        try {
-            // Retrieve or Create the instance configuration
-            // from the configuration admin
-            Configuration configuration = 
-                 m_configAdmin.getConfiguration("Super.PopCorn.Stock", 
-                 "file:../vendor.popcorn/output/vendor.popcorn.jar");
-            configuration.setBundleLocation(
-                 "file:../vendor.popcorn/output/vendor.popcorn.jar");
-            Properties props = new Properties();
-            props.put("stock", new Integer(15)); // Delivered corn
-            configuration.update(props);
-            System.out.println("Update the configuration of " 
-                  + configuration.getPid() + "(" 
-                  + configuration.getBundleLocation() + ")");
-            configuration.delete();
-        } catch (IOException e) {
-            e.printStackTrace();
+
+    :::java
+    public class CornTransporter {
+        
+        private ConfigurationAdmin m_configAdmin;
+        
+        
+        /**
+         * Reconfigure the popcorn vendor with the configuration admin. 
+         */
+        public void refillStock() {
+            try {
+                // Retrieve or Create the instance configuration
+                // from the configuration admin
+                Configuration configuration = 
+                     m_configAdmin.getConfiguration("Super.PopCorn.Stock", 
+                     "file:../vendor.popcorn/output/vendor.popcorn.jar");
+                configuration.setBundleLocation(
+                     "file:../vendor.popcorn/output/vendor.popcorn.jar");
+                Properties props = new Properties();
+                props.put("stock", new Integer(15)); // Delivered corn
+                configuration.update(props);
+                System.out.println("Update the configuration of " 
+                      + configuration.getPid() + "(" 
+                      + configuration.getBundleLocation() + ")");
+                configuration.delete();
+            } catch (IOException e) {
+                e.printStackTrace();
+            }
         }
     }
-}
 
-    Create a new configuration from the configuration admin and configure this configuration to add corn. Then, we update this configuration. This will reconfigured our popcorn vendor. More information on the Configuration Admin is available in the OSGi R4 Compendium.
-    So, now if we deploy this bundle, we will provide enough corn to feed all the customers:
-    {code:none}
+Create a new configuration from the configuration admin and configure this configuration to add corn. Then, we update this configuration. This will reconfigured our popcorn vendor. More information on the Configuration Admin is available in the OSGi R4 Compendium.
+
+So, now if we deploy this bundle, we will provide enough corn to feed all the customers:
+
+    :::sh
     -> start file:../vendor.corn.transporter/output/vendor.corn.transporter.jar
     Update configuration of Super.PopCorn.Stock(
            file:../vendor.popcorn/output/vendor.popcorn.jar)
@@ -507,7 +512,7 @@ public class CornTransporter {
 That's it!
 
 ## Conclusion
-This small tutorial has presented some of of the iPOJO features. Subscribe to the Felix users mailing list by sending a message to [mailto:users-subscribe@felix.apache.org]({{ refs.mailto-users-subscribe-felix-apache-org.path }}); after subscribing, email questions or feedback to [mailto:users@felix.apache.org].
+This small tutorial has presented some of of the iPOJO features. Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org](mailto:users-subscribe@felix.apache.org); after subscribing, email questions or feedback to [users@felix.apache.org](mailto:users@felix.apache.org).
   
   
   

Modified: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext?rev=1443557&r1=1443556&r2=1443557&view=diff
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext (original)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext Thu Feb  7 15:34:03 2013
@@ -6,16 +6,17 @@ Title: iPOJO Composition Tutorial
 # iPOJO Composition Tutorial
 *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.*
 
-{div:class=toc}
 [TOC]
-{div}
+
 
 ## Why providing a composition layer?
 iPOJO aims to simplify the creation of OSGi (dynamic) applications. Creating such as applications is basically a two steps process:
+
 * Developing services and components
 * Assembling them together to create the application
 
 To tackle the first step, iPOJO provides an easy-to-use development model. But, this does not help to design the application. To conduct the second step, iPOJO provides a composition language allowing to:
+
 * Assemble components and services together
 * Assert service isolation inside a composition
 * Hide/Abstract implementations 
@@ -26,6 +27,7 @@ However, it is also possible to import a
 
 ## The different types of composition in the OSGi world
 Basically there is two types of composition in OSGi:
+
 * The intra-bundle composition
 * The service-based composition
 
@@ -34,24 +36,29 @@ The intra-bundle composition is the poli
 
 ### Service-based composition
 There are two types of service composition. The behavioral service composition is like [BPEL](http://www.ibm.com/developerworks/library/specification/ws-bpel/) for the web services. An orchestrator supervises the execution and the collaboration of services like:
+
 1. Call service A
 1. Call service B 
 1. ...
 
 The second type of service composition is the structural service composition. This aims to provide a kind of Architecture Description Language for service-based applications. iPOJO follows this trend. This way as several advantages:
+
 * Avoids coupling a composition to specific implementation, and so it supports the dynamic substitution
 * Allows the evolution of used services and components at runtime
+
 This is also the way followed by [SCA](http://www.ibm.com/developerworks/library/specification/ws-sca/). However, SCA does not specify how the dynamism should be handled.
 
 ## The iPOJO composition theory for the dummies
 The distinction between component types and instances
 When you declare a `<component>` (or a `<composite>`) 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 [Factory]({{ refs.how-to-use-ipojo-factories.path }}) 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. 
-The service context concept
+
+## The service context concept
 The service context is the concept allowing service isolation. OSGi bundle context allows accessing both to bundle-based functionality (like `loadClass`) 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. 
 
 ## Downloads
 Download the [archive](http://people.apache.org/~clement/ipojo/tutorials/composite/composite-tutorial.zip). This archive contains:
+
 * The different applications and component types implemented in this tutorial
 * A preconfigured version of Felix
 * Deployment scripts
@@ -59,19 +66,27 @@ Download the [archive](http://people.apa
 Launch `ant` 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 `script.txt` file (in the felix folder) in the Felix shell.
 
 ## Let's start with a first composition
+
 In the [iPOJO in 10 minutes]({{ refs.ipojo-in-10-minutes.path }}) 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:
+
 * The dictionary service implementation, containing words
 * The Check service implementation, providing methods to check words against dictionaries
 * And the client GUI, using a Check Service to indicate misspelled words.
 
 We will reuse the same implementation than in the previous tutorial. The current application is designed as follow:
-!app1.png!
+
+<img src="app1.png">
+
 However, imagine that you want to isolate services provided and required by your application. For example, you want to isolate a stateful service or a critical (private) resource. 
+
 So, let's imagine a second version of our spellchecker application. In this application, the dictionary service, and the checker service are isolated inside a composite. So, those services will be accessible only from instances living in the composite. The GUI will also be instantiated inside the composite. The composition will be something like:
-!app2.png!
-The descriptor of this application is:
 
+<img src="app2.png">
+
+The descriptor of this application is:
+    
+    :::xml
     <ipojo>
     
     <!--  Declares a composition -->
@@ -92,55 +107,64 @@ The descriptor of this application is:
     </ipojo>
 
 First, a composite type is declared inside an iPOJO descriptor. A composite contain always a `name` attribute, which is the component type name. Inside the `<composite></composite>`, three instances are declared: the three instances used by our application. Remark that these instances are declared as 'regular' instances. The `component` attribute indicates the component type to use. Instances can be configured as regular iPOJO instances. Finally, an instance of our type is also declared. 
+
 To execute our composition, go in the felix directory and launch the following command:
-{code:none}
-java -jar bin/felix.jar
 
-    This version of Felix starts with the iPOJO framework, the iPOJO Arch command and the composite support. So, we just need to install our component types and the composition.
-    In the Felix prompt, launch the following commands:
-    {code:none}
+    :::sh
+    java -jar bin/felix.jar
+
+This version of Felix starts with the iPOJO framework, the iPOJO Arch command and the composite support. So, we just need to install our component types and the composition.
+
+In the Felix prompt, launch the following commands:
+
+    :::sh
     start file:../spell.services/output/spell.services.jar
     start file:../spell.english/output/spell.english.jar
     start file:../spell.checker/output/spell.checker.jar
     start file:../spell.checker.gui/output/spell.checker.gui.jar
 
 Those commands deploy the component types. Remark that no 'functional'  (i.e. neither Check service, nor Dictionary service) services are provided. Deployed bundles provide only iPOJO Factory services:
-{code:none}
--> inspect s c
-System Bundle (0) provides:
----------------------------
-org.osgi.service.startlevel.StartLevel
-org.osgi.service.packageadmin.PackageAdmin
-Apache Felix Shell Service (1) provides:
-----------------------------------------
-...
-Apache Felix Bundle Repository (3) provides:
---------------------------------------------
-org.osgi.service.obr.RepositoryAdmin
-iPOJO (4) provides:
--------------------
-...
-iPOJO Composite (6) provides:
------------------------------
-...
-spell.english (8) provides:
----------------------------
-org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
-spell.checker (9) provides:
----------------------------
-org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
-spell.checker.gui (10) provides:
--------------------------------
-org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
-
-    Now, when can deploy our composition:
-
-start file:../example1/output/composition1.jar
-
-    Once deployed and started, the fancy GUI appears:
-    !ss.png!
-    Now, you can check that the functional services are not unavailable outside the composite:
-    {code:none}
+
+    :::sh
+    -> inspect s c
+    System Bundle (0) provides:
+    ---------------------------
+    org.osgi.service.startlevel.StartLevel
+    org.osgi.service.packageadmin.PackageAdmin
+    Apache Felix Shell Service (1) provides:
+    ----------------------------------------
+    ...
+    Apache Felix Bundle Repository (3) provides:
+    --------------------------------------------
+    org.osgi.service.obr.RepositoryAdmin
+    iPOJO (4) provides:
+    -------------------
+    ...
+    iPOJO Composite (6) provides:
+    -----------------------------
+    ...
+    spell.english (8) provides:
+    ---------------------------
+    org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
+    spell.checker (9) provides:
+    ---------------------------
+    org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
+    spell.checker.gui (10) provides:
+    -------------------------------
+    org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
+
+Now, when can deploy our composition:
+
+    :::sh
+    start file:../example1/output/composition1.jar
+
+Once deployed and started, the fancy GUI appears:
+
+<img src="ss-comp.png">
+
+Now, you can check that the functional services are not unavailable outside the composite:
+
+    :::sh
     -> inspect s c
     System Bundle (0) provides:
     ---------------------------
@@ -173,6 +197,7 @@ start file:../example1/output/compositio
 
 Of course, if you stop a bundle providing a required service type, the application is stopped:
 
+    :::sh
     -> stop 8
     -> start 8
 
@@ -180,8 +205,10 @@ Then, the application also supports comp
 
 ## Importing a service inside a composite
 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. 
+
 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:
 
+    :::xml
     <ipojo>
     
     <!--  Declares a composition -->
@@ -206,9 +233,12 @@ If we use this implementation, we need t
     </ipojo>
 
 This composite just adds a `subservice` nested element. This subservice allows importing a service inside the composite. The `action` attribute specifies that we want to import the service from the parent scope (i.e. superior).   The `specification` attribute indicates the required service. 
-!app3.png!
+
+<img src="app3.png">
+
 Now, relaunch Felix and enter another profile name (`composition2` for example). Once started, executes the following commands:
 
+    :::sh
     start file:../spell.services/output/spell.services.jar
     start file:../spell.english/output/spell.english.jar
     start file:../spell.checker-v2/output/spell.checker-v2.jar
@@ -216,35 +246,34 @@ Now, relaunch Felix and enter another pr
     start file:../example2/output/composition2.jar
 
 Those commands deploy required component type (note that we deploy spell.checker-v2) and an implementation of the OSGi Log Service.  When you execute the last command, the fancy interface re-appears. 
+
 Try to enter a wrong word (as `composite`), and click on the check button. The trace does no more appear... the message is logged inside the log service. 
 Of course, such composite support dynamism. Try the following scenario
 
+    :::sh
     stop 9
     start 9
     stop 10
     start 10
 
 When the log service is stopped, the GUI disappears. In fact, the service can no more be imported, and so, the composition becomes invalid. When you stop a bundle containing a used component type, the same behavior occurs.
+
 Like in the previous example, you can check that only the log service is globally available. Other services are isolated inside the composite.
 In this case the parent scope is the OSGi service registry, but composite can also contain other composite. In such context, the import tracks services from the superior composite. An example of hierarchical composition is described later in this tutorial.
 
-<div class="box">
-	<div class="box-blue-header">
-	<div class="box-blue-title">
-		<img src="http://people.apache.org/~clement/ipojo/site/information.gif"> <b>Service Resolution</b>
-	</div>
-	</div>
-	<div class="box-blue-content">
+<div class="alert aert-success">
+	<strong>Service Resolution</strong>
+	<p>
 To tackle implementation service dependency resolution issues, iPOJO instances track services inside the composite but also in the global service context (OSGi service registry).  This feature allows avoiding the declaration of common service import published in the OSGi service registry.
-	</div>
-	<div class="box-blue-footer"></div>
+	</p>
 </div>
 
-
 ## Abstracting implementation... Composing services
 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.
+
 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. 
 
+    :::xml
     <ipojo>
     
     <!--  Declares a composition -->
@@ -268,9 +297,12 @@ In the first composition, we create an i
 
 The previous composition instantiates a dictionary service.  This means that the composite looks for an implementation of the Dictionary service and creates an instance of this implementation (i.e. component type) inside the composition. 
 If several implementations are available, the composite chooses one, and switches to another one if the used implementation becomes unavailable.
-!app4.png!
-To execute this composition, launch Felix and execute the following command:
 
+<img src="app4.png">
+
+To execute this composition, launch Felix and execute the following command:
+    
+    :::sh
     start file:../spell.services/output/spell.services.jar
     start file:../spell.english/output/spell.english.jar
     start file:../spell.checker/output/spell.checker.jar
@@ -279,6 +311,7 @@ To execute this composition, launch Feli
 
 These commands deploy component types and the composition. Only one implementation of the dictionary service is available (English). You can check this by executing the `service 8` command.
 
+    :::sh
     -> inspect s c 9
     spell.english (9) provides:
     ---------------------------
@@ -296,22 +329,26 @@ These commands deploy component types an
 Note the `component.providedServiceSpecifications` property indicating provided services. 
 Now deploy another implementation of the dictionary service, such as the French dictionary service ☺
 
+    :::sh
     start file:../spell.french/output/spell.french.jar
 
 Write  `welcome` in the GUI and then check. The word is correctly spelled. Then, stop the bundle providing the English dictionary.
 
+    :::sh
     stop 9
 
 Write `welcome` in the GUI, and check. The word is misspelled! Try to write `bienvenue` 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.
 
 ## Publishing services
 A composition can also provide services. iPOJO composites support two methods to provide services :
+
 * The service export: re-export a service from the composite to the parent context
 * The service implementation: the composite computes a delegation scheme to delegate every method of the provided service on internal entities (services and instances)
 
 This section addresses the export. Exporting a service is the opposite of the service import. It tracks services from the composites to publish it in the parent (superior) context.
 So, let's imagine a fourth version of our application. In this application, the GUI is externalized and lives in the global context (i.e. OSGi). So, the composition exports the spell checker service. 
 
+    :::xml
     <ipojo>
     
     <!--  Declares a composition -->
@@ -337,10 +374,13 @@ So, let's imagine a fourth version of ou
     </ipojo>
 
 In the previous composition, the composite exports the spell checker service. Moreover, the GUI is also created but in the global context. At runtime, the result will be as following:
-!app5.png!
+
+<img src="app5.png">
+
 The composite published the spell checker service in the OSGi service registry. The GUI tracks this service in the OSGi service registry too.
 To execute this composition, launch Felix and execute following the commands:
 
+    :::sh
     start file:../spell.services/output/spell.services.jar
     start file:../spell.english/output/spell.english.jar
     start file:../spell.checker/output/spell.checker.jar
@@ -349,6 +389,7 @@ To execute this composition, launch Feli
 
 You can check that the composition exports the service with the following command:
 
+    :::sh
     -> services 12
     Bundle 12 provides:
     -------------------
@@ -369,6 +410,7 @@ You can check that the composition expor
 
 So, now you can play with dynamism. Stop the bundle containing the Check service implementation. The GUI disappears. Restart it. The GUI reappears. Now, stop the bundle containing the GUI implementation. The checker service stills available. Indeed, the GUI is no more inside the composition, and so stills valid despite the unavailability of the GUI:
 
+    :::sh
     -> stop 9
     -> start 9
     -> stop 11
@@ -394,6 +436,7 @@ So, now you can play with dynamism. Stop
 ## Hierarchical composites
 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.
 
+    :::xml
     <ipojo>
     
     <!--  Declares the same composition than the latest one -->
@@ -430,9 +473,12 @@ A composition can also contain others co
     </ipojo>
 
 The `composition5` contains an instance of the `composition4` and of the GUI. So the spell checker service exported by the composition4 is published inside the service context of the `composite 5` (the parent context). The GUI instance lives in this service context, and so can access to the exported Spell checker service.
-!app6.png!
+
+<img src="app6.png">
+
 To execute this composition, restart Felix and launch the following commands:
 
+    :::sh
     start file:../spell.services/output/spell.services.jar
     start file:../spell.english/output/spell.english.jar
     start file:../spell.checker/output/spell.checker.jar
@@ -444,12 +490,13 @@ You can check that the composite does no
 ## Conclusion
 
 This page has presented how to use iPOJO composition model. Several topics were not addressed and will be added shortly:
+
 * Dynamic service implementation
 * The dependency model
 * *Composable* services and composition consistency
 * Context-awareness
 
-Subscribe to the Felix users mailing list by sending a message to [mailto:users-subscribe@felix.apache.org]({{ refs.mailto-users-subscribe-felix-apache-org.path }}); after subscribing, email questions or feedback to [mailto:users@felix.apache.org].
+Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org](mailto:users-subscribe@felix.apache.org); after subscribing, email questions or feedback to [users@felix.apache.org](mailto:users@felix.apache.org).
   
   
   

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss-comp.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss-comp.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss-comp.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/vendor.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/vendor.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/vendor.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/wsdl.png
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/wsdl.png?rev=1443557&view=auto
==============================================================================
Binary file - no diff available.

Propchange: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/wsdl.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream



Mime
View raw message