You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@felix.apache.org by fm...@apache.org on 2012/12/14 15:30:22 UTC
svn commit: r1421893 [14/24] - in /felix/site/trunk/content: ./
documentation/ documentation/community/ documentation/development/
documentation/faqs/ documentation/subprojects/
documentation/subprojects/apache-felix-commons/ documentation/subprojects/...
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,722 @@
+Title: iPOJO-Reference-Card
+
+{include:apache-felix-ipojo-header}
+
+<div class="content">
+
+# Declaring component types
+{code:xml|title=XML}
+<component
+ classname="my.Implementation"
+ name="my-type">
+</component>
+
+ {code:java|title=Annotations}
+ @Component(name="my-type")
+ public class Implementation {
+ // ...
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| classname | yes | | indicates the implementation class (automatic when using annotations). |
+| name | no | implementation class name | specifies the component type name. |
+
+
+
+
+{center}
+{div}
+* [How-to use iPOJO factories]({{ refs.how-to-use-ipojo-factories.path }})
+
+# Creating component instances
+{code:xml|title=XML}
+<instance component="my-type"/>
+<instance component="my.Implementation"/>
+<instance component="my-type" name="my-instance"/>
+<instance component="my-type" name="my-instance">
+ <property name="property1" value="value1"/>
+</instance>
+
+ {div:class=borderedTable}
+ {center}
+ ||Attribute name || Required || Default value || ||
+ | component | yes | | specifies the component type (either by using the name or the class name) |
+ | name | no | generated | specifies the instance name. |
+ {center}
+ {div}
+ * Instances can contains a configuration given under the {{key-value}} form. Properties can also by complex type.
+ * [How-to use iPOJO factories]
+
+ {code:java|title=Annotations}
+ @Component(name="my-type")
+ @Instantiate
+ public class Implementation {
+ // ...
+ }
+
+
+# Providing services
+{code:xml|title=XML}
+<component classname="my.service.implementation" name="my-service-impl">
+ <provides/>
+</component>
+<instance name="my-service-impl"/>
+
+ {code:java|title=Annotations}
+ @Component
+ @Provides
+ public class Implementation implements FooService {
+ ...
+ }
+
+* Only instances provides really services, so don't forget to declare an instance.
+* Published service interfaces must be implemented by your component implementation
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| specifications | no | all implemented interfaces | specifies the published service interfaces |
+| strategy | no | `singleton` | specifies the service object creation policy among `singleton`, `service` (OSGi Service Factory), `method` (use the factory method), `instance` (an object per instance) |
+{center}
+{div}
+* [Providing OSGi services]({{ refs.providing-osgi-services.path }})
+
+# Publishing service properties
+
+{code:xml|title=XML}
+<component classname="my.service.implementation" name="my-service-impl">
+ <provides>
+ <property name="foo" field="m_foo" />
+ <property name="bar" field="m_bar" mandatory="true" />
+ <property name="baz" type="java.lang.String" /> <!-- Static property (do not change at runtime) -->
+ </provides>
+</component>
+<instance name="my-service-impl"> <!-- The configuration has to inject value in unvalued mandatory properties -->
+ <property name="bar" value="5"/>
+ <property name="baz" value="my string"/>
+<instance/>
+
+ {code:java|title=Annotations}
+ @Component
+ @Provides(specifications= {FooService.class, BarService.class},
+ properties= {
+ @StaticServiceProperty(name="baz", type="java.lang.String")})
+ public class ProvidesProperties implements FooService, BarService {
+
+ @ServiceProperty(name = "foo")
+ public int m_foo = 0;
+
+ @ServiceProperty(name="bar", mandatory=true)
+ public int m_bar;
+
+ // ...
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| name | no | field name | specifies the published property name |
+| mandatory | no | false | specifies if the property has to receive a value from the instance configuration |
+| value | no | | specifies the default property value |
+| field | no | (automatic with annotations) | specifies the field attached to the service property |
+| type | Only if there is no field (generated) | Type of the property |
+
+{center}
+{div}
+* [Providing OSGi services]({{ refs.providing-osgi-services.path }})
+
+# Using services with field injection
+{code:xml|title=XML}
+<component classname="my.consumer.Implementation">
+ <requires field="fs" />
+ <requires field="bs" />
+</component>
+
+ {code:java|title=Annotations}
+ @Component
+ public class Dependency {
+
+ @Requires
+ public FooService fs;
+
+ @Requires
+ public BarService[] bs;
+
+ //...
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| id | no | field name | dependency id |
+| field | no | automatically detected with annotations | injected field |
+| optional | no | false | specifies if the dependency if optional |
+
+
+| specification | yes/no | can be discovered from the code | specifies the required service specification. This attribute is required when the service type cannot be inferred from the code (Collection type for fields, callbacks without service objects) |
+| filter | no | no filter | specifies the dependency LDAP filter |
+| from | no | | specifies a specific provider by its name |
+| policy | no | `dynamic` | specifies the binding policy among `dynamic`, `static` and `dynamic-priority` |
+| nullable | no | true | enables/disables nullable object injection for optional dependencies |
+| default-implementation // defaultimplementation for annotations | no | | specifies the default-implementation for optional dependencies |
+| comparator | no | | specifies the comparator class used to sort service providers |
+{center}
+{div}
+* [Service Requirement Handler]({{ refs.service-requirement-handler.path }})
+
+# Using services with method injection
+{code:xml|title=XML}
+<component classname="my.consumer.Implementation">
+ <requires>
+ <callback type="bind" method="bind" />
+ <callback type="unbind" method="unbind" />
+ <callback type="modified" method="modified" /> <!-- for filtered service dependencies, to be notified when a service is modified but still match -->
+ </requires>
+</component>
+
+ {code:java|title=Annotations}
+ @Component
+ public class Dependency {
+
+ @Unbind
+ public synchronized void unbindBaz(BazService bz) {
+ //...
+ }
+
+ @Bind
+ public synchronized void bindBaz(BazService bz) {
+ // ...
+ }
+
+ @Modified
+ public synchronized void modifiedBaz() {
+ // ...
+ }
+
+ //...
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| id | no | field name | dependency id |
+| field | no | automatically detected with annotations | injected field |
+| optional | no | false | specifies if the dependency if optional |
+
+
+| specification | yes/no | can be discovered from the code | specifies the required service specification. This attribute is required when the service type cannot be infered from the code (Collection type for fields, callbacks without service objects) |
+| filter | no | no filter | specifies the dependency LDAP filter |
+| from | no | | specifies a specific provider by its name |
+| policy | no | `dynamic` | specifies the binding policy among `dynamic`, `static` and `dynamic-priority` |
+| nullable | no | true | enables/disables nullable object injection for optional dependencies |
+| default-implementation // default implementation for annotations | no | | specifies the default-implementation for optional dependencies |
+| comparator | no | | specifies the comparator class used to sort service providers |
+
+| Sub-Element name | Required | Default value | |
+|--|--|--|--|
+| callback | no | callback specifies bind and unbind method. Two attributes are required (discovered automatically with annotations). `type` specified if the callback is a bind or unbind method (among \`{bind`, `unbind`, `modified`\}. The `method` attribute specified the method to call. The `modified` callback is called when the service properties of a bound service are modified and the service still match the filter.
+{center}
+{div}
+* [Service Requirement Handler]({{ refs.service-requirement-handler.path }})
+
+# Configuring service dependencies in the instance configuration
+ h2. Configuring the `from` attribute
+* Thanks to the `requires.from` property, it is possible to override the `from` attribute value.
+
+{code:xml|From attribute configuration}
+<component
+ classname="...MyComponent"
+ name="FOO">
+ <requires field="m_foo" id="id1">
+ <callback type="bind" method="bind"/>
+ <callback type="unbind" method="unbind"/>
+ </requires>
+</component>
+
+<instance name="FOO1" component="FOO"/> <!-- Use the default 'from' value -->
+
+<instance name="FOO2" component="FOO">
+ <property name="requires.from">
+ <property name="id1" value="myprovider"/>
+ </property>
+</instance>
+
+ h2. Configuring the {{filter}} attribute
+ * Thanks to the {{requires.filters}} property, it is possible to override the {{filter}} attribute value.
+
+ {code:xml|Filter attribute configuration}
+ <component
+ classname="org.apache.felix.ipojo.example.FilteredDependency"
+ name="FOO">
+ <requires field="m_foo" fiter="(foo.property=FOO)" id="id1">
+ <callback type="bind" method="bind"/>
+ <callback type="unbind" method="unbind"/>
+ </requires>
+ </component>
+
+ <instance name="FOO1" component="FOO"/> <!-- Use the default 'filter' value -->
+
+ <instance name="FOO2" component="FOO">
+ <property name="requires.filters">
+ <property name="id1" value="(foo.property=BAR)"/>
+ </property>
+ </instance>
+
+
+# Reacting to lifecycle state changes
+## Immediate components
+* A POJO object (implementation object) is created as soons as the instance becomes valid
+* Instances that don't provide services becomes automatically immediate
+{code:xml|title=XML}
+<component classname="my.service.implementation" name="my-service-impl" immediate="true">
+ <provides/>
+</component>
+
+ {code:java|title=Annotations}
+ @Component(immediate=true)
+ @Provides
+ public class Implementation implements FooService {
+ ...
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| immediate | no | false // true for instances that don't provide a service | specifies if the instance is immediate or not |
+{center}
+{div}
+* [Lifecycle Callback Handler]({{ refs.lifecycle-callback-handler.path }})
+
+## Lifecycle callbacks
+{code:xml|title=XML}
+<component classname="my.implementation" name="my-impl">
+ <callback transition="validate" method="start" />
+ <callback transition="invalidate" method="stop" />
+</component>
+
+ {code:java|title=Annotations}
+ @Component
+ public class Implementation {
+
+ @Validate
+ public void start() {
+
+ }
+
+ @Invalidate
+ public void stop() {
+
+ }
+ }
+
+* [Lifecycle Callback Handler]({{ refs.lifecycle-callback-handler.path }})
+
+# Declaring properties
+{code:xml|title=XML}
+<component classname="my.Implementation" name="my-impl">
+ <properties propagation="true" managedservice="MyPID">
+ <property name="boo" method="setBoo" />
+ <property field="m_bar" mandatory="true"/>
+ <property field="m_foo" value="4"/>
+ </properties>
+</component>
+<instance component="my-impl">
+ <property name="boo" value="..."/>
+ <property name="m_bar" value="..."/>
+</instance>
+<instance component="my-impl">
+ <property name="boo" value="..."/>
+ <property name="m_bar" value="..."/>
+ <property name="managed.service.pid" value="AnotherPID"/>
+</instance>
+
+ {code:java|title=Annotations}
+ @Component(managedservice="MyPID", propagation=true)
+ public class Implementation {
+
+ @Property(name="boo")
+ public void setBoo(int boo) {
+ //...
+ }
+
+ @Property(mandatory=true)
+ public int m_bar;
+
+ @Property(value="4")
+ public int m_foo;
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| propagation | no | false | specifies if the properties propagation (properties are also published as service properties) is enabled or disabled |
+| managedservice | no | instance name | specifies the PID of the published managed service. // This value can be overidden by the `managed.service.pid` instance property |
+| name | no | field name or computed from the method name | specifies if the the property name |
+| value | no | | specifies the default property value |
+| field | no | automatically detected with annotations | specifies the field in which the property value will be injected |
+| method | no | automatically detected with annotations | specifies the setter method in which the property value will be injected |
+| mandatory | no | false | specifies if the property has to receive a value from the instance configuration |
+{center}
+{div}
+* [Configuration Handler]({{ refs.configuration-handler.path }})
+
+# PostRegistration and PostUnregistration callbacks
+* This feature is part of the provided service handler, and so requires that the component provides a service.
+* The callback receives a `ServiceReference` as parameter.
+{code:xml|title=XML}
+<component
+ classname="...">
+ <provides
+ post-unregistration="unregistered" post-registration="registered"/>
+</component>
+
+ {code:java|title=Annotations}
+ @PostRegistration
+ public void registered(ServiceReference ref) {
+ System.out.println("Registered");
+ }
+
+ @PostUnregistration
+ public void unregistered(ServiceReference ref) {
+ System.out.println("Unregistered");
+ }
+
+* [Provided Service Handler](http://felix.apache.org/site/providing-osgi-services.html#ProvidingOSGiservices-Beingnotifiedoftheserviceregistrationandunregistration)
+
+# Controlling service publication
+* This feature is part of the provided service handler, and so requires that the component provides a service.
+* It allows a component to force the un-publication of a service.
+{code:xml|title=XML}
+<component
+ classname="...">
+ <provides>
+ <controller field="controller" value="false"/>
+ </provides>
+</component>
+
+ {code:java|title=Annotations}
+ @ServiceController(value="false")
+ private boolean controller
+
+* [Provided Service Handler](http://felix.apache.org/site/providing-osgi-services.html)
+
+
+# Using 'arch'
+* Deploy the 'arch' command bundle (available for Felix and Equinox)
+* Launch the 'arch' command in the OSGi Framework Shell
+{code:java|title=Felix Shell}
+arch => displays instances name & state (equivalent to arch \-instances)
+arch -instance $instance*name => displays complete information about the instance $instance*name
+arch -factories => display the list of available factories
+arch -factory $factory*name => display complete information about the factory $factory*name
+arch -handlers => list available handlers
+
+ {code:java|title=Felix Gogo}
+ ipojo:instances => displays instances name & state (equivalent to arch \-instances)
+ ipojo:instance $instance_name => displays complete information about the instance $instance_name
+ ipojo:factories => display the list of available factories
+ ipojo:factory $factory_name => display complete information about the factory $factory_name
+ ipojo:handlers => list available handlers
+
+
+* [iPOJO Arch Command]({{ refs.ipojo-arch-command.path }})
+* [Architecture Handler]({{ refs.architecture-handler.path }})
+
+# Temporal Dependencies
+ * Temporal dependencies are injected in fields. When accessing to the service, the thread waits for the service availability. If a timeout is reached, a timeout policy is executed.
+ * Service objects can be injected as `proxies` and be given to collaborator objects.
+* Temporal dependencies are implemented as an *external handlers*. To use them, deploy and start the temporal dependency handler bundle.
+
+{code:xml|title=XML}
+<iPOJO xmlns:temporal="org.apache.felix.ipojo.handler.temporal">
+<component
+ className="my.Implementation">
+
+ <!-- Temporal dependency configuration -->
+ <temporal:requires field="mytemporal"/>
+ <provides/>
+</component>
+</iPOJO>
+
+ {code:java|title=Annotations}
+ import org.apache.felix.ipojo.annotations.Component;
+ import org.apache.felix.ipojo.handler.temporal.Requires;
+ import org.apache.felix.ipojo.test.scenarios.annotations.service.FooService;
+
+ @Component
+ public class Implementation {
+
+ @Requires // org.apache.felix.ipojo.handler.temporal.Requires
+ private FooService mytemporal;
+
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| field | no | automatically detected with annotations | specifies the field in which the service object will be injected |
+| timeout | no | 3000 ms | specifies the timeout value (in ms). When the timeout is reached, the on timeout policy is executed |
+| onTimeout | no | Runtime Exception | specifies the on timeout policy. Possible values are: `null`, `nullable`, `empty`, *default-implementation* (class name) |
+| specification | only when using Collections | | specifies the required service specification. This attribute is required when the injected field is a Collection |
+| proxy | no | false | enables/disables proxy injection. Service injected as proxies can be given to collaborators |
+| filter | no | no filter | Filter use to discover matching filter. |
+{center}
+{div}
+* [Temporal Service Dependency]({{ refs.temporal-service-dependency.path }})
+
+
+# Sending and receiving events
+
+## Receiving events
+
+ * The event admin handler allows receiving events from the Event Admin.
+ * The event admin handler is implemented as an *external handlers*. To use it, deploy and start the event admin handler bundle and an implementation of the event admin service.
+ * Event (or data) are receive thanks to a callback method.
+
+{code:xml|title=XML}
+<ipojo
+ xmlns:ev="org.apache.felix.ipojo.handlers.event.EventAdminHandler">
+ <component className="...MyComponent">
+ <ev:subscriber
+ name="mySubscriber"
+ callback="receive"
+ topics="foo"/>
+ </component>
+</ipojo>
+
+ {code:java|title=Annotations}
+ @Component
+ public class MyComponent {
+
+ @Subscriber(name="s1", data_key="data")
+ public void receive1(Object foo) {
+ // Nothing
+ }
+
+ @Subscriber(name="s2", topics="foo,bar", filter="(foo=true)")
+ public void receive2(Event foo) {
+ // Nothing
+ }
+
+
+ @Subscriber(name="s3", topics="foo", data_key="data", data_type="java.lang.String")
+ public void receive3(String foo) {
+ // Nothing
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| name | yes | | specifies the name of the event subscriber, acting as a unique identifier. This name is used to configure event subscription in the instance configuration. |
+
+
+| topics | yes | | specifies the list (comma-separated-list) of the topics that the handler will listen to. Each event sent on a topic present in this list will be sent to the specified callback method. This parameter can be overridden by instances |
+
+
+If you use this attribute, the parameter passed to the callback method is the the value associated to this key, not the whole event. This attribute is generally used with the `data-type` attribute to specify the received object type. If an event is received and it does not contain such a key, it is ignored (with a warning message). |
+
+
+| filter | no | no filter | specifies the event LDAP filter used to filter incoming events before sending them to the callback. The syntax of this field is described in the OSGi EventAdmin Specification. If you don't specify a filter, all events sent on the listened topics will be considered. |
+{center}
+{div}
+* Instance configuration
+ ** event.topics : overrides `topics` attribute
+ ** event.filter : overrides `filter` attribute
+
+{code:xml|title=Instance configuration}
+<instance component="...MyComponent">
+ <property name="event.topics">
+ <property name="mySubscriber" value="foo"/>
+ </property>
+ <property name="event.filter">
+ <property name="mySubscriber"
+ value="|((arg=Minibar)(arg=Coconuts))"/>
+ </property>
+ </instance>
+
+
+ * [Event Admin Handlers]
+
+ h2. Sending events
+
+ * The event admin handler allows sending events to the Event Admin.
+ * The event admin handler is implemented as an _external handlers_. To use it, deploy and start the event admin handler bundle and an implementation of the event admin service.
+ * To send events, your code must contains a {{org.apache.felix.ipojo.handlers.event.publisher.Publisher}} field.
+
+ {code:xml|title=XML}
+ <ipojo
+ xmlns:ev="org.apache.felix.ipojo.handlers.event.EventAdminHandler">
+ <component className="...MyComponent">
+ <ev:publisher
+ name="myPublisher"
+ field="m_publisher"
+ topics="bar,nuts"/>
+ </component>
+ <instance component="...MyComponent"/>
+ </ipojo>
+
+{code:java|title=Annotations}
+
+@Component
+public class MyComponent {
+ // We use qualified names to avoid conflict.
+ @org.apache.felix.ipojo.handlers.event.Publisher(name="p1", synchronous=true)
+ org.apache.felix.ipojo.handlers.event.publisher.Publisher publisher1;
+
+ @org.apache.felix.ipojo.handlers.event.Publisher(name="p2", synchronous=false, topics="foo,bar", data_key="data")
+ org.apache.felix.ipojo.handlers.event.publisher.Publisher publisher2;
+
+ @org.apache.felix.ipojo.handlers.event.Publisher(name="p3", synchronous=true, topics="bar")
+ org.apache.felix.ipojo.handlers.event.publisher.Publisher publisher3;
+
+ // ...
+
+ public void doSomething() {
+ Dictionary e = new Properties();
+ //...
+ // Fill out the event
+
+ // Send event
+ publisher1.send(e);
+ }
+}
+
+
+ * [Event Admin Handlers]
+
+ {div:class=borderedTable}
+ {center}
+ ||Attribute name || Required || Default value || ||
+ | name | yes | | specifies the name of the event publisher, acting as a unique identifier. This name is used to configure event publishing in the instance configuration. |
+ | field | yes \\ automatically detected with annotations | | specifies The name of the field used to send events. The field is initialized at component instantiation time. The type of the field must be : {{org.apache.felix.ipojo.handlers.event.publisher.Publisher}}. |
+ | topics | yes | | specifies the list (comma-separated-list) of the topics on which events will be sent. This parameter can be overridden by instances |
+ | data-key \\ data_key when using annotations | no | user.data | specifies the data key used when you want to send data events. This attribute's value is the key, in the event's dictionary, in which sent data are stored. When you use the _sendData_ method of the Publisher, the given object is placed in the event dictionary, associated with the specified data-key. |
+ | synchronous | no | false | specifies if event sending is synchronous or not. |
+ {center}
+ {div}
+
+ * Instance configuration
+ ** event.topics : overrides {{topics}} attribute
+
+ {code:xml|title=Instance configuration}
+ <instance component="...MyComponent">
+ <property name="event.topics">
+ <property name="myPublisher" value="foo"/>
+ </property>
+ </instance>
+
+
+# Extender Pattern
+ * Allows implementing an `Extender pattern` without handling obscure details
+ * The extender pattern handler is implemented as an *external handlers*. To use it, deploy and start the external pattern handler bundle.
+
+{code:xml|title=XML}
+<ipojo xmlns:extender="org.apache.felix.ipojo.extender">
+ <component
+ classname="org.apache.felix.ipojo.extender.Myextender">
+
+ <!âExtender Pattern handler configuration -->
+ <extender:extender
+ extension="My-Extension"
+ onArrival="onArrival"
+ onDeparture="onDeparture"
+ />
+
+ <callback transition="invalidate" method="stopping" />
+ <callback transition="validate" method="starting" />
+ </component>
+</ipojo>
+
+
+ {code:java|title=Annotations}
+ @Component
+ @org.apache.felix.ipojo.extender.Extender(extension="My-Extension", onArrival="onArrival", onDeparture="onDeparture")
+ public class Myextender {
+
+ public void onArrival(Bundle bundle, String extension) {
+ // handle matching bundle arrival
+ }
+
+ public void onDeparture(Bundle bundle) {
+ // handler matching bundle departure
+ }
+ }
+
+{div:class=borderedTable}
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| extension | yes | | specifies the required extension (i.e. the required Manifest key) |
+| onArrival | yes | | specifies the method called when a matching bundle arrives. The method receives the Bundle object and the extension value |
+| onDeparture | yes | | specifies the method called when a matching bundle leaves. The method receives the Bundle object |
+{center}
+{div}
+* [Extender Pattern Handler]({{ refs.extender-pattern-handler.path }})
+
+
+# Whiteboard Pattern
+ * Allows implementing a `Whiteboard pattern` without handling obscure details
+ * The whiteboard pattern handler is implemented as an *external handlers*. To use it, deploy and start the whiteboard pattern handler bundle.
+
+{code:xml|title=XML}
+<ipojo xmlns:wbp="org.apache.felix.ipojo.whiteboard">
+ <component
+ classname="org.apache.felix.ipojo.test.MyWhiteBoardPattern"
+ >
+ <wbp:wbp
+ filter="(my.property=1)"
+ onArrival="onArrival"
+ onDeparture="onDeparture"
+ onModification="onModification"
+ />
+
+ <provides/>
+ </component>
+
+ {code:java|title=Annotations}
+ @Component
+ @org.apache.felix.ipojo.whiteboard.Wbp(filter="(my.property=1)",
+ onArrival="onArrival",
+ onDeparture="onDeparture",
+ onModification="onModification")
+ public class WhiteBoardWIModification {
+
+ public void onArrival(ServiceReference ref) {
+ // ...
+ }
+
+ public void onDeparture(ServiceReference ref) {
+ // ...
+ }
+
+ public void onModification(ServiceReference ref) {
+ // ...
+ }
+
+ }
+
+
+{center}
+|Attribute name | Required | Default value | |
+|--|--|--|--|
+| filter | yes | | specifies LDAP filter used to detect required service providers |
+| onArrival | yes | | specifies the method called when a matching service provider arrives. The method receives the ServiceReference object |
+| onDeparture | yes | | specifies the method called when a matching service provider leaves. The method receives the ServiceReference object |
+| omModification | no | | specifies the method called when a matching service provider is modified and is still matching. The method receives the ServiceReference object |
+{center}
+* [White Board Pattern Handler]({{ refs.white-board-pattern-handler.path }})
+
+
+
+
+{include:apache-felix-ipojo-footer}
\ No newline at end of file
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-support.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-support.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-support.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-support.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,81 @@
+Title: ipojo-support
+
+{include:apache-felix-ipojo-header}
+
+<div class="content">
+
+# Support
+
+*Two types of support are provided for Apache Felix iPOJO. The community support is free but relies on the availability of iPOJO developers. Professional supports are provided by companies guarantying a fast and efficient feedback.*
+
+
+## Community Support
+
+### Mailing List
+
+iPOJO is hosted as an Apache Felix sub-project, you can ask questions by sending mails to the Felix mailing lists. There is two mailing list:
+* The users mailing list
+* The developer mailing list
+
+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].
+Either, if you want to be involved, subscribe to the Felix dev mailing list by sending a message to [mailto:dev-subscribe@felix.apache.org]({{ refs.mailto-dev-subscribe-felix-apache-org.path }}); after subscribing, email ideas or feedback to [mailto:dev@felix.apache.org].
+
+### Bug Tracker
+
+If you want a features, an improvement or report a bug, feel free to open an issue on the Apache Felix bug tracker:
+* Go to the [https://issues.apache.org/jira/browse/FELIX](https://issues.apache.org/jira/browse/FELIX) page
+* Create an account or log in.
+* Open the 'Create a new issue in project Felix' form.
+* Then, select the Felix project and the issue type (improvement, bug, wish, new feature...)
+* At the second step, select the *iPOJO* component and fill out the form (please select the affected version only)
+* Finally click on the create button
+
+You can also watch the issue to monitor progress. The iPOJO team tries to give you quick and frequent feedback on issues.
+
+## Professional Support
+
+Companies listed below provide professional support (training, mentoring, consulting, development...) for Apache Felix iPOJO.
+
+### akquinet
+
+
+{section}
+{column:width=75%}
+
+<p style="padding:5px; text-align:justify;">
+akquinet AG is a high-performance IT consulting company for standard solutions, customized development, and outsourcing - operating internationally. It has been a long-serving and active participant In the Open Source movement. Taking Java, OSGi, JEE, SAP, and Microsoft as a basis, akquinet advises with respect to processes and industry in the selection, implementation, and optimization of IT solutions. Working agilely, akquinet develops customized software and integrates existing system environments as well as operating customer systems securely and reliably in high-performance computer centers.
+<br/><br/>
+akquinet possesses a lot of experience in OSGi development and in modular applications. akquinet provides support for Apache Felix and Apache Felix iPOJO as well as training, consulting, mentoring and development for modular / OSGi-based applications and mobile solutions. It also provides <a href="http://www.akquinet.de/content/java-sap/mobile-solutions-und-osgi/modular-solutions/osgi-jumppack.html">OSGi Jumpacks</a> to efficiently develop OSGi applications. For more information, visit the <a href="http://www.akquinet.de/content/java-sap/mobile-solutions-und-osgi.html">akquinet web site</a>.
+</p>
+
+{column}
+{column:width=25%}
+!http://www.akquinet.de/fileadmin/img/akquinet*logo*neu_k.JPG|align=center!
+{column}
+{section}
+
+
+
+
+
+
+
+<div class="box">
+ <div class="box-blue-header">
+ <div class="box-blue-title">
+ <img src="http://felix.apache.org/ipojo/site/information.gif"> <b>Want to be listed here ?</b>
+ </div>
+ </div>
+ <div class="box-blue-content">
+If your company also provides professional support for Apache Felix iPOJO, just send a message to [dev@felix.apache.org]({{ refs.mailto-dev-felix-apache-org.path }}) with the company description.
+ </div>
+ <div class="box-blue-footer"></div>
+</div>
+
+
+
+
+
+
+
+{include:apache-felix-ipojo-footer}
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-test-page.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-test-page.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-test-page.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/ipojo-test-page.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,126 @@
+Title: ipojo-test-page
+
+{include:apache-felix-ipojo-header}
+
+<div class="content">
+
+# Title 1
+
+## Title 2
+
+### Title 3
+
+#### Title 4
+
+this is a paragraph bla
+Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+
+{code:java}
+/**
+* A comment
+*/
+@AnAnnotation
+public class MyJavaCode {
+
+public LogService log;
+
+public void doSomething() {
+//...
+}
+}
+
+
+ {code:xml}
+ <!-- This is an xml comment -->
+ <ipojo>
+ <component classname="...MyComponentImpl">
+ <provides/>
+ </component>
+ </ipojo>
+
+
+
+A list :
+* Item 1
+* Item 2
+** Item 2.1
+
+An ordered list
+1. ITem 1
+1. Item 2
+1. # Item 2.1
+
+A TOC :
+{div:class=toc}
+[TOC]
+{div}
+
+[a link](http://perdu.com)
+
+
+A Table:
+|A|B|C
+|--|--|
+|aaa|bbb|ccc|
+
+
+<div class="box">
+ <div class="box-green-header">
+ <div class="box-green-title">
+ <img src="http://people.apache.org/~clement/ipojo/site/check.gif"> <b>My Title</b>
+ </div>
+ </div>
+ <div class="box-green-content">
+ My content<br>
+ Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+ </div>
+ <div class="box-green-footer"></div>
+</div>
+
+
+
+<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>My Title</b>
+ </div>
+ </div>
+ <div class="box-blue-content">
+ My content<br>
+ Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+ </div>
+ <div class="box-blue-footer"></div>
+</div>
+
+
+
+<div class="box">
+ <div class="box-yellow-header">
+ <div class="box-yellow-title">
+ <img src="http://people.apache.org/~clement/ipojo/site/warning.gif"> <b>My Title</b>
+ </div>
+ </div>
+ <div class="box-yellow-content">
+ My content<br>
+ Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+ </div>
+ <div class="box-yellow-footer"></div>
+</div>
+
+
+
+<div class="box">
+ <div class="box-red-header">
+ <div class="box-red-title">
+ <img src="http://people.apache.org/~clement/ipojo/site/forbidden.gif"> <b>My Title</b>
+ </div>
+ </div>
+ <div class="box-red-content">
+ My content<br>
+ Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+ </div>
+ <div class="box-red-footer"></div>
+</div>
+
+
+{include:apache-felix-ipojo-footer}
\ No newline at end of file
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/menu2.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/menu2.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/menu2.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/menu2.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,24 @@
+Title: menu2
+
+
+{style:import=http://cayenne.apache.org/css/master.css}
+
+# Coucou
+
+|aaa|BBB|
+|--|--|
+|aaa|bbb|
+
+## Foo
+
+{panel}
+this is a panel
+{panel}
+
+{code:java}
+public void class Foo {
+}
+
+
+
+
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/related-works.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/related-works.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/related-works.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-ipojo/related-works.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,26 @@
+Title: Related Works
+
+{section}
+{column:width=80%}
+# Presentations
+
+* [Service Blinder](http://www.aqute.biz/resources/2005/2005-10-OSGIWC*Service*Blinder.ppt) : Peter Kriens Presentation about "Removing Cruft" (OSGi World Congress 2005)
+
+
+# Articles
+
+* [Extending OSGi for Java Module Orientation ]({{ refs.-http-www-adele-imag-fr-index-php-option-com_equipemngt-view-publication-cid.path }})=95]
+* [Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model ](http://www-adele.imag.fr/Les.Publications/intConferences/ICSE2004Cer.pdf)
+
+# Web Sites
+
+* [Spring-DM](http://www.springframework.org/osgi)
+* [Service Binder](http://gravity.sourceforge.net/servicebinder/)
+* [Newton](http://newton.codecauldron.org/)
+* [Techne](http://wiki.ops4j.org/confluence/display/ops4j/Techne)
+* [Service Component Architecture](http://www.ibm.com/developerworks/library/specification/ws-sca/)
+{column}
+{column:width=20%}
+{include:apache-felix-ipojo-menu}
+{column}
+{section}
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-lightweight-http-service.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-lightweight-http-service.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-lightweight-http-service.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-lightweight-http-service.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,20 @@
+Title: Apache Felix Lightweight HTTP Service
+
+# Apache Felix Lightweight HTTP Service
+
+[TOC]
+
+This is a *minimal* implementation of the HTTP Service Specification as described in chapter 102 of the OSGi Compendium. The goal is to provide a basic HTTP Service for resource-constrained devices and other use cases where the standard HTTP Service may be overkill. The bundle requires Java 1.4 or above and implements the Servlet 2.4 API.
+
+## Targets
+
+The Apache Felix Lightweight HTTP Service comes in two targets: core and complete. Core provides the minimal server functionality and requires the HTTP Servlet and OSGi HTTP Service APIs to be provided by other bundles at runtime. The complete bundle packages these as well and has no external dependencies. Currently the complete bundle is about 2x the size of core (55Kb vs 98Kb). If space is a concern and the API packages are already provided by other bundles in your environment, the core target makes the most sense. However for easy installation and maintenance, the complete bundle may be the better choice.
+
+## Configuration Properties
+
+The service can only be configured using OSGi environment properties. The service supports a subset of the standard HTTP Service properties:
+
+* `org.osgi.service.http.port` - The port used for servlets and resources available via HTTP. The default is `8080`.
+* `org.apache.felix.http.enable` - Enable or disable the HTTP protocol. The default is enabled.
+* `org.apache.felix.https.enable` - Enable or disable the HTTPS protocol. Currently the lightweight HTTP Service does not support HTTPS, and setting this to true will only result in a log warning.
+* `felix.log.level` - The log level for messages originating from the bundle. The default is 1.
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-log.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-log.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-log.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-log.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,115 @@
+Title: Apache Felix Log
+
+# Apache Felix Log
+
+The OSGi Service Compendium specification defines a general purpose Log Service for the OSGi Platform. It is a very simple specification that doesn't provide all the functionality commonly available in enterprise-level logging tools, but its extensible service model can be used to build fairly sophisticated logging solutions.
+
+The Log Service specification defines four main entities:
+
+* *`org.osgi.service.log.LogService`* - service interface to log information, including log level, message, exception, and `ServiceReference` that generated the log.
+* *`org.osgi.service.log.LogReaderService`* - service interface to add and remove `LogListener` instances and to retrieve recent log entries.
+* *`org.osgi.service.log.LogEntry`* - interface defining a log entry.
+* *`org.osgi.service.log.LogListener`* - interface defining a listener for log entries, which is notified about new log entries.
+
+## Accessing the log service
+
+To access a `LogService` instance it is necessary to look it up in the OSGi service registry as demonstrated in the following code snippet:
+
+
+ public class Activator implements BundleActivator
+ {
+ public void start(BundleContext context) throws Exception
+ {
+ ServiceReference ref = context.getServiceReference(LogService.class.getName());
+ if (ref != null)
+ {
+ LogService log = (LogService) context.getService(ref);
+
+ // Use the log...
+ }
+ }
+
+ //..
+
+
+It is possible, and advisable, to use more sophisticated service acquisition mechanisms like a Service Tracker, Dynamic Services or iPOJO.
+
+## Using the log service
+
+The `LogService` interface provides four methods for logging:
+
+
+ public interface LogService
+ {
+ //..
+
+ // Log a message specifying a log level
+ public log(int level, java.lang.String message)
+
+ // Log an exception
+ public log(int level, java.lang.String message, java.lang.Throwable exception)
+
+ // Log a message specifying the ServiceReference that generated it
+ public log(ServiceReference sr, int level, java.lang.String message)
+
+ // Log a message specifying the ServiceReference and exception
+ public log(ServiceReference sr, int level, java.lang.String message, java.lang.Throwable exception)
+ }
+
+
+Log levels are defined in the same interface:
+
+* `LogService.LOG_DEBUG`
+* `LogService.LOG_INFO`
+* `LogService.LOG_WARNING`
+* `LogService.LOG_ERROR`
+
+## Retrieving log entries
+
+The `LogReaderService` provides a `getLog()` method to retrieve an `Enumeration` of the latest log entries. The following code snippets demonstrates how to retrieve it from the service registry and use it:
+
+
+ ServiceReference ref = context.getServiceReference(LogReaderService.class.getName());
+ if (ref != null)
+ {
+ LogReaderService reader = (LogReaderService) context.getService(ref);
+ Enumeration<LogEntry> latestLogs = reader.getLog();
+ }
+
+
+## Creating and registering a `LogListener`
+
+The Log Service specification doesn't define any particular entity to store, display, or write log entries; it's up to the developer to implement this functionality or to choose an available implementation capable of doing that. To create such a bundle, the first step is to create an implementation of the `LogListener` interface. The following code shows a simple implementation that echoes the log message:
+
+
+ public class LogWriter implements LogListener
+ {
+ // Invoked by the log service implementation for each log entry
+ public void logged(LogEntry entry)
+ {
+ System.out.println(entry.getMessage());
+ }
+ }
+
+
+The only method to implement is `logged()` method, which is called every time a log entry is created in the associated logging service. A `LogListener` implementation must be registered with the `LogReaderService` so it can start receiving log entries, as demonstrated in the following code snippet:
+
+
+ ServiceReference ref = context.getServiceReference(LogReaderService.class.getName());
+ if (ref != null)
+ {
+ LogReaderService reader = (LogReaderService) context.getService(ref);
+ reader.addLogListener(new LogWriter());
+ }
+
+
+
+## Setup of Apache Felix Log Service
+
+The Apache Felix Log Service bundle doesn't have any specific dependency on Felix, so it can run on any OSGi container. For its configuration, it will use the following optional system properties:
+
+|Property|Default|Description|
+|--|--|--|
+|`org.apache.felix.log.maxSize`|100|The maximum size of the log history. A value of -1 means the log has no maximum size; a value of 0 means that no historical information is maintained|
+|`org.apache.felix.log.storeDebug`|false|Determines whether or not debug messages will be stored in the history|
+
Added: felix/site/trunk/content/documentation/subprojects/apache-felix-manifest-generator-mangen.mdtext
URL: http://svn.apache.org/viewvc/felix/site/trunk/content/documentation/subprojects/apache-felix-manifest-generator-mangen.mdtext?rev=1421893&view=auto
==============================================================================
--- felix/site/trunk/content/documentation/subprojects/apache-felix-manifest-generator-mangen.mdtext (added)
+++ felix/site/trunk/content/documentation/subprojects/apache-felix-manifest-generator-mangen.mdtext Fri Dec 14 14:29:22 2012
@@ -0,0 +1,534 @@
+Title: Apache Felix Manifest Generator (mangen)
+
+# `mangen` - [OSGi](http://www.osgi.org) Bundle Manifest generator
+
+# Introduction
+
+The [OSGi](http://www.osgi.org) model provides a very powerful and flexible framework for developing Java applications in a modular fashion with a high degree of control over classloading inter-dependencies between modules. Projects such as [Oscar|http://oscar.objectweb.org/] and [Felix|http://incubator.apache.org/felix/] have recognised this power and implemented open source implementations of the framework. Adding to this is a growing availability of open source application bundles such as those offered via the [Oscar Bundle Repository|http://oscar-osgi.sourceforge.net/] (aka OBR).
+
+As an active developer of OSGi based application, [Ascert's](http://www.ascert.com/) technical staff grappled with the cumbersome task of manually creating OSGi Bundle Manifests. This task is never particularly interesting and only gets bigger and nastier as applications grow in size and the number of bundles present. To alleviate this chore the `mangen` tool has been created, with the following goals:
+
+* Provide automatic scanning of an OSGi bundle JAR to detect references to external classes which require imports and possible export packages
+* Support scanning of multiple bundle JARs in a single pass, including any JAR files within a specified directory tree
+* Detect the majority of common import and export cases and provide manual override mechanisms to include cases that are not detected
+* Provide a simple, extensible, rule based mechansim to allow the required imports and possible exports sets to be refined e.g. removing un-needed packages, automatic resolving to packages in other JARs etc.
+* Provide a simple, extensible, reporting mechanism of actions taken
+* Automatic updating of each bundle JAR's Manifest, including a means to easily switch between either OSGi R3 or R4 compatible Manifest headers
+
+If you're not a Java developer, or you're not sure what OSGi is yet, then this tool is probably not for you!
+
+## Licensing
+
+The `mangen` utility was originally created as a copyrighted © work of Ascert LLC, and released as *OSI Certified Open Source Software* for use under the under the terms of the [Common Public License](http://www.opensource.org/licenses/cpl1.0.php)
+
+To promote wider use and enhancement, Ascert submitted version 1.0.1 of `mangen` to the [Apache Felix](http://incubator.apache.org/felix/) project, where it will be actively developed and maintained by Felix project team. Availability is now under an [Apache 2.0 style license|http://www.apache.org/licenses/LICENSE-2.0]
+
+Included third-party libraries and contributions are copyrighted © works of their respective owners and are provided under the terms of their specified licenses.
+
+# Using `mangen`
+
+## Basic operation
+
+Using mangen is very simple. Unpack the distribution file to an installation directory, change to this directory and type the following command:
+
+
+ java -jar lib/mangen.jar <file-list>
+
+
+*Note: on Windows platforms you will need to use a '\' in place of the '/' file separator*
+
+Where:
+
+* *<file-list>* - is either a list of bundle JARs to be processed or a list of directories, or a mix of both. Each directory will be scanned and all JAR files in the directory, or any sub-directories will be included in the bundle JARs processed.
+
+The basic behaviour of `mangen` is to process the set of bundle JARs supplied and scan the classes within each JAR to build up a set of the possible exports and required imports for each JAR. Where inner jars are defined using the OSGi `Bundle-ClassPath` header the classes in these will also be scanned and the possible exports and required imports will be included in the sets generated for their enclosing JAR.
+
+Two phases of process happen after JAR scanning has completed:
+
+* Rule execution - typically rules will process the sets of imports and exports determined by `mangen` for each JAR, refining them according to the rule types being executed and the specific rule options
+* Report production - typically generating narrative reports on the bundles processed and the rules executed.
+
+Use of the word 'typically' is significant in the above descriptions. A basic set of [rules]({{ refs.-mangenrules.path }}) and [reports|#MangenReports] are included with `mangen` to perform various useful tasks. This set is infinitely extensible, however, and `mangen` places no restriction on the types of tasks that rules and reports can perform.
+
+The exact rules and reports to be run are entirely controlled by user configurable properties as described below. If no properties are supplied `mangen` will simply run, process the specified JAR files and exit.
+
+## Configuring `mangen` with Properties
+
+Properties to control `mangen` behaviour can either be supplied on the command line using the normal `-D` syntax or, for most cases in a `mangen.properties` file. If the same property name is specified in both then the `-D` command line property value will take precedence of the property file value.
+
+
+For added flexibility a simple variable expansion syntax is provided to allow the value of one Property value to be used within another property. Every property value will be scanned for `$\{property-name\`} markers. Where these are found the marker will be replaced with the value of the associated `property-name`.
+
+*Example:*
+
+
+
+ mangen.osgi.level=3
+ ...
+ mangen.rulesets=mangen-rule-R${mangen.osgi.level}-
+
+
+
+### mangen.properties
+
+The `mangen.properties` Property is used to instruct mangen where to find it's properties file. By default, `mangen` will look for a file named `mangen.properties` in the same directory in which `mangen.jar` was installed (i.e. `lib/mangen.properties`). By including a `-Dmangen.properties` setting on the command line a different properties file can be specified.
+
+*Example:*
+
+
+ java -jar lib/mangen.jar -Dmangen.properties=my_mangen.properties my_app.jar
+
+
+### mangen.osgi.level
+
+There are two places in which the `mangen.osgi.level` Property is used:
+
+* internally within `mangen` to determine the correct format of Manifest headers to be processed and generated.
+* as a means to guide which rulesets are executed, using the [variable-expansion syntax]({{ refs.-variableexpansionsyntax.path }})
+
+At present, this Property should be set to a value of '3' or '4' (the default if not specified will be '3');
+
+### mangen.rulesets
+
+Rules are the engine room of `mangen`, providing the basic means for refining the `mangen` detected import and export package sets e.g. removing un-needed or unused exports, supplying package version information, including undetectable package cases such as dynamic classloading.
+
+Rulesets provide a simple means of organising the rules to be executed into groups of rule sets. The rulesets are specified as a list of comma-separated values, each value specifying the ruleset name prefix. The following example shows a ruleset definition for 2 rules:
+
+
+
+ mangen.rulesets=mangen-rule-first- , mangen-rule-final-
+ ...
+ mangen-rule-first-0=...
+ mangen-rule-first-1=...
+ mangen-rule-first-2=...
+ ...
+ mangen-rule-final-0=...
+ mangen-rule-final-1=...
+
+
+
+As shown in the example, `mangen` will take each ruleset name and look for sequentially numbered properties, starting from 0 and finishing when no property name is found. Each rule found will be executed to completion against the processed set of bundle JARs before the next rule property is processed.
+
+Rulesets can be combined with [variable-expansion]({{ refs.-variableexpansionsyntax.path }}) to provide OSGi version dependent rules as shown the following example.
+
+
+
+ mangen.osgi.level=3
+ mangen.rulesets=mangen-rule-R${mangen.osgi.level}-
+ ...
+ mangen-rule-R3-0=...
+ ...
+ mangen-rule-R4-0=...
+
+
+
+Rules themselves are simply specified as a rule type followed by a space separate list of rule specific options e.g.
+
+
+
+ mangen.R4.syspackages=java\\..*
+ ...
+ mangen-rule-basic-0=Ignore imports(${mangen.R4.syspackages})
+ mangen-rule-basic-1=DontImportOwnExports
+
+
+
+See the [Rules]({{ refs.-mangenrules.path }}) section for full details of the currently support rule types.
+
+### mangen-report-
+
+Reports in `mangen` work in a similar fashion to rules but without the ruleset concept. The set of sequentially numbered `mangen-report-` properties will be scanned to determine which reports should be run e.g.
+
+
+
+ mangen-report-0=RuleReport .*
+ mangen-report-1=BundleReport .*
+
+
+
+See the [Reports]({{ refs.-mangenreports.path }}) section for full details of the currently support report types.
+
+### mangen.failonerror
+
+If set `on` will cause `mangen` to exit with a `System.exit()` error status of 3 if any errors occured. Typical usage is to allow an external build tool, such as Ant, detect that there were errors. Additionally, any error messages will also be sent to `stderr` as well as `stdout` if this property is set.
+
+Default is `on`.
+
+### mangen.failonwarning
+
+If set `on` will cause `mangen` to exit with a `System.exit()` error status of 5 if any warnings occured. Typical usage is to allow an external build tool, such as Ant, detect that there were warnings. Additionally, any warning messages will also be sent to `stderr` as well as `stdout` if this property is set.
+
+Default is `off`.
+
+
+## Rules
+
+The Rule concept in `mangen` was adopted to avoid hard-coding the types of post-processing steps that a user would be able to perform on the `mangen` generated set of package imports and exports. The rule syntax is as follows:
+
+
+ <rule-type> <rule-options>
+
+
+Where:
+
+* *<rule-type>* - must be the name of a valid existing rule type, details of which can be found in this section.
+* *<rule-options>* - will be a list of one or more of the standard options and/or rule specific options. The standard options are as follows:
+** `imports()` - a comma seperated list of package patterns, using the JDK regex format. These will be matched against a bundle's own import packages during rule processing, the specific handling undertaken for each match being dependent on the *<rule-type>*. *Note: each pattern must be separated from the next by a comma (,) and the list must not contain any space characters.*
+** `exports()` - a comma seperated list of package patterns, using the JDK regex format. These will be matched against a bundle's own export packages during rule processing, the specific handling undertaken for each match being dependent on the *<rule-type>*.
+** `sys-packages()` - a comma seperated list of standard 'system package' patterns, using the JDK regex format. The specific handling undertaken for each match being dependent on the *<rule-type>*
+
+Rules will can have either "global" scope, in which case every bundle JAR processed will have the rule appplied, or "local" scope meaning that they will only apply to a single bundle JAR. Global rules will be included in the `mangen.properties` file. Local rules are placed within the Manifest for the appropriate bundle in a special `mangen` attributes section e.g.
+
+
+
+ Bundle-Name: Help Component
+ Bundle-ClassPath: .,help4.jar,oracle_ice.jar,ohj-jewt.jar
+ Metadata-Location: metadata.xml
+
+ Name: com/ascert/openosgi/mangen
+ mangen-rule-0: Ignore imports(com\.adobe\.acrobat.*,webeq\..*,javax\.help,javax\.media)
+
+
+
+
+
+
+Details are included below showing whether a *<rule-type>* can be used in a global or a local context
+
+### AttributeStamp
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `yes` |
+| *Standard options* | `imports`, `exports` |
+| *Rule specific options* | |
+
+
+When processing a bundle JAR `mangen` can only detect the name of a required import package or a possible export package. Within an OSGi environment it's possible to also include qualifying information on a package name, such as versioning information. The AttributeStamp rule allows this information to be "stamped" over a detected package name.
+
+The rule may be supplied locally, in which case it will only apply to instances of a package name match with a specific bundle JAR, or globally in which case it will be applied to all instances of a package name match across all JARs.
+
+The `imports` or `exports` options allow stamping of attributes to either imported or exported packages respectively. The rule will perform a regex package name match against each entry in the list and if the name matches, will augment the matched package name with any additional attributes suppled. The following shows an example of this.
+
+*Example:*
+
+
+
+ mangen-rule-1=AttributeStamp imports(org\\.osgi\\.framework;version="1.2.0")
+
+
+
+If the rule finds a package name pattern match and the package already has additional attributes an error will be thrown if the stamped attributes do not match the existing attributes. This could be the case as a result of either a previous AttributeStamp or Merge rule.
+
+### DontImportOwnExports
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `yes` |
+| *Standard options* | |
+| *Rule specific options* | |
+
+
+In many application cases it's not necessary for a bundle JAR to import it' own exports. This rule may be used locally or globally to remove from a bundle's import list any package which it also exports.
+
+### Ignore
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `yes` |
+| *Standard options* | `imports`, `exports` |
+| *Rule specific options* | |
+
+
+There are several cases where a `mangen` detected possible export or required import may not actually be desired:
+
+* Standard JDK classes, particularly in an OSGi R3 environment where these packages are resolved without needing import statements
+* Packages which `mangen` detects as needing imports but won't actually be used in a running environment. One example of these is third party JARs which include Ant tasks for use in a development environment but which would probably never be instantiated in a running application.
+
+The Ignore rule will remove matching package entries from either the import or export lists, or both, as specified in the options.
+
+*Example:*
+
+
+
+ mangen.R4.syspackages=java\\..*
+ mangen-rule-R4-0=Ignore imports(${mangen.R4.syspackages})
+
+
+
+### Merge
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `yes` |
+| *Standard options* | `imports`, `exports` |
+| *Rule specific options* | `existing`, `fixed` |
+
+
+In some cases the simplest way to use `mangen` will be to provide a list of known imports and exports and then have `mangen` "merge" any remaining required imports and possible exports into these lists as needed. The Merge rule provides two mechanisms in which these known imports and exports can be supplied:
+
+* Using `existing` Manifest entries - in which case `mangen` will take any current Import-Package and Export-Package headers and merge them into the detected import and export package sets
+
+* By specifying a set of `fixed` Manifest entries - allowing a limited set of pre-determined entries to be listed in the special `mangen` attributes of the Manifest which will be merged in.
+
+*Example:*
+
+
+
+ Manifest-Version: 1.0
+ Bundle-Name: mybundle
+ Export-Package: my.bundle.package
+
+ Name: com/ascert/openosgi/mangen
+ Import-Package: some.other.package
+
+
+
+A `Merge existing` rule using the above example would ensure that `my.bundle.package` appeared in the list of packages to export. A `Merge fixed` would ensure that `some.other.package` appeared in the list of packages to import.
+
+It's possible to use both `Merge existing` and `Merge fixed` within a given set of application rules although it's more likely that only one of these would be used to meet a given application build strategy.
+
+The imports and exports options allow constraints on the packages to be merged based on regex package name pattern matches.
+
+One other aspect to note with the Merge option is that it also provides an alternative way to "stamp" OSGi attributes on a `mangen` detected pakcage name, since if the package being merged was already in the set of `mangen` detected packages it's entry will be augmented with any additional attributes supplied from the package entry being merged.
+
+
+### ProcessBundles
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `no` |
+| *Standard options* | |
+| *Rule specific options* | |
+
+
+By default, `mangen` will not actually process any of the JAR files specified, it will simply create objects to access them.
+
+Being able to skip `mangen` processing of bundle JARs is useful behaviour in a small number of instances, such as the [ObrReport]({{ refs.-obrreport.path }}) that will generally be run against existing bundle Manifest headers rather than `mangen` generated sets of imports and exports.
+
+For most cases, however, `mangen` import and export processing will be required and this Rule should be included.
+
+*Example:*
+
+
+
+ mangen.rulesets=mangen-rule-initial- , mangen-rule-Ant- , mangen-rule-R${mangen.osgi.level}- , mangen-rule- , mangen-rule-final-
+
+ mangen-rule-initial-0=ProcessBundles
+ ...
+
+
+
+
+### ResolveImportsToExports
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `no` |
+| *Standard options* | `sys-packages` |
+| *Rule specific options* | |
+
+
+Some OSGi developers use the framework as a basis for creating packaged applications, in fact it is just this usage which Ascert make of OSGi and Oscar and which motivated the creation of =mangen. In such cases, the simplest and possibly most powerful rule use case is simply to supply `mangen` with a complete set of application bundles and let it work out the matrix of imports and exports required to resolve every bundle dependency. This is exactly what the ResolveImportsToExports does.
+
+ResolveImportsToExports can only be used globally and will prune down the set of possible exports and required imports to just those required to satisfy every bundle dependency. It will generate `*** WARNING ***` report lines for the following cases:
+
+* duplicate exports where more than one bundle could be an exporter of the same package which is a necessary import of some other bundle. In these cases, at present, the first possible exporter found will be picked and all others removed and a warning generated
+* missing exports i.e. packages required by one or more bundles that are never exported. Erroneous warnings for standard JDK packages can be avoided using the `sys-packages` option.
+
+At present, the known cases where this rule may fail to create a consistent and resolved set of bundle Manifests are:
+
+* cases of dynamic classloading
+* certain third party JARs, such as Xerces, which use the awkaward-to-handle OSGi case of `Thread.getContextClassLoader()` to determine the classloader for dynamic classloading.
+
+### UpdateBundles
+
+| *Usable globally* | `yes` |
+| *Usable locally* | `no` |
+| *Standard options* | |
+| *Rule specific options* | `overwrite` |
+
+
+By default, `mangen` will only report on the generated list of imports and exports for each bundle processed. The UpdateBundles rule can be used to instruct `mangen` to update each bundle's Manifest wth the set of generated packages.
+
+This rule can only be used globaly. If the `overwrite` option is specified, the bundle JAR will overwritten with a new bundle JAR containing the new Manifest. Without this option, the update will create new JARs of the same name as each existing JAR but with a suffix of `.new.jar`.
+
+
+## Reports
+
+Reports are really like a simplified case of rules. At present only a couple of simple reports are included.
+
+All reports at present send their output to `System.out`, which can of course be redirected to a text file if a persistent copy is desired.
+
+### RuleReport
+
+This report will show any Rule generated output.
+
+### BundleReport
+
+| *Report options* | `show-differences` `show-local-rules` |
+
+This report will create a simple overview of the refined set of a bundle's imports and exports, together with a report of any local rules which have been run for the bundle. The following options are supported:
+
+* `show-differences` - will show details of *ADDED* and *REMOVED* packages by comparing the generate set of import and export packages against the existing Import-Package and Export-Package attributes. If this option is omitted a simple list of generated imports and exports will be shown
+* `show-local-rules` - will show report output from any local rules run for each bundle JAR
+
+
+### ObrReport
+
+| *Report options* | `skip-jars` |
+
+Produce a report for each bundle JAR that can be used as an OBR descriptor.
+
+The `skip-jars` option can be used to specify a comma separated list of JAR name regex patterns for which OBR descriptors are not required (e.g. source JARs).
+
+OBR descriptor production is a quite different aspect of `mangen` usage to import/export generation and so a separate example `obr.properties` file has been included to show typical settings for it's usage. The `-Dmangen.properties` setting can be used to run `mangen` with these settings e.g.
+
+*Example:*
+
+
+
+ java -Dmangen.properties=lib\obr.properties -jar lib\mangen.jar e:\obr\repo\
+
+
+
+The example `obr.properties` includes a number of features:
+
+* there is no *ProcessBundles* rule, meaning that `mangen` will not automatically generate imports and exports.
+* there is a *Merge existing* rule meaning `mangen` will use existing Manifest headers in each bundle JAR to generate the ObrReport
+* there is an `mangen.obr.ver` property that can be used to control the format of the OBR descriptors produced
+* text templates are included that allow the OBR version 1 and version 2 descriptors to be changed without needing to modify the ObrReport code.
+
+Whilst running, the ObrReport will look for a number of specific properties to aid it's processing:
+
+* `mangen.obr.ver` - to determine which format of OBR descriptor to produce
+* `mangen.obr.descr.<obr-ver>` - the main text template used to produce the OBR descriptor for each bundle
+* `mangen.obr.import.<obr-ver>` - the template used to produce the descriptor text for each import.
+* `mangen.obr.export.<obr-ver>` - the template used to produce the descriptor text for each export.
+* `mangen.obr.import.ver.<obr-ver>` - the template used to produce a "version" descriptor for an import which has an explicit version specified.
+* `mangen.obr.export.ver.<obr-ver>` - the template used to produce a "version" descriptor for an export which has an explicit version specified.
+
+The templates include a simple "tag substitution" mechanism that will expand the following tags:
+
+* `@@hdr:<header-name>@@` - include the attribute value of <header-name> from the bundle's Manifest. The `mangen` attributes will be searched first, followed by the Main attributes
+* `@@imports@@` - process the list of imports and generate descriptor text based on the `mangen.obr.import.<obr-ver>` template
+* `@@exports@@` - process the list of exports and generate descriptor text based on the `mangen.obr.export.<obr-ver>` template
+* `@@import-ver@@` - will be expanded using `mangen.obr.import.ver.<obr-ver>` if an explicit version was included for the import package
+* `@@export-ver@@` - will be expanded using `mangen.obr.export.ver.<obr-ver>` if an explicit version was included for the export package
+* `@@pkg:name@@` - name of the import or export package currently being processed
+* `@@pkg:ver@@` - version of the import or export package currently being processed
+
+## Contents of the distribution file
+
+The current `mangen` distribution includes the following:
+
+ * pre-compiled versions of `mangen` and libraries
+ * full source code and Ant build files
+ * this documentation in HTML format. The original documentation is maintained in TWiki format at Ascert's intranet set and a copy of the raw TWiki file is included.
+
+The following third party libraries are also included in the distribution:
+
+ * [Felix](http://incubator.apache.org/felix/) library JARs - required Felix library JARs, used by `mangen` in Manifest processing, and generation
+ * [ASM](http://asm.objectweb.org/) - the ASM java bytecode parsing toolkit used by the `ASMClassScanner` class scanning implementation.
+ * [BCEL](http://jakarta.apache.org/bcel/) - the BCEL java bytecode parsing toolkit used by the `BCELScanner` class scanning implementation.
+
+Thanks also go to the following contributors:
+
+ * [Richard S. Hall]({{ refs.mailto-heavy-ungoverned-org.path }}) - both for his assistance in the development and testing of `mangen` and for his contribution of the ASM based class scanning implementation.
+
+
+# Extending `mangen`
+
+First things first. You need to be a reasonably proficient Java developer to undertake extending `mangen`. If you're not, then you should consider a Java programming course or tutorial of some kind.
+
+Extensions to `mangen` can be performed in the following ways:
+
+ * creating new or enhanced Rules
+ * creating new or enhanced Reports
+ * supporting alternative class scanning implementations
+ * Modifying the core source code
+
+The idea is that as `mangen` matures most extension cases will be possible via the first two means, with new class scanners and core modifications being the exception.
+
+For detailed information, Javadoc API documentation for `mangen` can be found @@api-index-loc@@.
+
+## Creating new Rule types
+
+A rule type is in fact just a Java class which implements the `com.ascert.openosgi.Rule` interface. If no package name is specified, these will be assumed to be in the `com.ascert.openosgi.mangen.rules` package. Although somewhat less readable, a fully-qualified class name can be supplied for rule types in other packages.
+
+At present, the simplest way to learn about creating new rules is to look at the source code for existing rules to understand how they're put together and what can be done in them.
+
+## Creating new Report types
+
+Reports are similar to rules. A Report type is a Java class which implements the `com.ascert.openosgi.Report` interface. Unqualified report types will be assumed to be in `com.ascert.openosgi.mangen.reports` package, with the option to use fully-qualified class names if desired.
+
+As with rules, the source code for the existing reports is the best place to learn about creating new reports.
+
+## Alternative class scanners
+
+To parse the class files of an application `mangen` needs a class file bytecode scanning library. So that alternative scanning tools may be used `mangen` does not make direct usage of any library implementation. Instead a wrapper class is used which implements the `ClassScanner` interface, and hence insulates `mangen` from the specific details of different bytecode scanning tools. The `mangen.scanner.class` property can be used to control which scanner implementation class is used.
+
+At present, implementations of the `ClassScanner` interface have been include for the ObjectWeb [ASM](http://asm.objectweb.org/) toolkit and the [Apache BCEL|http://jakarta.apache.org/bcel/] toolkit.
+
+
+# Ongoing Development
+
+## Change Log
+
+### Version 1.0.1
+
+ * Initial version submitted to Felix project.
+ * Package names changed and license headers changed to Apache license
+ * `OsgiPackage` classes changed to use Felix manifest handling classes.
+ * ASM and BCEL sources removed and maven dependencies created to pull these in from repositories.
+ * Compiles and builds using normal maven build, but as yet doesn't create a standalone distribution which includes dependent jars and config `.properties` files.
+ * No analysis work has been performed to determine enhancements and additional rules desirable to integrate with Felix build and take advantage of `mangen` class scanning.
+
+
+### 0.1.x Versions
+
+The 0.1.x versions of `mangen` are the original versions developed to work with Oscar. The versions and documentation can still be downloaded from the [OBR Sourceforge site](http://oscar-osgi.sourceforge.net/mangen/). The change history has been maintained here for completeness.
+
+#### Version 0.1.2
+
+ * Inclusion of [ObrReport]({{ refs.-obrreport.path }}) for generation of OBR descriptors *[ oscar-osgi-Feature Requests-1221468 ]*
+ * Removed "default" processing of JARs. Now an explicit [ProcessBundles]({{ refs.-processbundles.path }}) must be included to force JAR processing to take place. This allows reports, such as the new ObrReport to skip `mangen` import/export processing and just work from existing manifests.
+ * default `mangen.properties` now explicitly lists each non java.* package rather than using wildcards, proved safer and more reliable when creating OSGi R4 manifests
+
+#### Version 0.1.1
+
+ * Support for errors and warnings to cause non-zero exit status to be returned
+ * Fix for occasional failures to update bundle JARs *[ oscar-osgi-Bugs-1218334 ]({{ refs.-oscar-osgi-bugs-1218334.path }})*
+
+#### Version 0.1.0
+
+ * First version
+ * Support for current OSGi Release 3 (R3) manifest headers, and basic support for proposed upcoming R4 headers
+ * Processing of JARs and directories containing JARs and parsing of contained classes using a subset of BCEL.
+ * Simple but extensible rule based engine for import and export set manipulation.
+ * Simple but extensible reporting engine
+ * Updating of process bundle JARs via an UpdateBundles rule
+ * Pluggable interface to allow alternative class byte code scanners to be used
+
+## Possible Enhancements
+
+As with any piece of software, there are always more things you'd like to do than time available in which to work on them. This library is no exception.
+
+In it's present form it `mangen` is simple, reasonably fast, and usable. Ideas on some of the more significant areas where it could be enhanced or improved are described in the sections below.
+
+Most `mangen` enhancement ideas have now been created as issues in the [Apache JIRA list](https://issues.apache.org/jira/secure/IssueNavigator.jspa?component=12310910&sorter/field=priority&mode=hide&reset=true&pid=12310100&sorter/order=ASC).
+
+Those which are more speculative have been left below.
+
+### Online usage within an OSGi environment
+
+Extending the concept of [Manifest-less usage]({{ refs.-manifestlessusage.path }}) comes an interesting possibility that a specific OSGi platform such as [Oscar|http://oscar.objectweb.org/] could be extended to load any JAR and automatically 'fix-up' a usable Manifest. This would require internal access/knowledge of the specific platform's implementation since the existing standard OSGi API would not supply sufficient details and access to the set of loaded bundle JARs. Additionally, it would probably need to be a "multi-step" process since until a largely complete set of bundle JARs were loaded it may not be possible to resolve all imports and exports. This perhaps implies some form of platform extension to allow a set of JARs to be passed to some form of "pre-load" mechanism capable of resolving their imports and exports within the JAR set, and possibly from existing loaded bundle JARs or even an external [OBR|http://oscar-osgi.sourceforge.net/].
+
+# Acknowledgements
+
+Ascert is pleased to acknowledge the following projects, organisations and individuals whose tools have been used in the creation of this software:
+
+ * [ASM](http://asm.objectweb.org/) - ObjectWeb's bytecode scanning and manipulation toolkit.
+ * [BCEL](http://jakarta.apache.org/bcel/) - Apache's bytecode scanning and manipulation toolkit.
+ * [jEdit](http://www.jedit.org) - home of the powerful and flexible jEdit
+ editor
+ * [Ant](http://ant.apache.org) - home of the Apache Ant build tool
+ * [Blue Marsh Softworks](http://www.bluemarsh.com/) - authors of the excellent [JSwat|http://www.bluemarsh.com/java/jswat/index.html] Java debugger.
+ * [Subversion](http://subversion.tigris.org/) - home of the Subversion (aka SVN) version control system, and [Regnis|http://www.regnis.de/] and [TortoiseSVN|http://tortoisesvn.tigris.org/], both of which are excellent SVN GUI clients
+ * [Sun Java](http://java.sun.com) - home of all things Java and a place we love.
+
+