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 10:01:24 GMT
> 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 <fmeschbe@adobe.com> wrote:
> Hi
>
> Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra <chetan.mehrotra@gmail.com>:
>
>> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <fmeschbe@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
>

Mime
View raw message