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

[Niclas Hedhman]

On Thursday 07 July 2005 15:57, Endre Stølsvik wrote:

First off, I don't have all the answer. A lot is just gut feeling. ;o)

> 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.

Ok, I can somewhat agree, but history tells me that "debug" wasn't enough. A 
lot of people wants more 'steps'. So now, is the above a debug or trace? 
Isn't it dependent on its context?

> The programmer -will- know this when developing the code.

To a large degree, yes. But I think Greg is pointing towards scenarios where 
it is less obvious. What Jetty consider INFO or even WARNING could well be 
"yeah, so what, we know that. Don't bother me." when Jetty is embedded in 
larger applications.

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

Don't know.

> 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.

I.e. There is only N Axes and each Logger becomes the end-point for the API 
user into each of those axes. Meaning the "Category Tree" is one Axis, 
possibly some default to make life easier.

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

Not sure I understand what you mean?

> 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.).

I think the paranthesis + the stuff further up are basically saying; "Why not 
use Category as a name instead of Axis?".

I am basically saying that the "setup" of the logging system is a concern 
outside 'code development'. I view it that the establishment of an Axis 
happens in runtime(!), and is persisted by the logging implementation. 
Exactly what is the 'default' is up for discussion, and I have no opinion 
about that right now, probably I tend towards "ALL"... ;o)

> 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..

Interesting!! :o)  I have no answer to that right now, but if there is more 
interest in this than a casual chat and shooting ideas, then we can start 
look into it.

> 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.

As I said, Tool Support for the runtime environment is paramount to make this 
useful. Visualization of instantiated Loggers, drag-n-drop interface, network 
engine with axis visualization and stuff is definately required, as you 
correctly have identified.

> | 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?

If the client API for 'grabbing' a Logger is in such a way that the 
implementation have choice of whether give it a shared logger, a logger for 
this thread or for "this" instance of that object, then we can probably 
handle all kinds of advanced logging, which otherwise is difficult. Again, 
don't have all the answers.

> 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. 

Point was mainly that the developer does not need to get involved. If the 
production or QA crew find it useful, then it is their choice.
"Best Practices" and such would of course lessen the decision-anxiety of what 
should be done.
(Bottom line of the entire subject, as found in Log4J development as well; 
Everyone has their own set of preferences in this subject, and the only 
solutions seems to be when you closing in on "everything is possible" ).

> 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)

I think you somehow missed the point. The developer do Nothing! No axes, no 
colors, no levels, no nothing. The people (sometimes the developer) who 
consumes the logging output, sets up the N-dimensional system to their 
liking. No programming and no configuration, is what I had in mind.


But as I said, I wonder if we should continue this discussion at all, since I 
feel it far outside the scope of SLF4J. WDYT?


> 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?

I agree on that the standing proposal of debug(), info() and so on methods, 
should have very clear and precise documentation, especially to guide the 
developer, and stand as a 'reference' if there are internal arguments 
between, for instance, developers and QA folks of what is the proper level.


Cheers
Niclas