In the text below I freely use "category" as a synonym for "axis".
If you have multiple categorization methods (axis), there are two
possible ways of associating loggers and categories. You can attach
loggers to categories or you can attach categories to loggers.
The second approach (attaching multiple categories to loggers) is
similar (if not identical) to my earlier domain/subdomain
idea. Unfortunately, this approach could potentially necessitate as
many loggers as there are category combinations, leading to
combinatorial explosion and prohibitive memory usage.
The first your approach, i.e. your approach, (attaching loggers to
categories) would be much more memory efficient. However, I fear it
would suffer from a manageability problem. In other words, wouldn't it
be painfully difficult to configure such a system? Your message shows
that you are well aware of this issue as well.
More below.
At 08:55 AM 7/7/2005, Niclas Hedhman wrote:
On Thursday 07 July 2005 13:54, Christian Stein wrote:
> I'm totally with Niklas - especially in two issues. First the strong typing
> of the 'message' and 'format' argument as String. And second, his proposal
> of the generic 'log(LEVEL, message...)' methods.
Huh??
Have I proposed that?
If you are referring to;
<quote>
If
logger.debug( m )
is the equivalent of
logger.log( Level.DEBUG, m );
and you are now introducing
logger.log( Level.DEBUG, Marker.MINE, m );
</quote>
Christian is probably referring to [1] where you indeed made such a proposal.
[1] http://www.slf4j.org/pipermail/dev/2005-June/000119.html
then it was just a matter of visualizing that there is multi-dimensional axes
in Ceki's proposal, and as (I think) Endre pointed out the Logger instance
itself was yet another.
- o - o - o - o - o -
After reviewing the ideas and experiences of others, especially Endre and
Greg, I am starting to get convinced that the the whole issue is tackled the
wrong way. "Wrong" as in another evolutionary step down the dinosaur path,
and not an emergent mammal takeover lurking in the shadows ;o) (please take
the joke for what it is...)
Nice analogy. Allow me to run (fly?) with it.
Recent scientific evidence shows that birds descended from
dinosaurs. (In other words, dinosaurs evolved into birds.) Now, if
logging is like flying, then from an evolutionary stand point,
dinosaurs fly much better than mammals. Airplanes (the machine mammals
invented for flying) do not perform nearly as well as birds. Airplanes
are very expensive to build and to maintain, nor are they energy
efficient. In any case, dinosaurs have evolved into pretty nifty
flying machines.
Instead of exposing these multi-dimensional concerns, which may 'never
end', I
think that there is simply just a need for better management at the
implementation side of things.
I could classify two (dinosaur and mammal) trains of thoughts as;
1. The "business logic" programmer is fairly well aware of what is relevant
logging material, and that he/she makes the decisions "this is info and that
is debug". The deployment team should most of the time just enable "debug",
"info" and so forth for most of the application and get "reasonable" output.
This is "standard logging thinking", the norm of the day.
2. The "business logic" programmer is not capable of knowing how the
logging
data is going to be consumed, and a library having a "info" statement could
in some applications be considered "debug" and annoying. One could defer the
definition of the logging output until deploy-time (provided the tools
existed). The axes of concerns could be assigned totally outside the API
itself. Let me elaborate;
Hard coding some of the categorization into each log statement makes
it reasonably easy to filter them out at runtime. Deferring all the
classification to deploy-time, is possible. The rub lies with the
convenience/inconvenience involved in doing so.
public interface Logger
{
String getName();
boolean isEnabled();
void log( String message );
void log( Throwable throwable );
void log( String message, Throwable throwable );
void log( String format, Object arg );
void log( String format, Object arg1, Object arg2 );
Logger addChildLogger( String name );
}
If the "business logic code" seriously think the user needs more than one
aspect of the output, then create more Loggers, and good practices would
possibly go towards 'children according to function', instead of towards
'verbosity'. But that may not be feasible.
Much later (especially for libraries and other code that is heavily re-used)
one, two or more axes are created and each of the Loggers are assigned to
zero, one or more axes.
When does the logger assignment occur? I presume that loggers will be
still arranged by class name, at least roughly speaking?
public interface Axis // better name sure can found
{
String getName();
Object getCurrent(); // perhaps limit to Comparable
void setCurrent( Object current );
void assignLogger( Logger logger, Object argument );
void unassignLogger( Logger logger );
void addTarget( Target target ); // Appender in Log4J terminology
void removeTarget( Target target );
}
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.
The fact that the original developer would be oblivious to the
existence of the Color axis can be considered as an important
advantage. Having said that and assuming loggers are classified by
class name, then in a given class X with logger lX, you would need
child loggers, lX_1, lX_2, ..., lX_N, all children of lX, to
specialize certain log statements. Otherwise, how could you
distinguish log statements emanating from class X? If you need
specialized loggers, then the developer *still* has to provide some
input to the logging system at compile time.
In which case, I think the Marking model offers exactly the same
flexibility, at a slightly lower cost at compile time, and
significantly lower cost at configuration time. Slightly lower cost at
compile time, because with Markers there is no need to create child
loggers. However, one still needs to assign markers to log
statements. Significantly lower cost at config time because with
markers there is no need to attach loggers to categories.
Anyway, my argumentation is entirely based on the assumption that
Niclas' proposal requires child loggers. Does it?
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.
NOW, there are two important parts of the above;
1. The Logger instance handed to the using code, has no encoding of how the
output will be used (as now is the case). The API is dirt simple, everything
else are "behind the scene implementation details" and "tools integration"
problems/challenges.
Do you have an idea of how one could accomplish such "tools integration"?
2. To make something like this work, tool support is extremely important.
Otherwise setting it up becomes a nightmare.
3. This can be done in other variations and the whole things is possibly
not
in the scope of SLF4J.
In the sense that it constitutes a revolution instead of evolution, as
your dinosaur/mammal analogy intimates.
I just felt I wanted to throw something wild on the table, perhaps trigger
some thought and revive last century thinking, which I consider current
logging approaches to be ;o)
Personally I get somewhat excited with the above. Time to go for a cold
shower, and return to reality. ;o)
Have fun looking at this.
:-)
Cheers
Niclas
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
