Hi

Am 11.09.2013 um 15:36 schrieb Tommaso Teofili:

> Thanks a lot Chetan, that helps a lot!
> 
> In the mentioned link it seems both ConfigurationFactory and 
> ManagedServiceFactory could be used for that purpose, do you know if there is 
> any difference / advantage / disadvantage of using one instead of the other? 

I think you are mixing concepts ;-)

The "configurationFactory" attribute to the @Component annotation is 
information to the Apache Felix SCR plugin on how to generate the Metatype 
descriptor (to use the component name as the factoryPID instead of the service 
PID) -- as such this has nothing to do with the core problem but is used to be 
able to describe configuration for tools such as the Web Console.

The mechanism actually used is so-called factory configuration. This is 
achieved in conjunction with the OSGi Installer when your configuration nodes 
have specific names of the form <factoryPid>-<alias>, e.g. 
"com.adobe.granite.monitoring.impl.ScriptConfigImpl-cpu".

This creates factory configurations and Declarative services will create an 
instance for each configuration instance.

Regards
Felix

> 
> Regards,
> Tommaso
> 
> On 11/set/2013, at 11:53, Chetan Mehrotra wrote:
> 
>> You can use Component based on ConfigurationFactory. Have a look at
>> [1] for one such example
>> 
>> [1] http://stackoverflow.com/a/15872131/1035417
>> Chetan Mehrotra
>> 
>> 
>> On Wed, Sep 11, 2013 at 3:05 PM, Tommaso Teofili <teof...@adobe.com> wrote:
>>> Hi all,
>>> 
>>> that's probably a trivial question but I'm looking for the best practice to 
>>> create and register OSGi Services from configurations.
>>> Here's an example scenario:
>>> - I have an interface FooBar
>>> - I have an implementation DefaultFooBarImpl
>>> - I want to be able to specify a node like:
>>> {
>>>   "jcr:primaryType" : "sling:OsgiConfig",
>>>   "name" : "foo"
>>>   "property-one" : "some-value",
>>>   "property-two" : "another-value",
>>> }
>>> - and consequently I'd like a new instance of DefaultFooBarImpl to be 
>>> created and registered as a Service (of course implementing FooBar)
>>> - then if a new configuration node is added:
>>> {
>>>   "jcr:primaryType" : "sling:OsgiConfig",
>>>   "name" : "bar"
>>>   "property-one" : "some-other-value",
>>>   "property-two" : "yet-another-value",
>>> }
>>> - another instance of DefaultFooBarImpl is created and registered as a 
>>> Service.
>>> 
>>> From my basic understanding (which may be obviously completely wrong) it 
>>> seems to me that the best fit for my use case would be using 
>>> ManagedServices [1] but I'm not too sure I should do that to handle 
>>> multiple instances.
>>> 
>>> Thanks in advance and have a nice day,
>>> Tommaso
>>> 
>>> [1] : 
>>> http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
>>> 
>>> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to