commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [general] logging
Date Fri, 27 Aug 2004 20:17:28 GMT

+1. I don't see any advantage to the commons-monitor approach as it would
still involve a dependency and would probably be harder to code than
simple logging.

Is there an easy way to produce a jar stripped of its logging parts? Any
of the bytecode-manip/aspect systems that could do it?

Hen

On Fri, 27 Aug 2004, matthew.hawthorne wrote:

> Craig McClanahan wrote:
> > On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <aok123@bellsouth.net> wrote:
> >
> >>However I think this issue is one we can resolve if we generalize the
> >>problem using monitors and event notification.  Logging is just a
> >>specific application for a monitor. Paul Hammant described this in the
> >>NoLogging wiki here:
> >>
> >>http://wiki.apache.org/avalon/AvalonNoLogging
> >>
> > The problem I have with this general approach is that it trades a
> > dependency on a logging adapter for a requirement to create code that
> > responds to the individual event handling interface for every single
> > library I'm using.
>
> This is only a requirement if you have a need to get details about what
> the library is doing.  In most cases, I don't -- but I obviously can't
> speak for
> everyone else.
>
> Logging (via commons-logging) has become pretty much a standard part
> of development for me.  But for those for which this is not the case,
> I don't see implementing a simple monitor interface to handle events
> as much harder than putting log4j into the classpath, setting up
> the config file to log for the desired class, etc.  Either way requires
> some extra work.
>
>
> > The primary benefit of having all the libraries
> > conform to a common logging API (whatever it is) is *precisely* the
> > fact that I, as an application developer, don't have to go through
> > that kind of pain -- I just configure the logging levels and
> > destinations, using my favorite logging implementation (using a single
> > log for everything, separate logs for functional areas, requesting the
> > appropriate amount of detail on a global or local level, or whatever
> > else I want), and it just works.
>
> I guess I always saw the primary benefit and purpose of commons-logging
> to be
> a bit simpler than this.  I thought it was to allow libraries to log,
> while allowing the user
> to choose which logging library is used -- nothing more.
>
> However, what you've said may indeed be true -- the issue is whether
> what works best
> for you works best for everyone else.  I'm fine with everything using
> commons-logging,
> but that's because I use it in pretty much every project I'm on anyway.
>   For others,
> it may cause more of an inconvenience, although I'm not quite sure how.
>   Too many jars, maybe.
>
>
> > My concern can be dealt with by implementing a commone event monitor
> > API that all the libraries use, so that I can still implement a
> > generic event listening framework ... but isn't that, in spirit
> > (although not in the proposed implementation manner), exactly what
> > commons-logging already does?
>
> Very true -- but I don't think this is what anyone was proposing.
> If this was the idea, then, just as you've said, I think commons-logging
> does the job fine.
>
> No need for commons-monitor or anything weird like that...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message