This shows you the differences between two versions of the page.
— |
multiple_component_instances_via_configuration [2015/09/24 14:44] (current) mihael created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Multiple Component Instances via Configuration ====== | ||
+ | In OSGi it is really simple and straightforward to create a service. Services in OSGi are singletons by default. | ||
+ | But sometimes you need multiple instances of the same service just with different configurations. And luckily OSGi also supports this. | ||
+ | |||
+ | ===== Implementation ===== | ||
+ | Just write your DS component as always as you would for a single instance component. Now add | ||
+ | |||
+ | configuration-policy="require" | ||
+ | |||
+ | to the component xml (or add it via annotations. I am a bit old school and still write the xml =). That means that a component will only be activated if there is a configuration for it. | ||
+ | |||
+ | You don't need to implement //ManagedService// for getting the configuration. So you can skip this step in your coding habit ;-). | ||
+ | |||
+ | ===== Configuration ===== | ||
+ | Here comes the tricky part. The normal configuration (always using //file install// for picking up the configuration) has the filename like the //service.pid// attribute with the suffix //cfg//. But that would mean that we would create a normal configuration ... and we wouldn't get multiple instances. | ||
+ | |||
+ | You syntax for the configuration file for multiple instances of a component (when using //file install//)is | ||
+ | |||
+ | <component.name>-<new_service_pid>.cfg | ||
+ | |||
+ | The configuration file itself doesn't need the //service.pid// entry. | ||
+ | |||
+ | ===== Configuration Modification ===== | ||
+ | And if a configuration changes the component will be deactivated, deregistered and removed and a new component instance will be created with the updated configuration. | ||
+ | |||
+ | {{tag>osgi}} |