[slf4j-dev] Release of SLF4J version 1.6.0-RC0

[Ceki Gülcü]

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
>