On Fri, 2004-08-27 at 15:13, 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. The primary benefit of having all the libraries
Actually the logging monitor implementation would still be implemented
by the library developer as an optional peice. The user would not have
to write a logging implementation for the monitor interface. Say for
example the library is the dbcp library. It might expose the following
interface as part of the library:
public interface DBCPMonitor
{
connectionAcquired( ConnectionPool pool, Connection conn );
connectionReleased( ConnectionPool pool, Connection conn );
}
Obviously this is a very simplistic example so please bear with me. The
library developer would have a setMonitor(DBCPMonitor) or even an
addMonitor(DBCPMonitor) method on the connection pool class for example
to set the monitor used. The developer might implement a do-nothing
monitor adapter for the default monitor to use. When these events occur
in the connection pool the methods are called instead of handling
logging.
Outside of the distribution jar the developer might include several
monitor implementations one of which can be a C-L based logging monitor
which is dependent on C-L obviously. So the user does not have to
implement the logger at all.
Someone (possibly James Strachan) actually used this pattern in the
ThreadPool package within the Jakarta Commons Sandbox here:
http://jakarta.apache.org/commons/sandbox/threadpool/apidocs/index.html
Take a look at the ThreadPoolMonitor interface and the
NullThreadPoolMonitor. I don't think the author actually implemented a
logging monitor here but they could have and not included it with the
core classes going into the jar.
> 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.
Yes it does work but not everyone wants the dependency. This is the
core problem. I personally don't mind having the commons-logging
dependency. Just making a recommendation to solve a recurring topic on
this list.
> 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.
Regards,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
