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. _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
