aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [DISCUSS] Logging for Aries modules
Date Fri, 03 Feb 2012 11:45:05 GMT
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 <david.bosschaert@gmail.com>

> 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 <david_jencks@yahoo.com> 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 <fmeschbe@adobe.com> 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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message