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

[bugzilla-daemon at pixie.qos.ch]

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





--- Comment #61 from Joern Huxhorn <joern at huxhorn.de>  2009-11-15 19:16:48 ---
Concerning comment #56 and comment #31:

The only downside is the possibility of separate maintenance in case of bug
fixes, if necessary and critical enough.
We are all in agreement that comment #31 is a good solution of this problem.

Concerning comment #59:
The only problem I have with XLogger is due to the fact that it *is* a wrapper.
Avoiding such an additional wrapper is one of the great features of Logback.
I like XLogger but I'd only use it if I required the entry etc. functionality,
not always.

Concerning my comment #45 and comment #53:
My suggestion of defining/discussing a new Logger interface is only partially
related to this bug. It was probably a mistake on my side to attach it here and
was not meant to be in disagreement with any other suggestion, like XLogger or
comment #31.

What I tried to accomplish is redesigning SLF4J to support stuff that we can't
support right now, due to the fact that we must neither reduce nor extend the
original SLF4J logger.

Bug #133 is one such issue, something that I would have needed on several
occasions, one of which was the bridging of XSLT messages to SLF4J. Being able
to retrieve the Threshold of a logger would be nice, too, although I didn't
have a situation where I'd needed it. And bug #125, removal of unnecessary
methods, is another one of that kind.
Last but not least, bug #70, my personal favorite.

We could even aim to support all the different kinds of message formattings
that were previously requested by various users, e.g. Java-Formatting,
StructuredData like Ralph suggested (supporting named placeholders),
MDC-related formatting (again, named placeholders that are replaced with MDC
values) and so on.

This would be possible if we devised something as general as

logger.debug(Message message)

where Message would be an interface like this:

public interface Message
{
    String getFormattedMessage();
    Throwable getThrowable();
}

where the current implementation would look something like this:

public class ParameterizedMessage
    implements Message
{
    Object[] getParameters() {..}
    String getMessagePattern() {..}
}

but with the ability to add new Message types as needed.

I'd be highly interested in a discussion about this topic but - as I said -
this bug is likely the wrong place for such a discussion...
A place to brainstorm about what SLF4J 2.0 could look like would be nice.

Cheers,
Joern.


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