At 05:45 PM 7/11/2005, Greg Wilkins wrote:
Ceki,
it's good to participate in a receptive discussion.... even if the end product
is to keep the current API as it is.
:-)
I kind of consider that the only true method in this API is
log(String) and the others are just conveniance methods for
effecient formatting.
Me: nods in approval.
So I do think that log(String) is appropriate for a request log,
as is isEnabled(). I could even make a case for log(String,Throwable)
if I was to have a request log that did not conform to NCSA format.
I could also live with log(Object) as the fundamental methed,
but slf4j appears to take that approach that logs are for strings not objects.
Yes, developer logs are for strings, not objects; a choice with not so
innocuous implications.
Even if log(Object) existed as the printed basic method, I believe
that one could not build interchangeable logging systems for different
purposes all adhering to the same abstract (as your simple Log) API. This is
not to say that such systems could not be built. They obviously
can. However, I think they cannot share the same client API, although
they may perhaps share components.
The scope of SLF4J API does not cover request logs. As I see and
understand the general problem of logging, it is impossible to come up
with a single client API to cover all use cases. By the way, I
encourage everyone to prove me wrong.
[snip]
I still think it is a good question to ask - why does the current API
force the same scope on debug, info, warn and error?
Is it just for simpicity of usage or is there another reason to tie
their scopes together?
Because for developer logs, the ordered level and hierarchical logger
paradigm covers a lot of ground. As you mentioned, however, it cannot
be generalized to suit other contexts.
Hence my suggestion of looking for a way to do both. The current "fat" API
is perfect for 90% of common usage give or take a few niggles about trace.
But because of it's fatness it is difficult to extend and uncomfortable to
use in some use-cases. So if there is a layer that we can peal off the
"fat"
API and reveal an underlying "thin" API then that can be used for the more
complex use-cases.
So the question is - is there such an underlying "thin" API? and is there
enough need for it to make it worth the complexity of exposing it?
Good question. In my humble opinion, the various use cases cannot be
abstracted into a nice, generic and highly abstracted API. Needless to
say, it would be extremely nice if such an API existed.
--
Greg Wilkins <[EMAIL PROTECTED]>
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
