My issue with it is that it brings in 2 dependencies: the SLF4J api and an SLF4J implementation bundle. In the context where I want to use the JNDI component there is already a log subsystem in place, which can be reached through the OSGi LogService, so adding those 2 SLF4J bundles brings in dependencies that appear like noise.
I would like components to have minimal dependencies which makes them more suitable for reuse in different contexts. Although I'm not a big fan of yet-another-logging-abstraction-layer, if we do the logging through an API in the Aries Util component which then forwards to whatever is configured with it I think it can satisfy everybody's needs, although I'm open to other suggestions... On 1 February 2012 13:16, Graham Charters <[email protected]> wrote: > Hi David, > > Could you clarify the issues with SLF4J? It would seem we could end > up replacing one logging wrapper API with our own. You mentioned you > require two bundles that are unnecessary. Is their size an issue? Is > there some refactoring that could be done in SLF4J to improve the > situation? Could your own logging sit behind SLF4J or does this cause > other issues? > > Regards, Graham. > > On 1 February 2012 12:38, Guillaume Nodet <[email protected]> wrote: >> Because the osgi log service has a crappy api which is too limited ? >> >> On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <[email protected]> wrote: >>> Hi >>> >>> Really ? YALA ? >>> >>> Why not just settle all Aries on LogService (maybe even through some >>> utility to guard against LogService being away) or SLF4J ? >>> >>> Regards >>> Felix >>> >>> Am 01.02.2012 um 12:51 schrieb David Bosschaert: >>> >>>> Yes, I'd like to have something that has minimal dependencies, but >>>> putting it in Aries Util is fine with me as most components depend on >>>> that anyway. >>>> >>>> While working with the LogService I put some code that I found in the >>>> Aries JMX component that makes working with the OSGi LogService easier >>>> in Util. You can find it here: >>>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java >>>> >>>> Maybe we can extend this class to provide a simple API that provides >>>> all the needed inputs for all uses (including classname-based >>>> initialization) so it can delegate appropriately. >>>> >>>> David >>>> >>>> On 1 February 2012 11:05, Graham Charters <[email protected]> wrote: >>>>> Guillaume's starter.... >>>>> >>>>> "Can't we simply do something in aries until that would be shared by >>>>> all aries modules (since they kinda all depend on it already) ? >>>>> A very small api that could be configured to either use slf4j, jul or >>>>> osgi logging ? Using optional imports, it should limit to what's >>>>> available and default to a good one, falling back to jul if nothing" >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Guillaume Nodet <[email protected]> >>>>> Date: 1 February 2012 10:46 >>>>> Subject: Re: Aries JNDI dependencies >>>>> To: [email protected] >>>>> >>>>> >>>>> Can't we simply do something in aries until that would be shared by >>>>> all aries modules (since they kinda all depend on it already) ? >>>>> A very small api that could be configured to either use slf4j, jul or >>>>> osgi logging ? Using optional imports, it should limit to what's >>>>> available and default to a good one, falling back to jul if nothing >>>>> else. >>>>> >>>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert >>>>> <[email protected]> wrote: >>>>>> Hi all, >>>>>> >>>>>> On 1 February 2012 09:58, Graham Charters <[email protected]> wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Prior to these changes, Apache Aries had the ability to filter logging >>>>>>> per class, and this was consistent across all Aries modules. >>>>>> >>>>>> Well apparently not because the Aries JMX component used the >>>>>> LogService already... >>>>>> >>>>>>> I don't >>>>>>> think we should be doing piecemeal infrastructure dependency changes >>>>>>> like these without a proper consideration. >>>>>> >>>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm >>>>>> asking for opinions re removing to the LogService and that the >>>>>> responses where positive... >>>>>> >>>>>>> Although nobody really wants to have a logging conversation, I don't >>>>>>> think we can avoid one, and until then, I think we need to go back to >>>>>>> the consistent approach that, until now, Aries consumers seemed happy >>>>>>> with. >>>>>> >>>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those >>>>>> changes for the moment. >>>>>> >>>>>> @David J: we can explore the capabilities of the log service in that >>>>>> discussion. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> David >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------ >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> FuseSource, Integration everywhere >>>>> http://fusesource.com >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> FuseSource, Integration everywhere >> http://fusesource.com
