You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2014/02/03 09:41:13 UTC
[osgi] Using Inventory API in Commons Log
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?
Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Feb 3, 2014 at 4:31 PM, Felix Meschberger <fm...@adobe.com> wrote:
> (Or semi-officially by just silently supporting it ?)
>
> Patches welcome.
Sure. Added that to ToDo list!!
Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 03.02.2014 um 11:24 schrieb Chetan Mehrotra <ch...@gmail.com>:
> On Mon, Feb 3, 2014 at 3:50 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Well, officially, ConfigurationPrinter does not support JSON, but you can write JSON as TXT output
>
> I can ... but rendering JSON in TXT does not look pretty!!. Probably
> it can be officially made to support json.
(Or semi-officially by just silently supporting it ?)
Patches welcome.
Regards
Felix
Re: [osgi] Using Inventory API in Commons Log
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Feb 3, 2014 at 3:50 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Well, officially, ConfigurationPrinter does not support JSON, but you can write JSON as TXT output
I can ... but rendering JSON in TXT does not look pretty!!. Probably
it can be officially made to support json.
Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Well, officially, ConfigurationPrinter does not support JSON, but you can write JSON as TXT output
Regards
Felix
Am 03.02.2014 um 11:01 schrieb Chetan Mehrotra <ch...@gmail.com>:
>> Yes, that probably is the consequence and we should refrain from adding Inventory API binding -- unless the commons log bundle exports the inventory API itself
>
> Well I required Inventory API to expose the logback state in JSON
> format (not that strong requirement though). Currently WebConsole
> supports Configuration Printer which do not explicitly implement
> Inventory API i.e. it supports any class which provides a method like
> [1] with some service properties. However that mode looks like does
> not support json mode. If it can support that then there is no string
> need for using Inventory API
>
> public void printConfiguration(PrintWriter printWriter)
> Chetan Mehrotra
>
>
> On Mon, Feb 3, 2014 at 3:11 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi
>>
>> Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra <ch...@gmail.com>:
>>
>>> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>>> So the question really is: what happens to the logger instances held by the bundles ....
>>>
>>> Before answering that I need to confirm would a new classloader be
>>> created for Commons Log upon package refresh? Probably yes then it
>>> that case existing Logger instances would be referring to old
>>> classloader. The other bundle would be bound to Sl4j API so they would
>>> not be refreshed but there logger instances would be referring to
>>> Logback provided classes.
>>>
>>> So one should probably avoid external dependency for a bundle like Commons Log?
>>
>> Yes, that probably is the consequence and we should refrain from adding Inventory API binding -- unless the commons log bundle exports the inventory API itself...
>>
>> On the other hand: considering both the Inventory and the Web Console API to be crucial, it might be conceivable to create API only bundles for these...
>>
>> Regards
>> Felix
>>
>>>
>>> Chetan Mehrotra
>>
Re: [osgi] Using Inventory API in Commons Log
Posted by Chetan Mehrotra <ch...@gmail.com>.
> Yes, that probably is the consequence and we should refrain from adding Inventory API binding -- unless the commons log bundle exports the inventory API itself
Well I required Inventory API to expose the logback state in JSON
format (not that strong requirement though). Currently WebConsole
supports Configuration Printer which do not explicitly implement
Inventory API i.e. it supports any class which provides a method like
[1] with some service properties. However that mode looks like does
not support json mode. If it can support that then there is no string
need for using Inventory API
public void printConfiguration(PrintWriter printWriter)
Chetan Mehrotra
On Mon, Feb 3, 2014 at 3:11 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra <ch...@gmail.com>:
>
>> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
>>> So the question really is: what happens to the logger instances held by the bundles ....
>>
>> Before answering that I need to confirm would a new classloader be
>> created for Commons Log upon package refresh? Probably yes then it
>> that case existing Logger instances would be referring to old
>> classloader. The other bundle would be bound to Sl4j API so they would
>> not be refreshed but there logger instances would be referring to
>> Logback provided classes.
>>
>> So one should probably avoid external dependency for a bundle like Commons Log?
>
> Yes, that probably is the consequence and we should refrain from adding Inventory API binding -- unless the commons log bundle exports the inventory API itself...
>
> On the other hand: considering both the Inventory and the Web Console API to be crucial, it might be conceivable to create API only bundles for these...
>
> Regards
> Felix
>
>>
>> Chetan Mehrotra
>
Re: [osgi] Using Inventory API in Commons Log
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra <ch...@gmail.com>:
> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> So the question really is: what happens to the logger instances held by the bundles ....
>
> Before answering that I need to confirm would a new classloader be
> created for Commons Log upon package refresh? Probably yes then it
> that case existing Logger instances would be referring to old
> classloader. The other bundle would be bound to Sl4j API so they would
> not be refreshed but there logger instances would be referring to
> Logback provided classes.
>
> So one should probably avoid external dependency for a bundle like Commons Log?
Yes, that probably is the consequence and we should refrain from adding Inventory API binding — unless the commons log bundle exports the inventory API itself…
On the other hand: considering both the Inventory and the Web Console API to be crucial, it might be conceivable to create API only bundles for these…
Regards
Felix
>
> Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
> So the question really is: what happens to the logger instances held by the bundles ....
Before answering that I need to confirm would a new classloader be
created for Commons Log upon package refresh? Probably yes then it
that case existing Logger instances would be referring to old
classloader. The other bundle would be bound to Sl4j API so they would
not be refreshed but there logger instances would be referring to
Logback provided classes.
So one should probably avoid external dependency for a bundle like Commons Log?
Chetan Mehrotra
Re: [osgi] Using Inventory API in Commons Log
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 03.02.2014 um 10:03 schrieb Chetan Mehrotra <ch...@gmail.com>:
> 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 <fm...@adobe.com> wrote:
>> Hi
>>
>> Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra <ch...@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
Re: [osgi] Using Inventory API in Commons Log
Posted by Chetan Mehrotra <ch...@gmail.com>.
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 <fm...@adobe.com> wrote:
> Hi
>
> Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra <ch...@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
Re: [osgi] Using Inventory API in Commons Log
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 03.02.2014 um 09:41 schrieb Chetan Mehrotra <ch...@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