On 01/05/2010 2:16 AM, Ralph Goers wrote:
On Apr 30, 2010, at 7:04 AM, Ceki Gülcü wrote:
On 30/04/2010 3:24 PM, Ralph Goers wrote:
Generally when I don't reply it isn't because I love the idea.
I gathered as much.
I can't think of any use cases where I'd want to construct a logging
event that way. It also would seem that you would be taking what is
currently a structure private to Logback and making it public as it
would make no sense for SLF4J to have one LoggingEvent and Logback to
have another.
Building a LoggingEvent prior to calling org.slf4j.Logger avoids
adding new methods to the Logger interface in order to keep it sane.
In short, it doesn't really solve what Joern and I have been looking
for with support for the Message and doesn't provide much value that I
can see.
Given that it solves the method population explosion problem,
LoggingEvent can be considered as a prerequisite to to the addition of
the Message interface.
So instead of adding new methods to Logger you will add them to LoggingEvent.
That helps how?
With the Logger interface, we overload the printing methods (debug(),
info()...) so that they admit different types. This gets harder as the
number of types increases. On the other hand, LoggingEvent is built
piecemeal.
For example, while it is practically impossible to add support for
Marker arrays in Logger, in LoggingEvent this is trivial. The user
invokes LoggingEvent's add(Marker) method multiple times or
alternatively we can introduce a new method add(Marker[]) without any
trouble.
The approach is analogous to a constructor with 10 parameters versus
an ObjectBuilder.
Ralph
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
