Correct way to read OSGi configuration

[sandeepk7656774]

Hi All,

It looks like there are 2 ways to read OSGi configurations

1. ConfigurationAdmin API way (Apache Felix - Apache Felix Configuration Admin Service)
2. By using Service, Implementation and ConfigurationPolicy annotation (Reading OSGi Configuration Values for Adobe Experience Manager 6.3)

Which one is correct way? What are advantages of one over another?

Regards,
Sandeep 

[smacdonald2008 · Accepted solution]

Use the API (org.osgi.service.metatype.annotations) as discussed in Reading OSGi Configuration Values for Adobe Experience Manager 6.3

[sandeepk7656774]

Thanks smacdonald2008​. Is there a way to read non-custom OSGi configuration e.g. Day CQ Mail Service etc in our code? Using ConfigurationAdmin we could directly get configuration

configurationAdmin.getConfiguration("PID of OOTB config");

Annotations seem to be working fine for custom application specific configuration (we have custom sling:Osgi config and corresponding java class), but for OOTB configurations there is already a mapping Java class in OOTB bundle, but not sure how we can use in custom bundle. If i should start a separate thread for this, let me know. But I thought its related to same thread.

Regards,
Sandeep

[arunpatidar]

Hi,

Please check below example for reading log configs, similarly you can do for others :

In below example you can read OOTB web console config inside activate method also.

aem63app-repo/ReadOsgiRepoConfImpl.java at master · arunpatidar02/aem63app-repo · GitHub

[sandeepk7656774]

Thanks Arun, this example is nice, but uses ConfigurationAdmin API. I was looking for example using R6 annotations way of reading OSGi configuration.

Regards,
Sandeep

[arunpatidar]

Hi,

I am not sure if you can use OSGI annotations and OCD to read configuration of other services but itself. To read configs of other services you need to use ConfigurationAdmin.

Thanks
Arun

[Jörg_Hoh]

Hi,

Do not read the OSGI configuration of other services. That's an antipattern for almost every case. Use the 2 methods you listed to read the configuration of a service from within this specific service, but do not use the ConfigAdmin to read any other configuration.

* If someone unfamiliar with your implementation changes some configuration, it might also affect other services.

* When your service B reads the configuration of service A, any change of the config of A will not cause a restart of your service B.

Don't do that. Don't read configuration from product bundles. If your code needs to have access to some shared configuration, build a "SharedConfigService" for it and let all consumers reference it.

Jörg