Configuration Framework

From RifidiWiki

Jump to: navigation, search

The configuration bundle provides two services that manage core services. The ConfigurationSerivce handles persisting registered services to an ini file and restoring them when the system starts up. The JMXService exposes services to JMX clients.

Configservice.jpg

Configuration

A configuration is a wrapper around a service that is put into the OSGi service registry. The configuration handles two important pieces of functionality: 1)Persisting the service to an ini file. 2) Exposing the service to JMX. Default behavior is provided by DefaultConfigurationImpl. All services in the edge server that wish to be persisted and/or exposed as JMX beans should extend RifidiService and should be associated with a factory. One important aspect of configurations is that they have properties associated with them. Properties are accessed in the java beans getter/setter style. For example if a configuration has a property called myprop, it should have a getMyProp() method and a setMyProp() method (as long as the property is settable).

Configuration.jpg

The following is an example of an entry in the ini file for a service:

[MyService-1]
factoryid = MyServiceFactory
MyProperty = abc

In this example, there is a configuration with an ID of MyService-1. The service is produced by a factory with ID MyServiceFactory. It has one property called MyProperty with a value of abc.

The following is an example of a simple service that uses the configuration framework

@JMXMBean

public class MyService extends RifidiService {

	private String myProperty;

	@Property(type = PropertyType.PT_STRING, 
			displayName = "My Property", 
			writable = true, 
			description = "This string will be printed")
	public String getMyProperty() {
		return myProperty;
	}

	public void setMyProperty(String myNewPropValue) {
		this.myProperty = myNewPropValue;
	}

	@Operation(description = "Invoke to say hi")
	public void sayHi() {
		System.out.println(myProperty);
	}
}

Configuration Factory

A configurationFactory produces configurations. When a ConfigurationFactory becomes available it registers itself in the OSGi registry. After that, it may be used by other components to create new services of a certain type.

The getFactoryIDs() method returns the ID of the factory (the same ID as the one in the ini file). The getClasszz() method returns the class of the service that is produced by this factory. The customConfig() method provides a hook for the factory to configure the service after it is created but before its configuration object is registered to the OSGi registry. Most factories should will use this method to register the service in the OSGi registry under the service's interface.

public class MyServiceFactory extends AbstractServiceFactory<MyService> {

	
	@Override
	public void customConfig(MyService instance) {
		//register service in osgi registry under the MyService interface
		instance.setServiceRegistration(getContext().registerService(
				MyService.class.getName(),
				instance, 
				null));
	}

	@Override
	public Class<MyService> getClazz() {
		return MyService.class;
	}

	@Override
	public List<String> getFactoryIDs() {
		List<String> ret = new ArrayList<String>();
		ret.add("MyServiceFactory");
		return ret;
	}
}

Configuration Service

The configuration service persists other services to an ini file and restores them from the file when the factory that produces that service becomes available. Saving happens as follows: The ConfigurationService listens for new Configurations to become available in the OSGi service registry. When the user invokes the store() method on the ConfigurationService, it will step through each of the registered configuraitons and persist their properties to an ini file. Restoring happens like this: On system startup, the ConfigurationService will read in the ini file. It then goes through the list of persisted services. If the factory is available for that service, it will pass the configuraiton information to that factory which will create a new service. If the factory is not available, it holds on to the configuration information and waits until the factory becomes available, at which time it use the factory to produce a new instance of the service as before.

JMX Service

The JMX Service listens for services to be registered in the OSGi registry which have been annotated with the @JMXMBean annotation. It then looks for properties in the services (as marked by the @Property annotation) and invokable methods (void-void methods marked with @Operation). It then makes these services accessible over JMX

Personal tools