This page presents how creating, reconfiguring and destroying iPOJO component instance with the OSGi Configuration Admin.
The Configuration Admin service is a configuration manager describe in the OSGi R4 Compendium. It allows an operator to set the configuration information of deployed applications The Configuration Admin defines the Configuration as the process of defining the configuration data of applications and assuring that those applications receive that data when they are running. The Configuration Admin is becoming an important piece on OSGi Gateway. It is become the standard way to configure applications on OSGi gateways.
As the configuration admin offer an administration support, it seems reasonable to combine iPOJO and the Configuration Admin to control the gateway. Indeed, thanks to the configuration admin it should be possible to:
- Create new component instances
- Configuring / reconfiguring these instances
- Destroying these instances
- Reconfiguring instances by using Managed Services (not addressed in this page, see here for further information)
The configuration admin is persistent, so stored configuration will be reload it the framework restarts.
Moreover, using the configuration admin allows avoiding describing instances inside iPOJO metadata file. These instances are created by inserting new configurations in the configuration admin.
iPOJO has a component type concept. For each (public) component type, a ManagedServiceFactory is published. For each configurations matching with the component type from the Configuration Admin, a new component instance is created. Moreover, when this configuration is updated, the instance is dynamically reconfigured. If the configuration is removed, the instance is disposed.
If a new Configuration is created:
- If the factory is available or an instance is create immediately,
- Else the factory is not available and the instance will be created as soon as the factory appears.
This section presents 3 examples about the management of iPOJO instances with the configuration admin:
- A simple instantiation example and destruction
- An instantiation with property injection and dynamic reconfiguration
- A property propagation example
All these examples are downloadable here. The archive contains both the project sources and a pre-configured version of felix.
To compile the project, launch ant from the config.admin.tutorial directory
Then, you can launch Felix by launching the following command from the felix directory:
Let's take 4 Felix shell commands to manage configuration admin configurations (available in the example archive):
- create_conf <type> <property-key=property-value>* allows to create a new Factory Configuration attached to the given type. The configuration contains the given properties.
- update_conf <configuration_name> < property-key=property-value>* allows to update the configuration with the given name with the given properties.
- delete_conf <configuration_name> allows deleting the configuration with the given name. If the name is 'all', delete all stored configurations.
- list_conf allows listing all stored configuration.
Moreover iPOJO and an implementation of the Configuration Admin must be deployed on the gateway:
Imagine the following very simple component implementation:
The component type is defined with following metadata:
The defined component type (Hello1) just creates a Hello1 object when the instance is created (thanks to the immediate attribute).
So if we deploy this bundle and add a consistent configuration we obtain (note that bundle need to be already compiled):
Note: Debug messages from the configuration admin were removed
So as predicted, the Hello message appears. To be really sure of the creating, we can ask for the instance architecture (the component type allows architecture introspection thank to the architecture attribute):
So, the instance is correctly created. The name of the instance was created by the configuration admin. It could change according to your configuration admin implementation.
Then, we can delete the instance by removing the configuration from the configuration admin:
So, arch does no more displayed any hello instances, the created instance was disposed.
Imagine the following component implementation:
And the following metadata:
The defined component type (Hello2) write "Hello + $name" when the property 'to' (attached to the field m_name) receive a new value. A value is necessary insert in the instance configuration. Moreover when killed, the instance will display a "Good By" message.
Let's play a simple scenario:
- Create a Hello2 instance
- Update the instance configuration
- Kill the created instance
In this simple scenario, we see that when the configuration is updated, the instance receives the new value. The setName method is immediately invoked to inject the new value. Moreover, when the configuration is deleted, the instance is going to be killed: the "Good Bye" message appears and the instance is disposed.
Obviously it is possible to create several instance of the same type:
The 'arch' command displays the two created instances.
you can delete all created configurations with the delete_conf all command
It is possible to propagate the instance configuration to the published service properties. To activate property propagation you need to write the 'propagation' attribute in the 'properties' element as in
The defined type provides a service. Moreover it supports properties propagation. So all property, except listed one (m_name), will be published inside the provided services.
So create an instance of the Hello3 component type as follow:
Then, you can check provided services with the services 7 command
Now, we update the instance configuration with a new property 'p1':
Remark that the new property p1 is published.
Now we can remove this property by reconfiguring the instance with an empty configuration:
The service does no more publish the p1 property.
This page has presented how to combine the configuration admin and iPOJO. You can also use FileInstall in combination with iPOJO and the Configuration Admin. Subscribe to the Felix users mailing list by sending a message to firstname.lastname@example.org; after subscribing, email questions or feedback to email@example.com