Difference between revisions of "SensiNact/gateway-bridge-local-config"

Revision as of 04:06, 2 May 2018

Local bridge configuration file

A shorter (even shorter) description of this modification is shown in sensinact-localconfiguration.pdf

In previous versions of sensinact the only way a bridge had to read a configuration externally would be either from the sensiNact-conf.xml or using the felix global configuration file.

The inconvenience of using sensiNact-conf.xml for the configuration is that this file is located inside the bundle itself and since the bundle can be signed during the compile time, modifying this file externally will invalidate your bundle for the platform, thus forcing your to compile the entire platform you re-validate your new sensiNact-conf.xml, making this approach unfeasible for the runtime.

The felix global configuraton approach inconvenience is that this file is taken into account for all the bridges and the entire osgi platform, which means that the bridges can read other bridges configurations, turning the configuration in a true good example of spaghetti architecture.

a non-exautive list of issues are: * the properties have long names in order to avoid conflict with other bridges configuration, entirely up to the developer to chose a long enough property name. * gateway configuration, http port, gateway name, security mechanism and other, are mixed up with particular bridge configuration, turnning the global property files hard to read. * In the global configuration properties are present (read) even if the bridge is not present in the platform * sometime bridges share the same configuration with other bundles; but this loose coupling makes hard to identify which configurations are really needed for the individual bridges

Thus a new method was created to isolate this configuration and allow this file to be visible exclusively for the bridge that needs the configuration.

Declaring a configuration file

In order to make the configuration file visible for your bridge, you have to deploy a property file named <math>{Bundle-SymbolicName}.property or </math>{Bundle-SymbolicName}.properties. Thesymbolic name of your bundle is indicated into the MANIFEST.MF file or you can use the markup "name" from of your bundle's pom.xml.

This file should be located in the diretory named cfgs inside sensinact installation directory, $SENSINACTHOME/cfgs/_.

Once this is done, all the information put inside of the configuration file can be used by your bundle via the Activator.

There are two ways of reading this property, one is using annotation method (recommended) and other using a doStart() new signature.

Injecting your properties into your bundle Activator via annotation

If you inherit your Activator directly from AbstractActivator, you can inject the properties defined in file deployed in cfgs directory directly using Property annotation located in the package org.eclipse.sensinact.gateway.common.annotation.

In the example shown below assume we have a bridge in a bundle with a symbolic-name custom-bridge. Thus we deployed a file named custom-bridge.properties in $SENSINACTHOME/cfgs_ directory. The content of this file is:

host=192.168.12.2

The example of how to read this property in the activator is:

public class Activator extends AbstractActivator<Mediator>{
    @Property(name="host")
    public String myhost;
    public void doStart() throws Exception {
        System.out.println(&quot;Property host=&quot;+myhost);
    }
    ...
}

Once @Property annotation is used, sensinact will assume that this is a required configuration property, and case this property is not defined the framework log will warn the user about a property required that is absent thus the bridge might not be correctly configured.

Case you want to define a default value for this property, you can assign a default value in the annotation, below the previous example modified:

public class Activator extends AbstractActivator<Mediator>{
    @Property(defaultValue="localhost")
    public String host;
 
    public void doStart() throws Exception {
        System.out.println("Property host="+host);
    }
    ...
}

Using the defaultValue options, case the property is not defined (or the configuration file is not present) the default value will be injected.