Обсуждение: Re: JDBC Logging & log4j

I don't have time to go into details now, but Jakarta's Commons logging project allows one to use different logging components, which may allow PgSQL JDBC developers to write an abstraction that would allow for easy switching between logging components (you can sue Log4J or this or that or nothing, you can get the jar or not, etc.). Sorry, I'm in a rush, but if you look at Jakarta's Commons logging you can see for yourself.

Otis
_______________________________________________________________
Get your own FREE email account at iVillage.com!
http://webmail.ivillage.com/

<-----Original Message----->
>
> From: Dave Cramer
> Sent: 3/16/2002 7:16:40 PM
> To: pgsql-jdbc@postgresql.org
> Cc: pgman@candle.pha.pa.us
> Subject: [JDBC] JDBC Logging & log4j
>
> A number of people have asked about logging in the driver, and
> specifically about the use of log4j.
>
> There are a number of issues with this.
>
> 1) It means that we have to have another jar, and likely include in the
> distribution. For folks that don't use java this is a burden. Think of
> it this way, do you want to download a bunch of perl modules with the
> driver so you can use jdbc?
>
> 2) log4j uses a propery file to load it's configuration and it seems
> there are some *very* creative ways to load database drivers out there
> which do not load the log4j properties correctly.
>
> 3) Regardless of how fast log4j is or isn't it is still will slow the
> driver down. And as Hans pointed out java has no preprocessing so we
> either get logging in there or not.
>
> 4) log4j does facilitate changing the loglevel at runtime instead of
> compile time, but we still run into issues where we have to create a
> string object to log whereas now we don't so code like:
>
> foo(getInfofrombackend())
>
> Becomes
>
> String msg = getInfofrombackend();
> logger.debug(msg);
> foo(msg);
>
> So the question is:
>
> Do we want to put logging in the driver?
> Why?
> How much?
> At what cost?
>
> I have given some thought to question 1) above and we could use a
> pluggable logger so that log4j could be used if configured or, there
> would be a default logger. However this would only slow things down even
> more.
>
> Dave
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

* "otisg" <otisg@iVillage.com> wrote:
|
| I don't have time to go into details now, but Jakarta's Commons logging
| project allows one to use different logging components, which may allow
| PgSQL JDBC developers to write an abstraction that would allow for easy
| switching between logging components (you can sue Log4J or this or that
| or nothing, you can get the jar or not, etc.). Sorry, I'm in a rush, but
| if you look at Jakarta's Commons logging you can see for yourself.


You can also do that with the log4j package which in fact is the main
logging package at Jakarta. But that is not the point at hand here. Do
we actually want the inevitable performance hit we will get from putting
more logging in there ? If we cannot use a preprosessor to turn logging
of at compile time, then the answer is no. Else yes.

--
Gunnar Rønning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/