Thread: 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-----
On Wed, 31 Oct 2001 14:46:29 -0700 (MST), you wrote: >I'm planing to create implmentations of ConnecitonPoolDataSource and >PooledConnection in the jdbc2 package, Jo! :-) >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? What sort of configuration file are you talking about exactly? Regards, René Pijlman <rene@lab.applinet.nl>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just replied, but I want to be abit more specific. PostgresqlDataSource provides methods to set database servername, etc. I want my pooled datasource to have those as well. But having a configuration file that can read default connections is useful in certain cases. I want to be able to retrieve the info from JNDI namespace eventually, but a properties file that contains the info is useful outside of JNDI environments. On 31-Oct-2001 Rene Pijlman wrote: > What sort of configuration file are you talking about exactly? 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 iD8DBQE74H28iysnOdCML0URAo/3AJ9rCySR0gx7Y9EhRPBqvnJC8aXY/wCfbzX1 5UZRCkaIqCQmG4sQUtuCo0Y= =u0Wb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31-Oct-2001 Rene Pijlman wrote: > What sort of configuration file are you talking about exactly? Basically, defaults for pool min size, max size, things like that. Also, since the ConnectionPoolDataSource interface only has two methods to get the connection (one with no arguments, one with username/password) there needs to be a default connection info, like host, database name, port, etc. 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 iD8DBQE74HwwiysnOdCML0URAqshAJoC9zUJ2oIYAAzs0rvCsJZyg2t9OACcC2+s SGCmfCMNVcaFud0Jn2j4N/w= =cw9K -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31-Oct-2001 Shevland, Joseph (AU - Hobart) wrote: > For the properties file, I'd suggest just a standard properties file, no Yeah, that's my plan... I'll get the default properties file org/postgresql/psql.properties as a resource from the class loader, then get a top-level one that the user would have configured to override its defaults. Using getClass().getResourceAsStream() method you mentioned. > Sounds good on the JDBC 2.0 front, if you need a hand doing anything or can > palm off discrete bits of work let me know, I've done a fair bit of work in > these areas including writing the first cut of the persistence stuff for > JBoss. Sure. I'm going to submit my pool by monday hopefully. After that's working, I want to see if I can add to the JNDI front and work on RowSets. 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 iD8DBQE74IfGiysnOdCML0URAqP2AJwP7sADUr5SnRClpRCuJGMTzyp51wCfXvdl DH/bYXnfG+8w77Lq8B65ZZI= =reth -----END PGP SIGNATURE-----
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)
* "Dave Cramer" <Dave@micro-automation.net> wrote: | | I have been wondering about the licensing issues of just including | log4jme source into ours with the proper recognition of course. I buy your reasoning about log4j. I think the licensing issues should be OK, since the Apache license is pretty similar to the pgsql license but you might want to check with the core team. There is no reason to reinvent logging, so if we could include and adapt source code from the microedition of log4j that would be great. If it is done right we might also be able to plug in the full log4j as a replacement when deploying the driver. OTOH, there could be some serious pitfalls here as well so we should probably keep everything out of the org.apache.* namespace to avoid potential version conflicts. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks- Last night I threw together a quick example of some ideas I have in the pooling mgmt for PostgreSQL's JDBC driver. The code can also found at: http://members.home.net/wolpert5/code/ First, I have some comments on the code I included, then I have questions for people. Comments: 1) Code shown here is not done. I've based it off of the PostgresqlDataSource code base. 2) Things not done include finishing JNDI naming stuff, thread for connection cleanup, using PSQLException, code cleanup, testing. (:-) In fact, don't run this example, just examine the way it works 3) I'm using logWriter for log writing. 4) Pooling technique include a) min number of connections b) max number of connections, c) Min number of 'available' connections, d) removing connections after SQLExceptions occured, e) cleanup 'unclosed' connections 5) The PostgresqlConnetionPoolDataSource is not serializable in my code. Should it be? (I figure not, since the pool is lost during serialization) 6) The technique for property-file usage is that it reads the default list first, which in the final jar, is org/postgresql/psqlProps.properties Then, it checks (in the classpath) for user properties at /psqlProps.properties, which overrides the default properties. Finally, the user of this class can set individual properties programmatically as well. Questions: 1) Is the log4j integration going to make use of the logWriter? Should we use both? 2) The PostgresqlConnetionPoolDataSource is not serializable in my code. Should it be? (I figure not, since the pool is lost during serialization) 3) In a JNDI layer, it 'almost' makes sense for a the connection pool to ma 4) The property technique, where defaults are read that exist in the jar file, user can have their own property file, and users can set properties programmatically seems good to me. What objections do people have? 5) Currently, if the username and/or password changes, I reset the entire pool. Is this bad? Should the ConnectionPoolDataSource contain multiple pools, each pool for each user/password combo? (With the ability flush a pool that is unused.) I figure I like my current implmentation, but I'm open to discussion 6) What package should the PostgresqlConnectionPoolDataSource be in? I figure the other items are definatly in the jdbc2 grouping. 7) Assuming this properties technique I have makes sense, should I move property retrieval into a more universally usable class in the utils directory? Or will no one else use it? 8) Any other comments other than code style. :-) (And yes, it does need some refactoring too.) Code included at these following links: http://members.home.net/wolpert5/code/PostgresqlConnectionPoolDataSource.java http://members.home.net/wolpert5/code/PostgresqlPooledConnection.java (I decided not to include them in this message. If people want me to send them to the list, I will) Remeber that the code is not completed, or in a usable state. Really, this is an example of my direction I'm working on, sorta an RFC, really. Thanks! 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 iD8DBQE74XMMiysnOdCML0URAi9AAJ0UeXxmFX7EWhOJ4pS4obbyTXw4LACffyZ/ SXt1qHAliIll10rZC715Us8= =Ww+e -----END PGP SIGNATURE-----
Folks- I'm not sure that the mailing list is working, but I wanted to send this to the group. I've got two files that help with default configuration. The first is the DefaultProperties.java file, which belongs in the org/postgresql/util directory. This file contains methods to get, well, default properties. The default properties can either the system defaults in the org/postgresl/psqlProps.properties file (which I included as well) or the user defined psqlProps.properties. Both files should be included in the jars that are built, and are not java version specific. They use standard property classes, and are minimal in size. A singleton reference to the class is there as well, so different components can share it. Properties can be reloaded. Finally, note that the user defaults override the system defaults, but the user psqlProps.properties doesn't need to contain all the system ones. Just the ones they want changed. I've included the two files here, and copies are at my website (http://members.home.net/wolpert5/code/) Let me know of any problems or suggestions. I'm going to use this for the pooling code I'm going to contribute. Thanks ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante wolpert@yahoo.com | _________________/ "Who watches the watchmen?" 4e75 -Juvenal, 120 AD -- Place your commercial here -- fnord __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com
Attachment
Ned, Looks good so far... I haven't had a chance to really read it, but I am wondering about a synchronized method that can block? Specifically getPooledConnection. Dave -----Original Message----- From: Ned Wolpert [mailto:wolpert@yahoo.com] Sent: November 2, 2001 12:22 PM To: pgsql-jdbc@postgresql.org; Bruce Momjian Cc: Dave Cramer; Barry Lind Subject: Default configuration file Folks- I'm not sure that the mailing list is working, but I wanted to send this to the group. I've got two files that help with default configuration. The first is the DefaultProperties.java file, which belongs in the org/postgresql/util directory. This file contains methods to get, well, default properties. The default properties can either the system defaults in the org/postgresl/psqlProps.properties file (which I included as well) or the user defined psqlProps.properties. Both files should be included in the jars that are built, and are not java version specific. They use standard property classes, and are minimal in size. A singleton reference to the class is there as well, so different components can share it. Properties can be reloaded. Finally, note that the user defaults override the system defaults, but the user psqlProps.properties doesn't need to contain all the system ones. Just the ones they want changed. I've included the two files here, and copies are at my website (http://members.home.net/wolpert5/code/) Let me know of any problems or suggestions. I'm going to use this for the pooling code I'm going to contribute. Thanks ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante wolpert@yahoo.com | _________________/ "Who watches the watchmen?" 4e75 -Juvenal, 120 AD -- Place your commercial here -- fnord __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com
--- Dave Cramer <Dave@micro-automation.net> wrote:
> Looks good so far... I haven't had a chance to really read it, but I am
> wondering about a synchronized method that can block? Specifically
> getPooledConnection.
Actually, I punted on that one. Reason I did it was that creating a
new Properties could fail due to an IOException. However, if I make
the 'reload()' method catch the exception, then I can have the static
var be created at construction time. (Like this)
private static DefaultProperties self = new DefaultProperties();
public static DefaultProperties getDefaultProperties() {
return self;
}
I use the term 'punted' since I didn't know if developers would rather
a) check that the singleton is null, b) get an empty DefaultProperties
object or c) handle the exception of an IOException. For this case, I
allowed the singleton to be null, and made it not a true singleton by
giving people the option to create their own instance.
Votes on proper behavior? I guess it makes sense to catch the exception
internally, and behave as if the DefaultProperties is empty should an
IOException occur.
=====
Virtually, | "Must you shout too?"
Ned Wolpert | -Dante
wolpert@yahoo.com |
_________________/ "Who watches the watchmen?"
4e75 -Juvenal, 120 AD
-- Place your commercial here -- fnord
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com