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