From: | Jorge Solórzano <jorsol(at)gmail(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Daniel Migowski <dmigowski(at)ikoffice(dot)de>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: New driver logging proposal |
Date: | 2017-04-10 14:05:50 |
Message-ID: | CA+cVU8N35aS06T_A5HrQP+N8ddgv9p886fpRcQ-hSeYiYZ4LUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Sun, Apr 9, 2017 at 8:29 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
> So far I have seen more benefits of using JUL than claims of performance
>> degradation (and most of the claims are when using slf4j bridge). Of course
>> there is more to do, it might be not the best choice but was that or
>> introduce a optional dependency of SLF4J (wich is a bad idea based on the
>> SLF4J developers https://www.slf4j.org/faq.html#optional_dependency) or
>> simply introduce a direct dependency of SLF4J making a forced used of a
>> dependency that not many want. This is like the chicken-egg problem.
>>
>
> How would the bridge degrade performance if logging is off ?
>
>
The jul-to-slf4j module does not reimplement the java.util.logging because
packages under the java.* namespace cannot be replaced. Instead,
jul-to-slf4j translates LogRecord objects into their SLF4J equivalent.
Basically it means that when using log4j for example, the bridge can
replace org.log4j packages with an implementation of slf4j, so it uses the
slf4j bridge dependency instead of the log4j dependency, but with jul it
can not do that (it's part of the JDK) and it construct the LogRecord
object even when logging is off.
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Smith | 2017-04-12 18:53:19 | Re: Logical Replication: adjacent COMMIT messages with the wrong StartLSN |
Previous Message | Daniel Migowski | 2017-04-10 04:31:41 | Re: New driver logging proposal |