Re: Updates to the driver - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: Updates to the driver |
Date | |
Msg-id | 015101c1626e$dfe55d80$c201a8c0@inspiron Whole thread Raw |
In response to | Updates to the driver (Ned Wolpert <ned.wolpert@knowledgenet.com>) |
Responses |
Re: Updates to the driver
New pooling (Long) [Was RE: Updates to the driver] |
List | pgsql-jdbc |
At the moment log4j seems to be problematic, as well as loading property files. There are a couple of reasons I am leaning away from log4j: 1) the aforementioned property file problem (I will explain below) 2) it will require that the user add another file to their classpath, and we have enough problems with ppl getting the driver on the classpath. Issues with log4j property files. The biggest issue is that we have no control how we are being loaded. In the case of a normal load where the driver is on the classpath I couldn't get log4j to load it's default "log4j.properties" file even though I put it everywhere I could think of. It is possible to load it using org.postgresql.Driver.ClassLoader.getResource("org/postgresql/log4j.prop erties") It's also possible to load it using getResourceBundle("org.postgresql.log4j.properties") There are a number of other unique cases 1) StarOffice needs the driver place in it's lib directory and I haven't a clue how to control the logging under this scenario. 2) druid loads the driver using the JarClassLoader and instantiates it from that. In this case the getResourceBundle fails as well The upshot of this is that with enough work and by placing things in the correct places I am sure we could get it to work, however the driver should be "simple" to use and our logging requirements aren't that demanding so I am thinking that we should roll our own. I have been wondering about the licensing issues of just including log4jme source into ours with the proper recognition of course. At any rate before you go down the ".properties" path with configuration files you may want to give some thought to the above. Also keep in mind servlet engines and their weird class loading issues. My current bias is to make sure we can load everything out of our own jar since we have no control of how we are loaded. Cheers, Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Ned Wolpert Sent: October 31, 2001 4:46 PM To: pgsql-jdbc@postgresql.org Subject: [JDBC] Updates to the driver -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks- I'm starting work trying to get the driver compliant to JDBC2.0. Of course, I'm starting with the easy stuff first. Things I'm working on first are pooling and rowsets. I'm planing to create implmentations of ConnecitonPoolDataSource and PooledConnection in the jdbc2 package, and planed to have a configuration files in the org/postgresql directory that could be overrideable. I figure that we'd have the default one in the classpath, under the org/postgresql directory, and the user overriding one in the top part of the classpath. What are people's thoughts on this? Also, to avoid needing an XML parser, I was planing on just using a standard properties file for them. Also, is Log4j going to be a standard? I heard this mentioned on the list before. Since exceptions we throw are PSQLExceptions (rather than SQLExceptions) will creating an exception of that type autolog the exception? Does anyone object to log4j? (I like it, but I just want to know what our standard is going to be.) Its about 130k, and unlike Ant, it will have to be distributed to end-users rather than just the build part of postgres. Thanks for you comments. Virtually, Ned Wolpert <ned.wolpert@knowledgenet.com> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74HE1iysnOdCML0URAv80AJ9xhMtG1y6HnT/RVPLtAfYYzVjBkQCfaL1N 9DVhMrt0bmKfjJHxR91rZkk= =P8N3 -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
pgsql-jdbc by date: