From dtrebbien at gmail.com  Wed Aug  2 20:27:29 2017
From: dtrebbien at gmail.com (Daniel Trebbien)
Date: Wed, 2 Aug 2017 11:27:29 -0700
Subject: [slf4j-user] Inconsistent behavior introduced in SLF4J version
	1.7.15
Message-ID: <CABrgu5TBi1YAo4i9W=abrPYCXLn6Wg9FLzsSZHr7UWWg=9DH4g@mail.gmail.com>

Hello,

I have noticed an inconsistency in behavior of the following logging code:

    final Throwable t = new RuntimeException("some runtime exception");
    LOGGER.info("{} {} {}", new Object[] { "abc", "def", t });
    LOGGER.info("{} {}", "abc", t);
    LOGGER.info("{}", (Object) t);

In SLF4J versions 1.7.14 and earlier (tested 1.7.14, 1.7.13, 1.7.10, 1.7.7,
1.7.0, and 1.6.0), the result using the "simple" backend is:

[main] INFO test.Main - abc def java.lang.RuntimeException: some runtime
exception
[main] INFO test.Main - abc java.lang.RuntimeException: some runtime
exception
[main] INFO test.Main - java.lang.RuntimeException: some runtime exception

In SLF4J versions 1.7.15 and newer (tested 1.7.15 and 1.7.25), the result
is:

[main] INFO test.Main - abc def {}
java.lang.RuntimeException: some runtime exception
at test.Main.main(Main.java:10)
[main] INFO test.Main - abc {}
java.lang.RuntimeException: some runtime exception
at test.Main.main(Main.java:10)
[main] INFO test.Main - java.lang.RuntimeException: some runtime exception


To me, the new behavior is unexpected, and it is inconsistent with the
logging variant taking exactly one parameter because although the Throwable
instance is the last parameter, the one and only formatting anchor in the
format string is replaced by the toString() result and the stack trace is
not logged.

Is this a bug?

Daniel Trebbien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170802/81756fa8/attachment.html>

From dtrebbien at gmail.com  Wed Aug  2 20:37:24 2017
From: dtrebbien at gmail.com (Daniel Trebbien)
Date: Wed, 2 Aug 2017 11:37:24 -0700
Subject: [slf4j-user] Inconsistent behavior introduced in SLF4J version
	1.7.15
In-Reply-To: <CABrgu5TBi1YAo4i9W=abrPYCXLn6Wg9FLzsSZHr7UWWg=9DH4g@mail.gmail.com>
References: <CABrgu5TBi1YAo4i9W=abrPYCXLn6Wg9FLzsSZHr7UWWg=9DH4g@mail.gmail.com>
Message-ID: <CABrgu5QCUm_VYSci8XHvFpREx-b9YMRU3oxS-gXQMr72pr1G2g@mail.gmail.com>

It looks like this is a bug:  https://github.com/qos-ch/slf4j/pull/166

On Wed, Aug 2, 2017 at 11:27 AM, Daniel Trebbien <dtrebbien at gmail.com>
wrote:

> Hello,
>
> I have noticed an inconsistency in behavior of the following logging code:
>
>     final Throwable t = new RuntimeException("some runtime exception");
>     LOGGER.info("{} {} {}", new Object[] { "abc", "def", t });
>     LOGGER.info("{} {}", "abc", t);
>     LOGGER.info("{}", (Object) t);
>
> In SLF4J versions 1.7.14 and earlier (tested 1.7.14, 1.7.13, 1.7.10,
> 1.7.7, 1.7.0, and 1.6.0), the result using the "simple" backend is:
>
> [main] INFO test.Main - abc def java.lang.RuntimeException: some runtime
> exception
> [main] INFO test.Main - abc java.lang.RuntimeException: some runtime
> exception
> [main] INFO test.Main - java.lang.RuntimeException: some runtime exception
>
> In SLF4J versions 1.7.15 and newer (tested 1.7.15 and 1.7.25), the result
> is:
>
> [main] INFO test.Main - abc def {}
> java.lang.RuntimeException: some runtime exception
> at test.Main.main(Main.java:10)
> [main] INFO test.Main - abc {}
> java.lang.RuntimeException: some runtime exception
> at test.Main.main(Main.java:10)
> [main] INFO test.Main - java.lang.RuntimeException: some runtime exception
>
>
> To me, the new behavior is unexpected, and it is inconsistent with the
> logging variant taking exactly one parameter because although the Throwable
> instance is the last parameter, the one and only formatting anchor in the
> format string is replaced by the toString() result and the stack trace is
> not logged.
>
> Is this a bug?
>
> Daniel Trebbien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170802/f55bcd43/attachment.html>

