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

[Ceki Gülcü]

On 30/04/2010 5:28 PM, Joern Huxhorn wrote:
> In my case, it was a mixture of not enough spare-time and not really knowing what I should reply.

No worries.

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

Yes, I had meant to write logger.log instead of logger.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.

Indeed.

Using enums for levels will require JDK 1.5 so we won't be able to use
enums in SLF4J 1.6 which still targets JDK 1.4. Compared to typed
level classes, e.g. java.util.logging.Level,
ch.qos.logack.classic.Level and org.apache.log4j.Level, levels based on
Java 5 enums offer little benefit. Yes, enums can be used as case
labels, but how difficult is to write the following?

  int levelInt = level.toInt();
  switch(levelInt) {
    case Level.TRACE_INT: ...;
    case Level.DEBUG_INT: ...;
    case Level.INFO_INT: ...;
    etc.
  }

Do you see other benefits of a level based on enums over a typed
level?  If not, I think we can stick with typed levels even after
SLF4J 1.6. If you wish to pursue this subtopic, I suggest creating a
new thread named "level based on enums" or similar.

> [cut]

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

I agree that building the LoggingEvent prior to calling logger.log
implies a paradigm change. However, I fail to understand your point
about "current methods enforce a certain order...". Could you explain?

More below.


 > Concerning the insanity, I'd rather be lazy while using the Logger
 > than while implementing it.

Of course! I agree with that sentiment but it's also about striking a
balance. Assuming that the vast majority of logger invocations are
akin to logger.level(message), only in a small number of cases will
the user write:

LoggingEvent event =
    new LoggingEvent(Level.ERROR, new Message("msg0", "type0"))).add(t);
logger.log(event);

With this API change, simple things remain simple and more complex
thing are made possible.

 > (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)

Considering that only a very small proportion of logger calls have 4
or 5 arguments, the expected performance gain obtained by the addition
of these methods should be negligible, especially considering that
although calling new Object[] is noticeably slower but not in way which
offsets the diminishing probability of having 4 or 5 params.

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

I actually agree with the way you brake down the problem. It's really a
trade between monkey-work on side of SLF4J developers versus
inconvenience to the users. The LoggingEvent paradigm is not that
awful and much more extensible. (Add a new method to LoggingEvent
instead of adding Nx5 new methods to logger, times its various
implementations.)

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

Given that the logger interface has to deal with 6 different types,
namely Level, Marker, String (the message), Message (typed message),
Throwable, Object[] (the arguments), combinatorial explosion in method
signatures cannot be avoided. Bug 70, which you know well, is an
example of possible interferences caused by just two different types
(Object[] and Throwable).


Around March of this year, Gunnar Wagenknecht observed that markers
should viewed as tags and the current marker mechanism is over
engineered. Unfortunately, I think he is right **. At this stage, it
would be very inelegant to add Marker[] as a new parameter type to the
logger interface. With the LoggerEvent paradigm, it the user wishes to
add several markers to the event, she repeatedly calls
event.add(marker). For example,

   new LoggingEvent("hello world").add(marker1).add(marker2);

That's it.

** http://www.qos.ch/pipermail/slf4j-dev/2010-March/002875.html

 > If it's simply a matter of the amount of work that'll be required
 > then I'd be happy to help out.

Thank you. I appreciate the offer.

 > If that's not the issue then please explain it to me.

I tried. See above. In a nutshell, I'd like to avoid painting
ourselves to a corner. :-)

> Joern.

--
Ceki