Hi David, why YALA? If you really are in need of the LogService, just use Pax-Logging. You can use any kind of Logging api you like, log4j, slf4j, etc.., you name it pax-logging got it. If there is still one missing, it's open source add it. I just do not understand why re-inventing the wheel does help here.
just my 2 cents here, Achim 2012/2/3 David Bosschaert <[email protected]> > 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. > > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
