[slf4j-dev] [Bug 70] " logging a stack trace along with a parameterized string" solution proposal

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=70


Joern Huxhorn <joern at huxhorn.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joern at huxhorn.de




--- Comment #13 from Joern Huxhorn <joern at huxhorn.de>  2008-09-28 21:22:50 ---
The code referenced in comment #11 does now reflect Cekis latest changes
concerning parameterized logging.
Thanks, Ceki, this approach is much cleaner and simpler than before. I could
throw away quite a bit of code and thats always Nice(tm).

My code does the following:
1.) Counting of placeholders in the message pattern (very cheap)
2.) Conversion of argument array into an ArgumentResult, containing the
arguments converted to String as well as an optional Throwable if available
(relatively cheap, but needs to be done)
3.) Replacement of placeholders in a message pattern with arguments given as
String[]. (most expensive)

Only step 1 and 2 are performed during construction of a LoggingEvent. The
actual formatting of the message is done lazily on demand.

The current implementation in Logback performs the formatting of the message in
the c'tor of LoggingEvent, i.e. every time even if it's not really necessary
(e.g. if just sent and not written to a logfile).
The formatted message also isn't transient so it will be serialized even though
it could be regenerated on demand after deserialization (both messagePattern
and arguments are still available).

The code above, if included that way or another in slf4j, would increase
logging performance significantly but it won't do so right now because Lilith
works on Logback events that already formatted the message in the c'tor
beforehand.

Concerning step 2, the rules are the following:
- If all arguments are used up, simply convert them to String[].
- Otherwise, if the *last* argument is a Throwable use that as a the Throwable
and convert *all* other arguments to String[], i.e. resulting args.length ==
originalArgs.length-1.

I have a rationale for that behavior:
Given that we still have the unformatted message pattern we could use it as a
translation id. The translated message could then contain a message like
"{1}{0}{2}" to be able to reorder the original arguments. Furthermore, it could
contain more arguments than the original message. I wouldn't consider this very
good style but I didn't want to prevent it explicitly.

@Thorbjørn: Sorry, I didn't mean to imply that you wanted to put the Throwable
before the arguments, although it reads like it.
I think I assumed something like that because you asked for compile time type
safety which, in combination with varargs, implies the Throwable before the
arguments.
My fault...

Real 1.5 varargs in slf4j are, btw, discussed in bug #31


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.