On Fri, 27 Aug 2004 20:53:41 -0400, Alex Karasulu <[EMAIL PROTECTED]> wrote: > On Fri, 2004-08-27 at 15:13, Craig McClanahan wrote:
<snip/> > > 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? > > I disagree but I see where you're comming from. The fact that you're > logging makes you specific to a particular monitoring implementation so > this is not a "generic event listening framework". Furthermore I'm not > recommending we DO have a "generic event listening framework." Each > monitor is specific to the library. I'm just saying let libraries > publish/expose the notable events that external systems can respond to. > The monitor interface for any library, component etcetera accomplishes > that. What the user does with that is their business. Also while > exposing that monitor interface give the user interested in logging a > head start by offing a logging monitor based on C-L outside of your core > jar. If there isn't a standard way of doing this, doesn't that mean that each component (library) will end up doing it slightly differently? That, in turn, means that each component will have its own (optional) additional library that needs to be included just to add logging for that library. This seems like it would result in an explosion of jars - much worse than everyone just using Commons Logging, which is now so ubiquitous in any case. It also means that, if we decide to migrate a class from one component to another, the logging (sorry, monitoring ;) scheme needs to change to adhere to the conventions of the new component. Finally - and perhaps my biggest worry - performance would be negatively impacted by the additional calls, and by the lack of any ability to check the logging level before actually logging. (You can't have methods like isDebugEnabled() in a general purpose monitoring interface, after all.) IMHO, logging should be easy and cheap, so that developers put it wherever it could be useful. I can't tell you how many times I've wished that 3rd party code had more logging in it so that I could figure out why things weren't working as I expected. -- Martin Cooper > > Regards, > Alex > > > > > --------------------------------------------------------------------- > 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]
