Re: New driver logging proposal

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.

In response to

Browse pgsql-jdbc by date

  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