[slf4j-dev] Beta 4 and the new method signatures

[Endre Stølsvik]

Interesting, and surely a good point with the programmers not knowing what 
to log where, or (basically?) what will become debug output, and what will 
become info..

But I'm not sure I agree, though! A log-statement that is output on every 
iteration of a loop, where the iteration-part isn't anything important of 
the algorithm in question at all, will never become informational stuff. 
The programmer -will- know this when developing the code.

And, how would the programmer know what to name his loggers, or how many 
loggers to make, if more than one?

Lets boil it a bit down here:

Basically, you suggest having -two- separate axis-aspects, then?

The first is still the Logger's "name" (or "category), and the second is 
this multi-dimensional Axis-thing, right? That they both have "getName()" 
is a give-away, kinda..!

Why couldn't the axis-thing be merged back into the category-tree, 
instead? See, each axis here could simply be viewed as a separate (main, 
top) branch of the one category tree, and its branches again are the 
elements (colors, levels).
  You then allow for one Logger to be attached to multiple spots in this 
resulting tree.

What is the main benefit of having a separate Axis-aspect taking care of 
the "multitude" of such attachments?

|
| So, I could(!) create one Axis for the equivalent of "Level", where "Current" 
| is one of the discussed method levels; "fatal", "error", "warning", "info", 
| "debug", "trace". And that when the Logger is assigned to the Axis, its Level 
| is given as an argument. You want 45 level granularity, be my guest. And the 
| single levelAxis.setCurrent( "debug" ) could set the entire application in 
| debug mode, or parts of the application in debug mode. See my point??
| 
| I can create the the "Ignore" axis with a simple "on" and "off" settings, or 
| with "off", "quiet" and "verbose" if I like to.
| 
| I can create the "Color" axis, no blood, sweat and tears, the original 
| developer wouldn't even know it could be conceived.
| 

How do you set part of the system in debug mode? You'd have to go on the 
category-name, right? (See, I -like- the "Category" idea. One have a 
Logger, and that Logger has a (or several) Category it logs to.).

What if you want -two- "Axes" to "intersect" before an Appender is 
activated? I want the "green debug" to go here, while the "black info" 
goes here..

The problem, as I still perceive it, is that you'd end up with some 
rule-language as of which log-lines goes where. And it'll be cool, but 
hell to configure, IN PARTICULAR with the all-important "level" axis - I 
am still certain that levels are in a truly separate category of 
important-ness and 
"all-logstatements-will-need-a-place-on-this-particular-axis"-ness.

|
| If I somehow could hand out one Logger per instance, I can also create the 
| equivalents of NDC/MDC in Log4J, per user, per application or whatever I 
| want, without(!) changing the application code, or asking them to follow some 
| particular pattern.

I don't think I got this one.

Is the point that the code is "given" the Logger, instead of creating it 
itself, in an interesting IoC pattern? Okay, who decides the names then? 
And you'd surely have to give a largish library a whole bunch of loggers, 
wouldn't you? The method signature for init of your PNG-library would have 
45 Loggers defined, each parameter-name defining what would be put into 
the logger by the library??

Hmm.. Maybe you could give the library -one- Logger, and it'd make 
child-loggers off of that Logger? What if the library is used from several 
parts of the running code, where each of the parts are coded by different 
people, and they each give the library's log-init method a different 
Logger to fork children off? Okay, it would either have to be a 
"instantiatable library", or one would have to supply the Logger instance 
on each method invocation, but that would lead to a way to heavy Logger 
creation/fetching cycle...


PS: I don't know if I'm that fond of "make 45 levels, be my guest". 
Sometimes it IS good that a library strictly enforces a set of rules. If 
these are documentet -good- explaining the background and what and not, 
then the developer using the system will have a good set of boundaries to 
relate to and work off. Or else you'll actually end up with 45 levels, 
where the developer doesn't -quite- know how to use the system (they're 
obviously not documented at all), so some places, the levels contain 
contextual info about what is logged, some places they contain the 
"color", and so on - the concerns will be merged back and forth, and the 
end system will have no real, or at least not a obvious structure. Merging 
one such codebase with another (think library) will become interesting.
  (I'm rambling away here; please do note that sometimes I fade out into a 
kind of brain-storming session with myself, hoping that maybe you, the 
reader, would like to follow along..!)

PPS: Did you folks read the javadocs-suggestions/ideas? What do you think 
of the stuff there? Wouldn't it be good to have such strictish guidelines 
embedded in the javadoc? My point is still that -since- this is a 
-hardcoded- axis, then the ticks on that axis should have -really- good 
explainations.

| 
| Personally I get somewhat excited with the above. Time to go for a cold 
| shower, and return to reality. ;o)

;)

Regards,
Endre.