On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu <[EMAIL PROTECTED]> wrote:
The problem I have with this general approach is that it trades aHowever 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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
