You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Tommaso Teofili <te...@adobe.com> on 2013/09/11 11:35:40 UTC
Dynamically create and register OSGi services from configurations
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
Re: Dynamically create and register OSGi services from
configurations
Posted by Tommaso Teofili <te...@adobe.com>.
On 12/set/2013, at 08:35, Felix Meschberger wrote:
> 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.
thanks Felix for clarifying, I'll let you know how it goes.
Regards,
Tommaso
>
> 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 <te...@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
>>>>
>>>>
>>
>
Re: Dynamically create and register OSGi services from
configurations
Posted by Felix Meschberger <fm...@adobe.com>.
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 <te...@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
>>>
>>>
>
Re: Dynamically create and register OSGi services from
configurations
Posted by Tommaso Teofili <te...@adobe.com>.
Ok, great, thanks Chetan for clarifying, then it seems ConfigurationFactory is the right fit for my use case :)
Regards,
Tommaso
On 12/set/2013, at 06:16, Chetan Mehrotra wrote:
> Hi Tommaso,
>
> In general you should always use the ConfigurationFactory approach as
> it is lot more simpler and easy to use.
>
> ManagedServiceFactory is useful in few cases when you do not want your
> bundle to depend on any other service runtime apart from core OSGi
> framework. So suitable for infrastructure bundles like Logging ,
> WebConsole or other OSGi spec implementations etc
> Chetan Mehrotra
>
>
> On Wed, Sep 11, 2013 at 7:06 PM, Tommaso Teofili <te...@adobe.com> wrote:
>> 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?
>>
>> 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 <te...@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
>>>>
>>>>
>>
Re: Dynamically create and register OSGi services from configurations
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Tommaso,
In general you should always use the ConfigurationFactory approach as
it is lot more simpler and easy to use.
ManagedServiceFactory is useful in few cases when you do not want your
bundle to depend on any other service runtime apart from core OSGi
framework. So suitable for infrastructure bundles like Logging ,
WebConsole or other OSGi spec implementations etc
Chetan Mehrotra
On Wed, Sep 11, 2013 at 7:06 PM, Tommaso Teofili <te...@adobe.com> wrote:
> 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?
>
> 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 <te...@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
>>>
>>>
>
Re: Dynamically create and register OSGi services from
configurations
Posted by Tommaso Teofili <te...@adobe.com>.
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?
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 <te...@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
>>
>>
Re: Dynamically create and register OSGi services from configurations
Posted by Chetan Mehrotra <ch...@gmail.com>.
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 <te...@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
>
>