Hi all, Although I do acknowledge Graham's point that if Util gets refactored into a number of separate modules that we will end up with additional modules for logging again, I'm not sure how realistic the need for this is in the medium-long term, I would say we cross that bridge when we get there :)
As an Enterprise OSGi Component project it seems natural to me that Aries would natively support the OSGi LogService. Having a solution in Aries Util could address the needs of everyone on the thread (except for those who are totally against adding a layer here): * It could connect to SLF4J, if available, in which case the ultimate logged message would end up exactly as it is today (addressing Mark and David J's requirements). * It could connect to the OSGi LogService, if available, addressing my use-case. * It could capture the current classname when the logger is object is contructed. When bound to SLF4J this is simply passed on to SLF4J, but in the case of the OSGi LogService it can be prefixed to the log messages sent to it effectively adding this feature to the OSGi LogService. * It can provide a more user-friendly API than the OSGi LogService - I'm thinking similar to SLF4J debug(), info(), warn() etc (addressing Guillaumes' point). * Other bridges (e.g. for java.util.logging) could be provided too. It would not add any additional mandatory imports to Aries Util and would remove the mandatory dependency on SLF4J. Some of the suggestions here are how I can make my usecase work with SLF4J. This is not my problem. As stated before, my main interest is in reducing mandatory dependencies. I'm happy to come up with an actual prototype for this... Best regards, David On 1 February 2012 17:16, David Jencks <[email protected]> wrote: > AFAICT no one disputes that slf4j has more capabilities than LogService > (logging per category/class). > > Slf4j is designed as a minimal logging interface with easliy pluggable > backends, and its really widely used as such. > > I'm strongly in favor of keeping using slf4j. > I'm strongly against duplicating slf4j in an aries package. > > David B, since your logging backend already has several adaptation > capabilities, can you add the slf4j-api classes to your logging backend along > with adapter classes like pax-logging? > > -rw-rw-rw- 11150 10-Jan-2012 16:41:00 > org/ops4j/pax/logging/slf4j/Slf4jLogger.class > -rw-rw-rw- 2622 10-Jan-2012 16:41:00 > org/ops4j/pax/logging/slf4j/Slf4jLoggerFactory.class > -rw-rw-rw- 2205 10-Jan-2012 16:41:00 > org/ops4j/pax/logging/slf4j/Slf4jMDCAdapter.class > > This is what pax-logging does. Maybe it's possible to leave out some of the > slf4j api classes, I didn't look. > > thanks > david jencks > > On Feb 1, 2012, at 7:43 AM, David Bosschaert wrote: > >> On 1 February 2012 15:29, Felix Meschberger <[email protected]> wrote: >>> Hi, >>> >>> Am 01.02.2012 um 14:53 schrieb David Bosschaert: >>> >>>> 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. >>> >>> Got it. >>> >>> In my setup I already use SLF4J (and LogService and Log4J and Commons >>> Logging). Adding yet another logging API just adds another dependency to my >>> setup and adds CPU consumption and learning curve experiences and makes my >>> users wonder. >> >> Well, if Aries has a small log API in its util component that wouldn't >> add any dependencies, because most things in Aries already depend on >> util. >> That component could then delegate to SLF4J, the OSGi LogService or >> whatever bringing only those dependencies in that are actually used. >> So for your use-case you should still be able to use it with SLF4J, >> but for my usecase I don't need to. >
