Yeah, my bad - I meant ManagedServiceFactory: https://docs.osgi.org/javadoc/r5/cmpn/org/osgi/service/cm/ManagedServiceFactory.html
It works with "pid", however this pid becomes a factory one, meaning that your etc/ configuration files must have -something in the name. >From your example: etc/no.priv.bang.oldalbum.roleadder.auth-testenvironment.cfg etc/no.priv.bang.oldalbum.roleadder.auth-prod.cfg The -prod is not directly visible to managed service #update method call (however can be retrieved from dictionary if you use fileinstall), cause "pid" will contain your pid and some random value. Your service factory can then decide what kind of service should be published and decide to resign from it if config is invalid. I used this pattern to build configurable authentication mechanism in one of customer projects and it served purpose quite well. With proper tracking and decorating of services you can build whole chain of elements which will for example result in launching of dedicated endpoint where user will enter password, or like in your case amend authorization logic. Best, Łukasz On 21.09.2020 19:58, Steinar Bang wrote: >>>>>> Łukasz Dywicki <[email protected]>: > >> Last resort is turning your configuration into >> ManagedConfigurationFactory and publishing services only when config >> admin receives an updated version of config. > > Hm... google can't find much on ManagedConfigurationFactory. > > Do you have a URL to some docs? > > Thanks! >
