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.
