OK. Instead of passing a Message, one would pass an Event which would
contain a Message as well as optionally other data.
Example 1)
Event event = new Event("hello {}").addParam("world").add(marker);
logger.error(event);
Example 2)
Event event = new Event(structredData).add(throwable);
logger.error(event);
On 26/04/2010 3:38 PM, Ralph Goers wrote:
In general, I agree with Joern. The point of the Message interface is to make
it easy to create all different kinds of Messages. A StructuredData message
really has no good way to implement addParam() or event addThrowable.
Ralph
On Apr 26, 2010, at 5:09 AM, Joern Huxhorn wrote:
On 26.04.2010, at 10:58, Ceki Gülcü wrote:
On 24/04/2010 3:55 PM, Joern Huxhorn wrote:
One of my goals in slf4j-n was to reduce the number of methods in the
Logger interface.
This was seemingly a bad idea since it would have a performance impact,
in the case where a message isn't actually logged, as Ralph reported.
Because of this, it would be very wise to keep all the methods that are
already present in the Logger interface and simply add
debug(Message)
debug(Message, Throwable)
debug(Marker, Message)
debug(Marker, Message, Throwable)
[same for other levels plus generic log(Level, ...)-methods]
The designer in me doesn't like the "bloated" (in the sense that some
methods could be dropped without losing functionality) interface, but
the realist in me accepts that performance is more important than
aesthetics ;)
Can't we coalesce debug(Message), debug(Message, Throwable), debug(Marker,
Message) and debug(Marker, Message, Throwable) into a single variant?
Here is an idea:
try {
...
} catch(Throwable t) {
Message m = new Message("hello{}").addParam("word").add(marker).add(t);
logger.error(m);
}
This approach incurs the cost of creating and building the Message object
regardless of whether the request will be logged or not. I suspect that the
bulk of the cost is due to the object creation incurred by new Message(...) and
not due to the addition of extra data incurred in calling addParam() and the
other add() methods. Thus, performance-wise we are in the same position as the
original Message proposal but now we can get rid of all the overloaded variants
dealing with Marker and throwable.
Well, the idea of the Message interface (!) was to enable lazy initialization
(in contrast to a simply toString) without adding too many additional
requirements to it.
http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/core/Message.java
It would be much more work to implement a custom Message with the suggestion
above. More work implies more chances of faulty implementation, for example in
case of Marker support. The addParam() method would be quite a mistake, too,
since a different implementation of Message might use key/value-pairs as
parameters. (This is something that I'd really like to do since it would also
enable easier translations)
I see that interface as the main extension point of SLF4J& Logback. The
Message instance is supposed to end up in the appenders in case of Logback, so
custom appenders could handle custom Message implementations in arbitrary ways
without having to parse anything.
We could, however, add the Throwable to the Message interface. I left it out of
the interface and added it only to the ParameterizedMessage implementation to
keep the interface as clean as possible.
This would reduce the interface to debug(Message) and debug(Marker, Message),
at least.
How about
interface Message
{
Message set(Throwable); // instead of setThrowable to be more concise?
Throwable getThrowable();
}
in addition?
My problem is: I'm not really sure if I'll like this while using it ;)
Regardless of the way we'll implement it in the Message, it will always be less
concise (concerning both brevity and readability) than code using the four
methods...
Joern.
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
