ache.org/repos/asf/logging-log4j2.git
>
>
> The following commit(s) were added to refs/heads/release-2.x by this push:
> new 487588b LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of
> formatted message data
> 487588b is described below
>
> commit 487588b7c34bc0b
It would be impossible to support Logback without pulling in slf4j-api, and
the extra jars is what causes the perception of a problem.
On 26 September 2017 at 03:20, Remko Popma wrote:
> Sounds to me that Ralph's analysis shows that doing the binding ourselves
> may not be worth doing since we c
Sounds to me that Ralph's analysis shows that doing the binding ourselves may
not be worth doing since we can't get an advantage by either improving people's
perception nor improve performance. Unless I'm missing something.
> On Sep 26, 2017, at 16:34, Mikael Ståldal wrote:
>
> I don't thin
I don't think we should support binding to Logback specifically. We
should support binding to any SLF4J implementation (including Logback).
We should probably test this with Logback though, since it's one of the
most popular SLF4J implementations.
On 2017-09-26 03:58, Matt Sicker wrote:
Woul
On Sep 25, 2017, at 6:58 PM, Matt Sicker wrote:
>
> Would it be possible to make a log4j-api provider that binds directly to
> logback instead?
>
> On 25 September 2017 at 18:54, Ralph Goers
> wrote:
>
>> I have been looking at the log4j-to-slf4j binding and am ret
Would it be possible to make a log4j-api provider that binds directly to
logback instead?
On 25 September 2017 at 18:54, Ralph Goers
wrote:
> I have been looking at the log4j-to-slf4j binding and am rethinking
> changing it. There really isn’t much to SLF4J to begin with. Unlike Log
I have been looking at the log4j-to-slf4j binding and am rethinking changing
it. There really isn’t much to SLF4J to begin with. Unlike Log4j 2, Logger is
an interface; the whole implementation is delegated. All SLF4J really does is
perform the binding between it and the implementation. So
Understood about the log4j-to-slf4j diagram.
About updating the performance page, I haven't been able to spend much time on
Log4j2 recently. When I did have time it has gone mostly into bug fixes.
If you have done this before you probably know this, but doing these
performance investiga
verflow.com/a/41500347/1446916> show some people perceive the
> log4j-to-slf4j module as a facade for a facade.
>
> If we bind directly, perhaps I should update this diagram to have a direct
> arrow from log4j-to-slf4j to SLF4J implementation?
>
>
> Remko
>
Ok I see now.
It would certainly be good to have more ammunition to argue for using the
Log4j2 API directly.
Comments on StackOverflow
https://stackoverflow.com/a/41500347/1446916 show some people perceive the
log4j-to-slf4j module as a facade for a facade.
If we bind directly, perhaps I
Well, SLF4J recently changed the binding mechanism with 1.8 in order to comply
with Java 9. It isn’t likely to do it again any time soon.
What we would “solve” is that now it is log4j-api -> log4j-to-slf4j ->
slf4j-api -> logging implementation. With this change it would be
; In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is
> strikes me that log4j-to-slf4j is binding to the SLF4J API while
> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using
> SLF4J’s binding mechanism. So it seems to me that instead of having
> lo
In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is
strikes me that log4j-to-slf4j is binding to the SLF4J API while
log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using
SLF4J’s binding mechanism. So it seems to me that instead of having
log4j-to
13 matches
Mail list logo
