> I didn’t mean ManagedService using DS, I meant using DS configuration (which 
> is basically a managed service.

Ok - but you can see the source of confusion right? Your post does not 
reference DS at all, and ManagedService is an interface defined by 
ConfigurationAdmin. If someone looks up ManagedService on Google then they 
won’d find the DS solution.

> I disagree about @Referece to ConfigurationAdmin: in some use cases, it makes 
> sense. Look in Karaf Cellar for instance.

I have taken a look - in most of the cases here Cellar is acting as a 
management agent (which I explicitly mentioned in my first post) and is making 
configuration updates on behalf of other people, or synchronising 
configurations, not getting its own configuration. In some other cases it 
appears as though the code could be simplified and improved by not using 
ConfigurationAdmin to retrieve its own configuration, but I’m not a cellar 
expert, and it’s possible that these components are still acting on other 
bundle’s configurations not their own. The main thing is not to confuse 
middleware/infrastructure with application code. The number of people who are 
writing things like Cellar is very small, and the OSGi advice/best practice is 
pretty clear that using ConfigurationAdmin to get your own configuration is an 
anti-pattern.

Regards,

Tim



> On 3 Dec 2017, at 13:55, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> I didn't mean ManagedService using DS, I meant using DS configuration (which 
> is basically a managed service.
> 
> When using @Component, we implicitly have a configuration link to the 
> component injected via activate and the ComponentContext (getProperties).
> 
> I disagree about @Referece to ConfigurationAdmin: in some use cases, it makes 
> sense. Look in Karaf Cellar for instance.
> 
> Regards
> JB
> 
> On 12/03/2017 01:10 PM, Timothy Ward wrote:
>>> I would more recommend a ManagedService or inject the ConfigAdmin service.
>> This is really bad advice, and Steinar should definitely not do either of 
>> these things (nor should other readers of this mail chain).
>>  * Steinar has already indicated that he wants to use Declarative Services, 
>> so
>>    implementing ManagedService is both unnecessary and ties him to an API 
>> that
>>    he has no need to implement. It also prevents him from using Component
>>    Property Types, defaults, annotations, and forces him to use Dictionary 
>> for
>>    his configuration. Finally, it also makes his component’s lifecycle
>>    management harder, as he would have to manage all the reconfiguration
>>    dynamics himself.
>>  * Injecting the Config Admin service is inevitably the wrong way for any 
>> user
>>    to read configuration in OSGi. The only people who should ever access the
>>    ConfigurationAdmin service directly are management agents like Felix File
>>    Install and Felix Web Console (and whatever component in Karaf does the 
>> same
>>    job).
>> The correct way to consume configuration in DS is to receive it via your 
>> activate method - if you think that you need to do something else then you 
>> have most likely got the wrong design.
>> If you’re not using DS then most component frameworks still provide you with 
>> configuration in a similar way (injection of a map). If you’re determined to 
>> do things the hard way (without a framework) then, and only then, should you 
>> implement ManagedService or ManagedServiceFactory, and you should absolutely 
>> never try to consume your configuration directly from the Configuration 
>> Admin service (it’s simply not designed to be used this way).
>> Regards,
>> Tim
>>> On 3 Dec 2017, at 10:41, Jean-Baptiste Onofré <j...@nanthrax.net 
>>> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net 
>>> <mailto:j...@nanthrax.net>>> wrote:
>>> 
>>> I would more recommend a ManagedService or inject the ConfigAdmin service.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 12/03/2017 09:41 AM, Steinar Bang wrote:
>>>> What's the recommended way for an OSGi bundle running inside karaf to
>>>> access its configuration?
>>>> Get an OSGi service of type ConfigMBean[1]?
>>>> Get an OSGi servie of type ConfigRepository[2]?
>>>> Or maybe avoid karaf dependencies, and get an OSGi service of type
>>>> ConfigurationAdmin[3]...?
>>>> Does anyone know of code examples of any of the three approaches?
>>>> Preferrably DS w/annotation based code examples?
>>>> Thanks!
>>>> - Steinar
>>>> References:
>>>> [1] 
>>>> <https://github.com/apache/karaf/blob/master/config/src/main/java/org/apache/karaf/config/core/ConfigMBean.java>
>>>> [2] 
>>>> <https://github.com/apache/karaf/blob/master/config/src/main/java/org/apache/karaf/config/core/ConfigRepository.java>
>>>> [3] 
>>>> <https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html>
>>> 
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org <mailto:jbono...@apache.org> 
>>> <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>> Talend - http://www.talend.com <http://www.talend.com/>
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org <mailto:jbono...@apache.org>
> http://blog.nanthrax.net <http://blog.nanthrax.net/>
> Talend - http://www.talend.com <http://www.talend.com/>

Reply via email to