Re: Aspect questions?
markspace <-@.> wrote in news:jicc1d$er6$1@dont-email.me:
On 2/25/2012 3:22 PM, Arne Vajh?j wrote:
That looks as if you are almost building your own logging framework
on top of a logging framework.
That does not make much sense to me.
I can think of a use case for it though. Let's say you haven't decided
which logging framework to use, or you want to be flexible as to which
one to use. (Different customers of yours prefer different loggers.)
(Not syntax checked or tested.)
abstract class MyLogger {
public static MyLogger getLogger( String name ) {
MyLogger logger = Class.forName(
System.getProperty("me.mystuff.MyLogger.logImpl",
"me.mystuff.MyDefaultLogger" ).newInstance());
return logger;
}
public abstract void logStuff(Object...);
}
So the idea is that you wrap the logging framework in your own, and
then
you're free to provide an implementation that matches whatever logging
framework you choose to use in the future. Maybe this is not for
everyone, but I could see its advantages. Some folks might like
java.util.Logger, some folks like log4j. And some might like things
that I don't know about yet.
I wish I could say I was that clever but I'd be lying if I did.
I've simply been doing logging incorrectly. I don't even remember what
thought process got me doing things the way I do in my code. I worked
that technique out a few years ago, then had a gap away from Java for a
while and am finally revisiting a lot of my old code to do things the
proper way. Lew has convinced me it's not the right way to do things. Now
I'm trying to get a clear picture of what I SHOULD be doing so that I can
revise my code....
A couple of other things.
Lew wrote:
public class Foo
{
final Logger logger = getLogger(getClass());
[...]
}
This requires that a logger is instantiated for each object as it is
created. Potentially this is a lot of work, and each logger may not be
used. (Even declaring the logger to be static still requires a logger
per class loaded.)
Whereas this:
...
try {
... some stuff...
} catch (Exception ex) {
getLogger(getClass()).log( ... );
}
creates the logger lazily and therefore doesn't spend any resources if
logging happens to be never required.
Lastly, I don't know about log4j, but I don't think the
java.util.logging package uses threads when logging. Any IO operations
the logger makes will block the calling thread. I've heard this is
undesirable in most cases. So rolling your own framework also gives
you
control over threading issues too, which again might be important for
some customers.
--
Novice