sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: [osgi] Using Inventory API in Commons Log
Date Mon, 03 Feb 2014 09:03:31 GMT
Thanks for the clarification Felix!

Just to confirm though ... if Inventory bundle is later
patched/refreshed it would then lead to refresh of Commons Log bundle
also. Would that mean framework would be bought down to level 1 and
restarted again
Chetan Mehrotra


On Mon, Feb 3, 2014 at 2:21 PM, Felix Meschberger <fmeschbe@adobe.com> wrote:
> Hi
>
> Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra <chetan.mehrotra@gmail.com>:
>
>> Hi,
>>
>> For SLING-3264 I was thinking to provide Inventory integration in
>> Commons Logs. However the Commons Log bundle starts at level 1 while
>> the Inventory bundle starts at Level 5. The log bundle would use the
>> ServiceFactory approach to expose the Inventory service and would not
>> have required dependency on Inventory API.
>>
>> So just wanted to confirm that would it be fine to depend on classes
>> from a bundle which starts at later start level or not?
>
> Sure. This is what we are using ServiceFactory and dynamic/delayed import all over places.
See for example the Configuration Admin binding the Apache Felix SCR bundle.
>
> So, what seems to boild down to kind of a best practice is to:
>
>   * use ServiceFactory for optional services
>   * use Import-Package with resolution:=optional to have
>       static wiring if possible
>   * use DynamicImport-Package to have dynamic wiring
>       on-demand
>
> It is just very important to thouroughly test this to not get inadvertend ClassNotFoundExceptions,
for example if the optional classes appear in the method signature of a required class (see
the ResourceResolverActivator.getFeaures() method which returns Object to work around this
issue).
>
> Regards
> Felix

Mime
View raw message