migration of SCR annotation to OSGI R6 annotations | Adding multiple OCD for a component

[RejithaRaj]

Hi,

I am working on the migration of SCR annotation to OSGI R6 annotations. I am able to create and use custom OSGI config within the bundle using OCD.

1. I am not able to use them outside my main bundle. (We have multiple bundles referring the main OSGI config).

How to use them ?  Got an error specifies ocd class com.xxx.cms.config.GlobalSystemSettings which cannot be found

2. Also I wanted to use 2 OSGi service inside my component. I am writing a scheduler, I wanted to refer to Scheduler Interface as one OCD and custom OSGI Configuration as another. Like show below

@Designate(ocd = SitemapSchedulerConfig.class,ocd = GlobalSystemSettings.class).

But i am getting error.

Any help would be appreciated.

[smacdonald2008]

I am only aware of this HELPX artilce that shows you how to read OSGi config values for a service.

Reading OSGi Configuration Values for Adobe Experience Manager 6.3

This approach was successfully used in this SOLR article to read the OSGI config values too: Adobe Experience Manager Help | Integrating SOLR with Adobe Experience Manager 6.4

I too have only used them within the same OSGi bundle - as shown in the SOLR article.

[Jörg_Hoh · Accepted solution]

If you reference the same OCD from multiple services, each service gets the same (but not identical) configuration; thus you have the same configuration multiple times in your system. I would not do that (at least I would be confused).

And you cannot use 2 OCD statements in your @Designate annotation. Check OSGI r6 enterprise spec, chapter 105.9.3

[RejithaRaj]

Hi,

Thank you for your input.

As you mentioned, calling same OCD from multiple services is creating multiple reference of the same configuration.

So if we wanted to share the config variables within your project, how do you suggest to use them ?

Creating same config variables as different OCD will not be a good solution right ? then It will be repeated.

[Jörg_Hoh]

Well, there's an obvious easy answer to that, and probably an answer which makes more work but will likely improve your software architecture.

The obvious answer is to create a single service ("ConfigService"), which holds all these shared variables as parameters, and provides getters to all of them. Then you can reference this ConfigService from all other services which need to read them. Don't overuse it, as a single change of an innocent variable might cause a restart of your complete application (all dependent services).

When you are interested in the more the complex way: Ask yourself why you have a lot of services sharing the same configuration data. In many cases it's caused by bad application design and you probably violate the single responsibility principle, because multiple services need to access the same "thing" (whatever it might be). If you redesign your services you should come up with a solution where a specific configuration value is only required by a single service; and all other services are building on top of this service (and not by requesting this configuration value from the service).

Jörg