On Feb 9, 2004, at 7:30 PM, Nathan Bubna wrote:
Geir Magnusson Jr said:On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:...Sorry if I have been vague :) I'm arguing for dropping LogSystem in favour of c-l. What you are proposing is an adapter to the adapter - and that, IMO, is silly.
it would be entirely silly if c-l was just an adapter, in the sense of
a common interface. But it isn't. It's a logging system in itself, as
well as a logging implementation finder, which is more than an adapter.
i must disagree. my understanding and experience is that c-l is designed and
intended to be an adapter. from the c-l site itself, "The Logging package is
an ultra-thin bridge between different logging libraries." how do you read
that?
Like you read it. But it's not the whole story. It's also a logger too, as it includes one, o.a.c.impl.SimpleLog
This really is besides the point, btw :)
......How do you access features of log4j that aren't in the logger interface?Oh, just answer the question.... You were arguing that c-l's lcd approach to logging is quite sufficient.
you left off two very key words. you should've said "...quite sufficient
<em>for middleware</em>" that distinction is absolutely critical here and it
is frustrating that you frequently ignore it.
It's actually a new meme in the last two messages, trying now to distinguish between middleware and application software.
And I don't get the point. Define middleware... I think of things like message brokers, containers, and such to be middleware, and quite frankly, I think adding containers is a stretch.
I ask you, how do you take
advantage of new features in logging systems? The answer is you can't.
that's not true at all!
i can and do take advantage of new, non-commons-logging features in log4j in
my applications that use components that depend on c-l. Struts and all of
it's commons cohorts use c-l, and i know that both myself and others who use
Struts simply point c-l to log4j for our applications and are able to use NDC
and all those other wonderful log4j toys in our applications without problem.
So you skip c-l and just use log4j? I've must have just plain missed the c-l API's that allow you to safely use a specific logging system like that.
...I think you need to be clear here. I prefer when my middleware is logs
to it's own logging. I don't want middleware logging into my logs. I
experience nothing but annoyance when things like JMS client libraries
(a true middleware) barf into my logs of high level app info. (and
yes, I know that w/ log4j, I just configure to put middleware spew into
a separate log...)
ah ha! here we have a genuine disagreement. you want components to log
separately by default (without having to tell log4j to do it), and i/we do
not. i want my components' log output to stay together unless i tell them to
be separate. i see no recourse for us here but to agree to disagree.
If you want to phrase it that way, sure. I see that we just have different preferences, and both should be easily supported in anything we do.
I prefer components to just shut up and do their job, and thow an exception or indicate problems w/ a return value.
(And note that you changed subject, from middleware to components. I don't consider my JMS broker a component, in the sense that httpclient is a component.)
...But I'd also be happy to do something like
Middleware m = new Middleware(middlewareLogger);
This sort if insertion of dependencies is a PERFECTLY VALID if I want to do it that way (see recent rage of lightweight IoC containers, for example).
I'd also like to be able to do things like :
Middleware m1 = new Middleware(middlewareLogger1); Middleware m2 = new Middleware(middlewareLogger2);
yeah, while it may be possible with c-l, it would probably be sketchy. so, i
agree, c-l is not designed for this pattern. of course, neither is log4j (i'm
less sure about LogKit or jdk1.4 since i don't use them). so, all question of
technical merit aside, as far as i can see, this is a less common pattern.
It's a less common pattern, but still an important and valid one. I think as we see people moving from heavyweight to lightweight containers, you'll start to see this sort of injection pattern more and more.
For example, you could have a container (there are some that do this, like pico) that will look at the CTORs and available component classes, and construct what it can from what's it's been given.
So you could have
public class Foo {
public Foo(MyLogger logger) {
...
}
}and a class
public class DevNullLogger implements MyLogger {
...
}and then tell the container that it has a Foo, a DevNullLogger, and to go to town and figure things out....
IMO, this is a good pattern.
Or...
Middleware m = new Middleware(null);
to shut off the logging when i don't care.
How do I do that w/ c-l?
while this is not _how_ you would shut off logging with the c-l/log4j pattern,
it is still quite easy to silence logging with them as well.
A code sample would be wonderful. (Not a configuration sample, please)
geir
Nathan Bubna [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
