Expand my Community achievements bar.

SOLVED

Correct way to read OSGi configuration

Avatar

Level 4

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 

1 Accepted Solution

Avatar

Correct answer by
Level 10
6 Replies

Avatar

Correct answer by
Level 10

Avatar

Level 4

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

Avatar

Community Advisor

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



Arun Patidar

Avatar

Level 4

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

Avatar

Community Advisor

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



Arun Patidar

Avatar

Employee Advisor

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