+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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