From mike at themills.id.au  Thu Aug 24 01:49:36 2017
From: mike at themills.id.au (Mike Mills)
Date: Thu, 24 Aug 2017 09:49:36 +1000
Subject: [slf4j-user] Slf4j-test should be more convenient to use
Message-ID: <CAGKeJ3yP-SzY9GmFVAq3vtpGUGr41FoVNxFgzgtm+uzeeQUqSg@mail.gmail.com>

Hi,

I have been using the Log4j-test library but I have found that it just is
not flexible enough in most real world use cases.

When you include this library in your test scope, gradle and maven will by
default create a classpath with your normal runtime slf4j implementation
and the log4j-test implementation on the classpath during tests.


Would it be possible to modify the LoggerFactory.bind code to identify the
test variant and use it in preference to any other implementations on the
classpath?

Thanks

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170824/4322d11d/attachment.html>

From sschlansker at opentable.com  Thu Aug 24 01:52:31 2017
From: sschlansker at opentable.com (Steven Schlansker)
Date: Wed, 23 Aug 2017 23:52:31 +0000
Subject: [slf4j-user] Slf4j-test should be more convenient to use
In-Reply-To: <CAGKeJ3yP-SzY9GmFVAq3vtpGUGr41FoVNxFgzgtm+uzeeQUqSg@mail.gmail.com>
References: <CAGKeJ3yP-SzY9GmFVAq3vtpGUGr41FoVNxFgzgtm+uzeeQUqSg@mail.gmail.com>
Message-ID: <7ADFBE36-7E7D-43FD-9A99-995CCF740B96@opentable.com>


> On Aug 23, 2017, at 4:49 PM, Mike Mills <mike at themills.id.au> wrote:
> 
> Hi,
> 
> I have been using the Log4j-test library but I have found that it just is not flexible enough in most real world use cases.
> 
> When you include this library in your test scope, gradle and maven will by default create a classpath with your normal runtime slf4j implementation and the log4j-test implementation on the classpath during tests.
> 
> 
> Would it be possible to modify the LoggerFactory.bind code to identify the test variant and use it in preference to any other implementations on the classpath?

You'd probably be better off changing your normal runtime implementation to be <scope>runtime</scope> in your Maven POM
than expecting the binder to change.  We've had really good success including logback as runtime scope and slf4j-simple as test scope.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170823/331eb468/attachment.sig>

From boards at gmail.com  Thu Aug 24 03:47:01 2017
From: boards at gmail.com (Matt Sicker)
Date: Wed, 23 Aug 2017 20:47:01 -0500
Subject: [slf4j-user] Slf4j-test should be more convenient to use
In-Reply-To: <7ADFBE36-7E7D-43FD-9A99-995CCF740B96@opentable.com>
References: <CAGKeJ3yP-SzY9GmFVAq3vtpGUGr41FoVNxFgzgtm+uzeeQUqSg@mail.gmail.com>
 <7ADFBE36-7E7D-43FD-9A99-995CCF740B96@opentable.com>
Message-ID: <CACmp6kpyb5rQzi1-E1E2ppGRCfXYdpO9sdShk+Vk-275=sdLSg@mail.gmail.com>

Can't you make test config files? Like log4j-test.xml, logback-test.xml,
log4j2-test.xml, etc. Those take precedence over the normal file when
present, so including them in the test classpath works as expected.

On 23 August 2017 at 18:52, Steven Schlansker <sschlansker at opentable.com>
wrote:

>
> > On Aug 23, 2017, at 4:49 PM, Mike Mills <mike at themills.id.au> wrote:
> >
> > Hi,
> >
> > I have been using the Log4j-test library but I have found that it just
> is not flexible enough in most real world use cases.
> >
> > When you include this library in your test scope, gradle and maven will
> by default create a classpath with your normal runtime slf4j implementation
> and the log4j-test implementation on the classpath during tests.
> >
> >
> > Would it be possible to modify the LoggerFactory.bind code to identify
> the test variant and use it in preference to any other implementations on
> the classpath?
>
> You'd probably be better off changing your normal runtime implementation
> to be <scope>runtime</scope> in your Maven POM
> than expecting the binder to change.  We've had really good success
> including logback as runtime scope and slf4j-simple as test scope.
>
>
>
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>



-- 
Matt Sicker <boards at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170823/cacafa1e/attachment.html>