[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=31

--- Comment #92 from John Vasileff <git at netcc.us> 2011-09-07 16:13:42 CEST ---
(In reply to comment #90)
> (In reply to comment #89)

Joern, thanks for reviewing this.

> All maybeLog(...)-methods in NamedLoggerBase are calling the same
> private void log(Marker marker, Level level, String msg, Throwable t)
> method, already formatting the message and dropping any info about the argument
> array and message pattern that was used to call it.

I pushed an update for NamedLoggerBase to improve compatibiltiy.  It now
delegates to the existing Object[] logging methods and no longer performs
formatting.

> I can't help but feel dirty defining an interface like this...

Well.. I agree, this adds a lot of methods to the API.  It is relatively easy
to code if the burden is removed from _each_ logger implementation, but it is
still end user facing.  It really comes down to whether or not we care about
the current 1ns or so penalty and subsequent gc.  Future VMs (and processors)
may optimize this, but my hunch is that an implicit array will always be
created.  I'm somewhat neutral on this.  Maybe looking at the resultant
javadocs would change my mind.

> The fact that (optional) formatting is happening in the adapters is not an
> issue but a feature.
> Message formatting is an implementation detail and different frameworks can
> handle it in different ways (e.g. postpone it as in my Logback example).

Got it.  It does however seem valuable to simplify requirements for logger
implementors.  Everyone implemntation requires solving the same problems of 1)
maintaining compatibility, and 2) implementing numerous similar methods.
Enhancements like "Bug 70" should be possible without updating implementations
everywhere.  The same for possible future formatting or other features as you
mentioned.

An adjustment to #4's AbstractLogger:

protected abstract void log(
    Marker marker, Level level, String msg, Throwable t,
    String rawMsg, Object[] argsWithoutTrailingThrowable);

And an alternate AbstractRawLogger (implementor's decision which to use):

protected abstract void log(
    Marker marker, Level level, String rawMsg, Object[] rawArgs);
protected final Message format(String rawMsg, Object[] rawArgs);
public interface Message {
    // similar to comment #61 but also include the "processed" args that
    // exclude the optional last arg throwable.  Initially this would be
    // an instance of "FormattingTuple implements Message"
    String getFormattedMessage();
    Throwable getThrowable();
    Object[] args;
}

> Agreed, but it must be possible to use 1.6.x and 2.0 side-by-side.

Original items #1 - #3 allow full 1.6 <-> 2.0 mix and match, and may even
provide "perpetual support" of 1.6 loggers.  Probably pointless, but support
could even be re-added for even older loggers (pre-TRACE?).

Original item #4 would require 2.0+ for any loggers implementing AbstractLogger
or AbstractRawLogger.  But it seems like the best time for something like this
would be when JDK 5 is introduced.  And if Abstract[Raw]Logger is well thought
out, it will provide very long term compatibility while not restricting
future enhancements.

-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.