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