I went round-and-round with Berin a few months ago before he convinced me
on this point. The LogKit API provides a simple framework based on IoC
that "wraps" various loggers. It became clear that adding the popularly
used "pull" (Log4J, JDK 1.4, and other loggers) model to the Avalon LogKit
was counter to their design goals. At about the same time the commons
logging API was released.
Perhaps what we need is pointers (in both components) to the logger
supporting the "other" philosophy:
If you want "pull", use commons logging.
If you want "push" and IoC, use the Avalon LogKit.
And again, DON'T propose trying to merge the two, their goals are
orthogonal.
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
"Berin Loritsch"
<bloritsch@apach To: "'Jakarta Commons Developers
List'"
e.org> <[EMAIL PROTECTED]>
cc:
04/03/2002 01:32 Subject: RE: [logging] Need
interface...
PM
Please respond
to "Jakarta
Commons
Developers List"
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>
>
> On Wed, 3 Apr 2002 [EMAIL PROTECTED] wrote:
>
> >
> > The current model used in log4j, jdk1.4, etc is pull - you
> request a
> > logger by name. Same thing for jdbc connections, resources, etc.
> >
>
> In fact, there's an important philosophical issue about
> logging here as well -- who gets to choose the name of the
> logger (and therefore the log level)?
In IoC based apps, the container. period. That is what IoC
is all about. The container (or manager) makes all the decisions
about the component.
> The trend I've seen the most is that logger names are fine
> grained - often based on the fully qualified class name of
> the class that is doing the logging. This means that I can
> turn on debug logging on just my "foo" component, without
> having to turn on debugging info for all the components that
> are sharing the same Log instance. To say nothing of the
> fact that I can direct the log output from different
> components to different places ...
FQCN based logging is not fine enough :)
> Bottom line is that I would be unlikely to create components
> that implemented LogUser or whatever, even if it did get
> added. It takes away too much fine-grained control for my
> taste. The pattern I like is similar to what Jon quoted:
>
> public class MyComponent {
>
> private static Log log = LogFactory.getLog(MyComponent.class);
>
> public void hello() {
> log.info("Hello!");
> }
>
> }
The container chooses the fine grained name. Avalon makes the
balance quite well. In fact, we can have loggers that are by
functional unit--even below the class/component level.
>
> which creates a logger based on the fully qualified class name.
>
> Further, at least for Log4J and JDK 1.4 logging (and perhaps
> others) have nice inheritance rules about logging names, so
> that you could turn on debug level output for *all* Commons
> components that use this pattern by setting the level for
> "org.apache.commons" ...
LogKit also has those.
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
