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

[Joern Huxhorn]

On 30.04.2010, at 16:04, 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.
> 

In my case, it was a mixture of not enough spare-time and not really knowing what I should reply.

I was also a bit confused by your examples:
LoggingEvent event =
  new LoggingEvent(Level.ERROR,
             new AuditMessage("msg0", "type0"))).add(t);
logger.error(event);

I guess you mean logger.log instead of logger.error. Otherwise I'd be quite interested what the framework should do if the given event wasn't of Level.ERROR.

Beside that, I'm very hesitant about adding Level at this point (read: I think it's a very bad idea), anyway, since the proper way of implementing it would be an enum but we need to stay 1.4-compatible for now, right?
If we introduce it now then we won't be able to change it into an enum later on. That's why I would NOT add Level to SLF4J right now. I'd do this during the big 1.5 update sometime in the future.

> > 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.

First of all, I agree with everything Ralph said above.

Using the suggested methods would create illegible logging calls, at least in my opinion, since they differ quite much from the current signature.
The current methods enforce a certain order which won't be the case anymore in case of LoggingEvent.

Concerning the insanity, I'd rather be lazy while using the Logger than while implementing it.
(Concerning the performance info at http://bugzilla.slf4j.org/show_bug.cgi?id=31#c82 I'd even consider adding methods with 4 and 5 arguments :p)

This means I'd happily perform the monkey-work of implementing 4*5(LogLevels)*6(SLF4J-implementations) methods but I'm not really interested very much in

Logger.log(LoggerEvent)

> 
> > 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.

I don't agree that this problem is a problem at all.

If it's simply a matter of the amount of work that'll be required then I'd be happy to help out.
If that's not the issue then please explain it to me.

Joern.