> 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 <[email protected]> wrote: > Hi > > Am 03.02.2014 um 10:30 schrieb Chetan Mehrotra <[email protected]>: > >> On Mon, Feb 3, 2014 at 2:54 PM, Felix Meschberger <[email protected]> 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 >
