logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Masterson" <m.master...@computer.org>
Subject RE: conversion patterns and caller class information
Date Sun, 06 Jun 2004 16:04:12 GMT
Hi Jake,

>>In each class that will use the monitor, I just provide a Monitor instance
variable.  I don't create the monitor in the class itself as is the normal
Log4j usage.<<

Yeah, okay, that makes sense for the *component*.  But how do you deal with
the chicken-and-egg problems that you're inevitably confronted with in the

Specifically, how do you deal with a need for the container to be able to do
things like logging during its *own* start-up and initialisation?  Who tells
the container how to log?

Once the container is up and running, the Monitor interface idea would
obviously work, but the container still has the original problem.  Arguably,
this is an appreciable gain, in and of itself - rather than 20 components
all individually having to worry about how to log while they're getting
their feet under them, now only the container has to deal with such issues.
But the issues are still there...  Aren't they?

Hmmm...  I suppose you could design Monitor implementations such that they
could be instantiated cleanly via reflection, and then one would just have
to have some meta-data source somewhere (properties file, deployment
descriptor, whatever) where one configured a property for the container's
"logging monitor"... But if one does this, I don't see how such a solution
is fundamentally different from the following, which is alleged to be a "bad
smell" on Pico Container's Web site...

public class AppleImpl implements Apple {
  private static Orange orange = OrangeFactory.getOrange();
  public Apple() {
  // other methods

Presumably, in this solution, "OrangeFactory" is reading the above-mentioned
meta-data source to find out what sort of "OrangeImpl" to create, and then
using reflection to do so.  So, if the container uses a similar trick to
parameterise its own, internal logging, isn't it still suffering from a bad


To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message