Hi Am 03.02.2014 um 10:03 schrieb Chetan Mehrotra <[email protected]>:
> 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. Yes > Would that mean framework would be bought down to level 1 and > restarted again no, but … all logging would be "disabled and would have to be reconfigured" if the commons log bundle is refreshed … So the question really is: what happens to the logger instances held by the bundles …. Regards Felix > Chetan Mehrotra > > > On Mon, Feb 3, 2014 at 2:21 PM, Felix Meschberger <[email protected]> wrote: >> Hi >> >> Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra <[email protected]>: >> >>> 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
