You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <Fe...@day.com> on 2007/05/03 14:39:12 UTC
SCR and compendium services
Hi Richard,
In Felix-277 you propose to "privatize" the ServiceTracker and make the
LogService package a dynamic dependency. I think, this is a good idea and
will, as noted in the issue, implement this.
While doing this, there is another Compendium Service dependency in the scr:
Configuration Admin Service. This is a more complicated dependency because
scr does not only call into the ConfigurationAdmin service but also
registers a ManagedServiceFactory for factory components. So, if the OSGi cm
packages are not available, factory components will not work (and
configuration retrieval by other components may fail).
What do you think of having scr export and re-import the OSGi cm package ?
This way, the framework would select the cm package to which other bundles
get wired and scr will have the OSGi cm packages regardless of whether a CM
implementation exporting it is available.
Thanks for any feedback also from the community.
Regards
Felix
Re: SCR and compendium services
Posted by Clement Escoffier <cl...@gmail.com>.
Richard S. Hall a écrit :
> Clement Escoffier wrote:
>> Hello
>>
>> Felix Meschberger a écrit :
>>> Hi Richard,
>>>
>>> In Felix-277 you propose to "privatize" the ServiceTracker and make the
>>> LogService package a dynamic dependency. I think, this is a good
>>> idea and
>>> will, as noted in the issue, implement this.
>>>
>>> While doing this, there is another Compendium Service dependency in
>>> the scr:
>>> Configuration Admin Service. This is a more complicated dependency
>>> because
>>> scr does not only call into the ConfigurationAdmin service but also
>>> registers a ManagedServiceFactory for factory components. So, if the
>>> OSGi cm
>>> packages are not available, factory components will not work (and
>>> configuration retrieval by other components may fail).
>>>
>>> What do you think of having scr export and re-import the OSGi cm
>>> package ?
>>> This way, the framework would select the cm package to which other
>>> bundles
>>> get wired and scr will have the OSGi cm packages regardless of
>>> whether a CM
>>> implementation exporting it is available.
>> It is what I do for the Log service and the Config Admin in iPOJO. It
>> increase the size of the bundle but I did not find another acceptable
>> solution.
>> The pom file contains folowing BND instructions:
>> <Import-Package>
>> org.osgi.framework; version="1.3",
>> org.osgi.service.cm; version="1.2",
>> org.osgi.service.log; version="1.3"
>> </Import-Package>
>> <Export-Package>
>> org.apache.felix.ipojo; version="0.7.1",
>> ....... (some other iPOJO packages) .....
>> org.osgi.service.cm; version="1.2",
>> org.osgi.service.log; version="1.3"
>> </Export-Package>
>
> Shouldn't BND automatically detect the versions for you from the
> packageinfo files?
BND inserts versions for imported (and re-exported version), but does
not add version for non imported packages (In the previous snippet, BND
can add 1.3 and 1.2 version but cannot discover 0.7.1 version).
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: SCR and compendium services
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Clement Escoffier wrote:
> Hello
>
> Felix Meschberger a écrit :
>> Hi Richard,
>>
>> In Felix-277 you propose to "privatize" the ServiceTracker and make the
>> LogService package a dynamic dependency. I think, this is a good idea
>> and
>> will, as noted in the issue, implement this.
>>
>> While doing this, there is another Compendium Service dependency in
>> the scr:
>> Configuration Admin Service. This is a more complicated dependency
>> because
>> scr does not only call into the ConfigurationAdmin service but also
>> registers a ManagedServiceFactory for factory components. So, if the
>> OSGi cm
>> packages are not available, factory components will not work (and
>> configuration retrieval by other components may fail).
>>
>> What do you think of having scr export and re-import the OSGi cm
>> package ?
>> This way, the framework would select the cm package to which other
>> bundles
>> get wired and scr will have the OSGi cm packages regardless of
>> whether a CM
>> implementation exporting it is available.
> It is what I do for the Log service and the Config Admin in iPOJO. It
> increase the size of the bundle but I did not find another acceptable
> solution.
> The pom file contains folowing BND instructions:
> <Import-Package>
> org.osgi.framework; version="1.3",
> org.osgi.service.cm; version="1.2",
> org.osgi.service.log; version="1.3"
> </Import-Package>
> <Export-Package>
> org.apache.felix.ipojo; version="0.7.1",
> ....... (some other iPOJO packages) .....
> org.osgi.service.cm; version="1.2",
> org.osgi.service.log; version="1.3"
> </Export-Package>
Shouldn't BND automatically detect the versions for you from the
packageinfo files?
-> richard
>
> Regards,
>
> Clement
>
>
Re: SCR and compendium services
Posted by Clement Escoffier <cl...@gmail.com>.
Hello
Felix Meschberger a écrit :
> Hi Richard,
>
> In Felix-277 you propose to "privatize" the ServiceTracker and make the
> LogService package a dynamic dependency. I think, this is a good idea and
> will, as noted in the issue, implement this.
>
> While doing this, there is another Compendium Service dependency in
> the scr:
> Configuration Admin Service. This is a more complicated dependency
> because
> scr does not only call into the ConfigurationAdmin service but also
> registers a ManagedServiceFactory for factory components. So, if the
> OSGi cm
> packages are not available, factory components will not work (and
> configuration retrieval by other components may fail).
>
> What do you think of having scr export and re-import the OSGi cm
> package ?
> This way, the framework would select the cm package to which other
> bundles
> get wired and scr will have the OSGi cm packages regardless of whether
> a CM
> implementation exporting it is available.
It is what I do for the Log service and the Config Admin in iPOJO. It
increase the size of the bundle but I did not find another acceptable
solution.
The pom file contains folowing BND instructions:
<Import-Package>
org.osgi.framework; version="1.3",
org.osgi.service.cm; version="1.2",
org.osgi.service.log; version="1.3"
</Import-Package>
<Export-Package>
org.apache.felix.ipojo; version="0.7.1",
....... (some other iPOJO packages) .....
org.osgi.service.cm; version="1.2",
org.osgi.service.log; version="1.3"
</Export-Package>
Regards,
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
Re: SCR and compendium services
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think that sounds reasonable, this is a good use case for
importing/exporting the same package...
As Clement noted, you could use the same approach for the log service if
you prefer to have a consistent approach, since I imagine the bloat is
negligible.
Either way, I am fine with it.
-> richard
Felix Meschberger wrote:
> Hi Richard,
>
> In Felix-277 you propose to "privatize" the ServiceTracker and make the
> LogService package a dynamic dependency. I think, this is a good idea and
> will, as noted in the issue, implement this.
>
> While doing this, there is another Compendium Service dependency in
> the scr:
> Configuration Admin Service. This is a more complicated dependency
> because
> scr does not only call into the ConfigurationAdmin service but also
> registers a ManagedServiceFactory for factory components. So, if the
> OSGi cm
> packages are not available, factory components will not work (and
> configuration retrieval by other components may fail).
>
> What do you think of having scr export and re-import the OSGi cm
> package ?
> This way, the framework would select the cm package to which other
> bundles
> get wired and scr will have the OSGi cm packages regardless of whether
> a CM
> implementation exporting it is available.
>
> Thanks for any feedback also from the community.
>
> Regards
> Felix
>