Differences
This shows you the differences between two versions of the page.
multiple_component_instances_via_configuration [2015/09/24 16:44] |
multiple_component_instances_via_configuration [2021/04/05 11:23] (current) |
||
---|---|---|---|
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=" | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | ===== Configuration ===== | ||
+ | Here comes the tricky part. The normal configuration (always using //file install// for picking up the configuration) has the filename like the // | ||
+ | |||
+ | You syntax for the configuration file for multiple instances of a component (when using //file install// | ||
+ | |||
+ | < | ||
+ | |||
+ | The configuration file itself doesn' | ||
+ | |||
+ | ===== Configuration Modification ===== | ||
+ | And if a configuration changes the component will be deactivated, | ||
+ | |||
+ | {{tag> |