Thread: DatabaseMetaData.getTables()
Hi,
There seems to be a problem with DatabaseMetaData.getTables() when I do the following:
ResultSet R=conn.getMetaData().getTables(null, null, "%", null);
It throws a NullPointerException:
java.lang.NullPointerException
at org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java:1732)
at Test.main(Test.java:66)
Looking at the source, ResultSet.getBytes() is called and it returns null, causing this exception to be thrown. However
Ican use ResultSet.getString() without a problem. I'm using 7.1.3 at the moment. Does ResultSet.getBytes() need to be
fixedor should getTables() be modified?
I'd be grateful for any insights. Or you can just tell me to use the latest cvs version of PostgreSQL :) What is the
consensuson supporting older versions, will you phase out old code when 7.2 comes out?
--
Jason Davies
jason@netspade.com
Attachment
On Sat, 27 Oct 2001 19:25:49 -0500, you wrote: >There seems to be a problem with DatabaseMetaData.getTables() [...] >It throws a NullPointerException: This may have been fixed by now: http://fts.postgresql.org/db/mw/msg.html?mid=1021572 Regards, René Pijlman <rene@lab.applinet.nl>
It appears the getBytes was previously being used to return a byte array
of any arbitrary column.
Fixes for blobs seem to have broken this. The question is as Jason
pointed out which do we fix.
It doesn't seem unreasonable to be able to return a byte array for any
arbitray column. On the other hand is this the intended use?
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Jason Davies
Sent: October 27, 2001 8:26 PM
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] DatabaseMetaData.getTables()
Hi,
There seems to be a problem with DatabaseMetaData.getTables() when I do
the following:
ResultSet R=conn.getMetaData().getTables(null, null, "%", null);
It throws a NullPointerException:
java.lang.NullPointerException
at
org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java:17
32)
at Test.main(Test.java:66)
Looking at the source, ResultSet.getBytes() is called and it returns
null, causing this exception to be thrown. However I can use
ResultSet.getString() without a problem. I'm using 7.1.3 at the moment.
Does ResultSet.getBytes() need to be fixed or should getTables() be
modified?
I'd be grateful for any insights. Or you can just tell me to use the
latest cvs version of PostgreSQL :) What is the consensus on supporting
older versions, will you phase out old code when 7.2 comes out?
--
Jason Davies
jason@netspade.com
Yes, I had a look at this, and it is confirmed to be broken in the CVS
tip. You can try the driver from jdbc.postgresql.org. It may be more
stable. This did work recently ;(
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Jason Davies
Sent: October 27, 2001 8:26 PM
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] DatabaseMetaData.getTables()
Hi,
There seems to be a problem with DatabaseMetaData.getTables() when I do
the following:
ResultSet R=conn.getMetaData().getTables(null, null, "%", null);
It throws a NullPointerException:
java.lang.NullPointerException
at
org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java:17
32)
at Test.main(Test.java:66)
Looking at the source, ResultSet.getBytes() is called and it returns
null, causing this exception to be thrown. However I can use
ResultSet.getString() without a problem. I'm using 7.1.3 at the moment.
Does ResultSet.getBytes() need to be fixed or should getTables() be
modified?
I'd be grateful for any insights. Or you can just tell me to use the
latest cvs version of PostgreSQL :) What is the consensus on supporting
older versions, will you phase out old code when 7.2 comes out?
--
Jason Davies
jason@netspade.com
I forgot to mention I'm using the current CVS. On Sun, Oct 28, 2001 at 10:07:06AM +0100, Rene Pijlman wrote: > On Sat, 27 Oct 2001 19:25:49 -0500, you wrote: > >There seems to be a problem with DatabaseMetaData.getTables() > [...] > >It throws a NullPointerException: > > This may have been fixed by now: > http://fts.postgresql.org/db/mw/msg.html?mid=1021572 > > Regards, > René Pijlman <rene@lab.applinet.nl> -- Jason Davies jason@netspade.com
Attachment
On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote:
> It appears the getBytes was previously being used to return a byte array
> of any arbitrary column.
>
> Fixes for blobs seem to have broken this. The question is as Jason
> pointed out which do we fix.
>
> It doesn't seem unreasonable to be able to return a byte array for any
> arbitray column. On the other hand is this the intended use?
This is what the documentation says:
public byte[] getBytes(int columnIndex)
throws SQLException
Retrieves the value of the designated column in the current row
of this ResultSet object as a byte array in the Java
programming language. The bytes represent the raw values
returned by the driver.
It seems to imply that it _should_ return a byte array for any arbitary column. But as usual, it's up to us to decide.
Ithink it's reasonable, since we are working with byte arrays in the code anyway.
--
Jason Davies
jason@netspade.com
Attachment
Well I think we can restore the orignal functionality of getBytes so
that it returns a byte array for other objects
As long as we preserve the functionality for bytea types, and
LargeObjects
Dave
-----Original Message-----
From: Jason Davies [mailto:jason@netspade.com]
Sent: October 28, 2001 8:34 AM
To: Dave Cramer
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] DatabaseMetaData.getTables()
On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote:
> It appears the getBytes was previously being used to return a byte
> array of any arbitrary column.
>
> Fixes for blobs seem to have broken this. The question is as Jason
> pointed out which do we fix.
>
> It doesn't seem unreasonable to be able to return a byte array for any
> arbitray column. On the other hand is this the intended use?
This is what the documentation says:
public byte[] getBytes(int columnIndex)
throws SQLException
Retrieves the value of the designated column in the current
row
of this ResultSet object as a byte array in the Java
programming language. The bytes represent the raw values
returned by the driver.
It seems to imply that it _should_ return a byte array for any arbitary
column. But as usual, it's up to us to decide. I think it's reasonable,
since we are working with byte arrays in the code anyway.
--
Jason Davies
jason@netspade.com
Barry, The spec is probably ambiguous about this. The way everyone uses the getters/setters is to get, and set an object into the db. I doubt there is anything in the spec stopping us from retrieving an arbitrary column as a byte[]. I see this as being innocuous. The user would normally set/get any object using the appropriate setter, and if we allow a user to retrive any object as a byte[] then it's just 'extra' functionality. Of course we could just make this an internal driver method as well Thanks for taking care of it, Dave -----Original Message----- From: Barry Lind [mailto:barry@xythos.com] Sent: October 29, 2001 1:51 PM To: Dave@micro-automation.net Cc: pgsql-jdbc@postgresql.org Subject: Re: DatabaseMetaData.getTables() Dave, I will look into this. I will check the jdbc spec to see what it says should happen. Since it was my getBytes() changes that broke this, I will take responsibility for fixing. thanks, --Barry Dave Cramer wrote: > It appears the getBytes was previously being used to return a byte > array of any arbitrary column. > > Fixes for blobs seem to have broken this. The question is as Jason > pointed out which do we fix. > > It doesn't seem unreasonable to be able to return a byte array for any > arbitray column. On the other hand is this the intended use? > > Dave > > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Jason Davies > Sent: October 27, 2001 8:26 PM > To: pgsql-jdbc@postgresql.org > Subject: [JDBC] DatabaseMetaData.getTables() > > > Hi, > > There seems to be a problem with DatabaseMetaData.getTables() when I > do the following: > > ResultSet R=conn.getMetaData().getTables(null, null, "%", null); > > It throws a NullPointerException: > > java.lang.NullPointerException > at > org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java: > 17 > 32) > at Test.main(Test.java:66) > > Looking at the source, ResultSet.getBytes() is called and it returns > null, causing this exception to be thrown. However I can use > ResultSet.getString() without a problem. I'm using 7.1.3 at the > moment. Does ResultSet.getBytes() need to be fixed or should > getTables() be modified? > > I'd be grateful for any insights. Or you can just tell me to use the > latest cvs version of PostgreSQL :) What is the consensus on > supporting older versions, will you phase out old code when 7.2 comes > out? > >
Dave, I will look into this. I will check the jdbc spec to see what it says should happen. Since it was my getBytes() changes that broke this, I will take responsibility for fixing. thanks, --Barry Dave Cramer wrote: > It appears the getBytes was previously being used to return a byte array > of any arbitrary column. > > Fixes for blobs seem to have broken this. The question is as Jason > pointed out which do we fix. > > It doesn't seem unreasonable to be able to return a byte array for any > arbitray column. On the other hand is this the intended use? > > Dave > > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Jason Davies > Sent: October 27, 2001 8:26 PM > To: pgsql-jdbc@postgresql.org > Subject: [JDBC] DatabaseMetaData.getTables() > > > Hi, > > There seems to be a problem with DatabaseMetaData.getTables() when I do > the following: > > ResultSet R=conn.getMetaData().getTables(null, null, "%", null); > > It throws a NullPointerException: > > java.lang.NullPointerException > at > org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java:17 > 32) > at Test.main(Test.java:66) > > Looking at the source, ResultSet.getBytes() is called and it returns > null, causing this exception to be thrown. However I can use > ResultSet.getString() without a problem. I'm using 7.1.3 at the moment. > Does ResultSet.getBytes() need to be fixed or should getTables() be > modified? > > I'd be grateful for any insights. Or you can just tell me to use the > latest cvs version of PostgreSQL :) What is the consensus on supporting > older versions, will you phase out old code when 7.2 comes out? > >
Jason, Thanks, this won't quite work in the new code due to the test for server version 7.2, but will suffice for my current work. Dave -----Original Message----- From: Jason Davies [mailto:jason@netspade.com] Sent: October 29, 2001 2:45 PM To: Dave Cramer Cc: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] DatabaseMetaData.getTables() Hi, Here is a diff that fixes ResultSet.getBytes() so that it returns a byte[] array but preserves the functionality for other objects. I also noticed that in Java 1.4, DatabaseMetaData.getTables() returns 10 columns instead of the 5 in Java 1.3. Is this considered JDBC 3? Jason On Sun, Oct 28, 2001 at 10:56:30AM -0500, Dave Cramer wrote: > Well I think we can restore the orignal functionality of getBytes so > that it returns a byte array for other objects As long as we preserve > the functionality for bytea types, and LargeObjects > > Dave > > -----Original Message----- > From: Jason Davies [mailto:jason@netspade.com] > Sent: October 28, 2001 8:34 AM > To: Dave Cramer > Cc: pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] DatabaseMetaData.getTables() > > > On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote: > > It appears the getBytes was previously being used to return a byte > > array of any arbitrary column. > > > > Fixes for blobs seem to have broken this. The question is as Jason > > pointed out which do we fix. > > > > It doesn't seem unreasonable to be able to return a byte array for > > any > > > arbitray column. On the other hand is this the intended use? > > This is what the documentation says: > > public byte[] getBytes(int columnIndex) > throws SQLException > > Retrieves the value of the designated column in the current > row > of this ResultSet object as a byte array in the Java > programming language. The bytes represent the raw values > returned by the driver. > > It seems to imply that it _should_ return a byte array for any > arbitary column. But as usual, it's up to us to decide. I think it's > reasonable, since we are working with byte arrays in the code anyway. > > -- > Jason Davies > > jason@netspade.com > > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Jason Davies jason@netspade.com
Hi, Here is a diff that fixes ResultSet.getBytes() so that it returns a byte[] array but preserves the functionality for otherobjects. I also noticed that in Java 1.4, DatabaseMetaData.getTables() returns 10 columns instead of the 5 in Java 1.3. Is this consideredJDBC 3? Jason On Sun, Oct 28, 2001 at 10:56:30AM -0500, Dave Cramer wrote: > Well I think we can restore the orignal functionality of getBytes so > that it returns a byte array for other objects > As long as we preserve the functionality for bytea types, and > LargeObjects > > Dave > > -----Original Message----- > From: Jason Davies [mailto:jason@netspade.com] > Sent: October 28, 2001 8:34 AM > To: Dave Cramer > Cc: pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] DatabaseMetaData.getTables() > > > On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote: > > It appears the getBytes was previously being used to return a byte > > array of any arbitrary column. > > > > Fixes for blobs seem to have broken this. The question is as Jason > > pointed out which do we fix. > > > > It doesn't seem unreasonable to be able to return a byte array for any > > > arbitray column. On the other hand is this the intended use? > > This is what the documentation says: > > public byte[] getBytes(int columnIndex) > throws SQLException > > Retrieves the value of the designated column in the current > row > of this ResultSet object as a byte array in the Java > programming language. The bytes represent the raw values > returned by the driver. > > It seems to imply that it _should_ return a byte array for any arbitary > column. But as usual, it's up to us to decide. I think it's reasonable, > since we are working with byte arrays in the code anyway. > > -- > Jason Davies > > jason@netspade.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Jason Davies jason@netspade.com
Attachment
This should now be fixed in current sources. Thanks for finding and reporting the problem. --Barry Dave Cramer wrote: > Jason, > > Thanks, this won't quite work in the new code due to the test for server > version 7.2, but will suffice for my current work. > > Dave > > -----Original Message----- > From: Jason Davies [mailto:jason@netspade.com] > Sent: October 29, 2001 2:45 PM > To: Dave Cramer > Cc: pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] DatabaseMetaData.getTables() > > > Hi, > > Here is a diff that fixes ResultSet.getBytes() so that it returns a > byte[] array but preserves the functionality for other objects. > > I also noticed that in Java 1.4, DatabaseMetaData.getTables() returns 10 > columns instead of the 5 in Java 1.3. Is this considered JDBC 3? > > Jason > > On Sun, Oct 28, 2001 at 10:56:30AM -0500, Dave Cramer wrote: > >>Well I think we can restore the orignal functionality of getBytes so >>that it returns a byte array for other objects As long as we preserve >>the functionality for bytea types, and LargeObjects >> >>Dave >> >>-----Original Message----- >>From: Jason Davies [mailto:jason@netspade.com] >>Sent: October 28, 2001 8:34 AM >>To: Dave Cramer >>Cc: pgsql-jdbc@postgresql.org >>Subject: Re: [JDBC] DatabaseMetaData.getTables() >> >> >>On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote: >> >>>It appears the getBytes was previously being used to return a byte >>>array of any arbitrary column. >>> >>>Fixes for blobs seem to have broken this. The question is as Jason >>>pointed out which do we fix. >>> >>>It doesn't seem unreasonable to be able to return a byte array for >>>any >>> >>>arbitray column. On the other hand is this the intended use? >>> >>This is what the documentation says: >> >>public byte[] getBytes(int columnIndex) >> throws SQLException >> >> Retrieves the value of the designated column in the current >>row >> of this ResultSet object as a byte array in the Java >> programming language. The bytes represent the raw values >> returned by the driver. >> >>It seems to imply that it _should_ return a byte array for any >>arbitary column. But as usual, it's up to us to decide. I think it's >>reasonable, since we are working with byte arrays in the code anyway. >> >>-- >>Jason Davies >> >>jason@netspade.com >> >> >>---------------------------(end of >>broadcast)--------------------------- >>TIP 4: Don't 'kill -9' the postmaster >> >
Ok, with the latest changes and some logging added to the driver I have been able to fix the driver to work with staroffice6 beta I am having some difficulty getting it to work with druid however. At this point druid won't even load the driver. I am pretty confident that I can get around this today. Are there any other tools out there that people are using that I can check for compatability with? Dave
I have been experimenting with adding logging to the driver.
I think it was Gunnar that suggested that I try using log4j. I am
running into a number of difficulties with this and would like to throw
them out to see if there are some solutions.
1) configuring log4j requires an external file to be read, or
configuration inside the driver at startup time. I have tried putting
the configuration file log4j.properties into the jar and letting log4j
initialize itself. This didn't work; it seems the default
Classloader.getSystemResource("log4j.properties") doesn't find it inside
the jar?? So I wrote a little code to get it as a resource bundle much
like the error messages. This worked fine for things that load the
driver in the usual manner, but then while debugging druid, I found that
it doesn't load the driver in the "usual" manner but instead uses the
JarClassLoader. For some reason log4j didn't get initialized properly. I
am sure I can figure out a way around this, but I'm not sure I want to
pursue the log4j option much further.
2)Perceived problems with log4j:
a)we will have to ship another jar with the code.
b)the log4j.properties file has to be placed somewhere on the
filesystem and I'm not sure yet where that should be. It may turn
out that depending on your application the property file has to be
somewhere different.
c) I think due to a and b above we are going to make it more
difficult for new users to get the driver up and running
At this point I am thinking about how to make it default to log nothing,
and then provide properties for the driver to turn on selective logging.
My biggest concern is requiring the installation of another jar, and the
associated problems building the driver
Any suggestions are welcome,
Dave
On Tue, 30 Oct 2001 09:26:01 -0500, you wrote: >Are there any other tools out there that people are using that I can >check for compatability with? Yes, Justin posted this two months ago. It's about a design tool called DbVisualizer. :To: pgsql-jdbc@postgresql.org :Subject: [JDBC] Need help with JDBC driver. Problem, - getExportedKeys = : Driver.notImplemented() exception :From: Justin Clift <justin@postgresql.org> :Date: Sat, 01 Sep 2001 21:26:52 +1000 :Cc: Roger Bjärevall <roger@ideit.com> : :Hi all, : :Does anyone know if we're planning on adding the Java :class/function/method/whatever called getExportedKeys? (I'm not a Java :programmer). : :I've been looking at the free Java product called DbVisualizer :(http://www.ideit.com/innovations/dbvis/), which can connect to a :database and create an ER diagram from it, including RI information and :everything. Presently it supports several databases happily, but the :PostgreSQL JDBC 7.1.3 driver isn't passing information to it regarding :the RI relationships. So for PostgreSQL it gives a nice display of all :the tables, but no display of their relationships. : :Here's a screenshot of what it's supposed to display, when all the RI :relationships are shown : : :http://www.ideit.com/innovations/dbvis/images/dbvis-4.gif : :In discussing this with Roger (the Product Manager of Innovative-IT who :has created this program), he says our JDBC driver gives a :Driver.notImplemented() exception when trying to find out the RI info. :(Email history detailed below). : :Can anyone please assist with this? : :Regards and best wishes, : :Justin Clift Regards, René Pijlman <rene@lab.applinet.nl>
It works with the latest version of DbVisualizer, as well as druid. But only if the db is > 7.1 Dave -----Original Message----- From: Rene Pijlman [mailto:rene@lab.applinet.nl] Sent: October 30, 2001 12:46 PM To: Dave@micro-automation.net Cc: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Staroffice compatability On Tue, 30 Oct 2001 09:26:01 -0500, you wrote: >Are there any other tools out there that people are using that I can >check for compatability with? Yes, Justin posted this two months ago. It's about a design tool called DbVisualizer. :To: pgsql-jdbc@postgresql.org :Subject: [JDBC] Need help with JDBC driver. Problem, - getExportedKeys = : Driver.notImplemented() exception :From: Justin Clift <justin@postgresql.org> :Date: Sat, 01 Sep 2001 21:26:52 +1000 :Cc: Roger Bjärevall <roger@ideit.com> : :Hi all, : :Does anyone know if we're planning on adding the Java :class/function/method/whatever called getExportedKeys? (I'm not a Java :programmer). : :I've been looking at the free Java product called DbVisualizer :(http://www.ideit.com/innovations/dbvis/), which can connect to a :database and create an ER diagram from it, including RI information and :everything. Presently it supports several databases happily, but the :PostgreSQL JDBC 7.1.3 driver isn't passing information to it regarding :the RI relationships. So for PostgreSQL it gives a nice display of all :the tables, but no display of their relationships. : :Here's a screenshot of what it's supposed to display, when all the RI :relationships are shown : : :http://www.ideit.com/innovations/dbvis/images/dbvis-4.gif : :In discussing this with Roger (the Product Manager of Innovative-IT who :has created this program), he says our JDBC driver gives a :Driver.notImplemented() exception when trying to find out the RI info. :(Email history detailed below). : :Can anyone please assist with this? : :Regards and best wishes, : :Justin Clift Regards, René Pijlman <rene@lab.applinet.nl>
Hi
I think the problem is that the property file isn't inside a "package"???
One thing I often do with log4j properties is put the props file inside
the jar within the same directory as the other .class files, ie in
org/postgresql/. Then use a snippet of code like:
props.load((org.postgresql.Driver.class).getClassLoader().getResourceAsStream(
"org/postgresql/postgresql_jdbc.props" ));
That way you are using the same ClassLoader that loaded the
org.postgresql.Driver class.
Maybe helps???
PHilip
On Tue, 30 Oct 2001, Dave Cramer wrote:
> I have been experimenting with adding logging to the driver.
>
> I think it was Gunnar that suggested that I try using log4j. I am
> running into a number of difficulties with this and would like to throw
> them out to see if there are some solutions.
>
> 1) configuring log4j requires an external file to be read, or
> configuration inside the driver at startup time. I have tried putting
> the configuration file log4j.properties into the jar and letting log4j
> initialize itself. This didn't work; it seems the default
> Classloader.getSystemResource("log4j.properties") doesn't find it inside
> the jar?? So I wrote a little code to get it as a resource bundle much
> like the error messages. This worked fine for things that load the
> driver in the usual manner, but then while debugging druid, I found that
> it doesn't load the driver in the "usual" manner but instead uses the
> JarClassLoader. For some reason log4j didn't get initialized properly. I
> am sure I can figure out a way around this, but I'm not sure I want to
> pursue the log4j option much further.
>
> 2)Perceived problems with log4j:
>
> a)we will have to ship another jar with the code.
> b)the log4j.properties file has to be placed somewhere on the
> filesystem and I'm not sure yet where that should be. It may turn
> out that depending on your application the property file has to be
> somewhere different.
> c) I think due to a and b above we are going to make it more
> difficult for new users to get the driver up and running
>
> At this point I am thinking about how to make it default to log nothing,
> and then provide properties for the driver to turn on selective logging.
> My biggest concern is requiring the installation of another jar, and the
> associated problems building the driver
>
> Any suggestions are welcome,
>
> Dave
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
Actually I tried that, but will try again. Even so it appears that the
way druid loads the driver my kludge with getResourceBundle fails as
well. This is a little troubling as I suspect the errors.properties
won't be loaded either.
Dave
-----Original Message-----
From: Philip Crotwell [mailto:crotwell@seis.sc.edu]
Sent: October 30, 2001 1:35 PM
To: Dave Cramer
Cc: 'Barry Lind'; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Driver Logging
Hi
I think the problem is that the property file isn't inside a
"package"???
One thing I often do with log4j properties is put the props file inside
the jar within the same directory as the other .class files, ie in
org/postgresql/. Then use a snippet of code like:
props.load((org.postgresql.Driver.class).getClassLoader().getResourceAsS
tream(
"org/postgresql/postgresql_jdbc.props" ));
That way you are using the same ClassLoader that loaded the
org.postgresql.Driver class.
Maybe helps???
PHilip
On Tue, 30 Oct 2001, Dave Cramer wrote:
> I have been experimenting with adding logging to the driver.
>
> I think it was Gunnar that suggested that I try using log4j. I am
> running into a number of difficulties with this and would like to
> throw them out to see if there are some solutions.
>
> 1) configuring log4j requires an external file to be read, or
> configuration inside the driver at startup time. I have tried putting
> the configuration file log4j.properties into the jar and letting log4j
> initialize itself. This didn't work; it seems the default
> Classloader.getSystemResource("log4j.properties") doesn't find it
> inside the jar?? So I wrote a little code to get it as a resource
> bundle much like the error messages. This worked fine for things that
> load the driver in the usual manner, but then while debugging druid, I
> found that it doesn't load the driver in the "usual" manner but
> instead uses the JarClassLoader. For some reason log4j didn't get
> initialized properly. I am sure I can figure out a way around this,
> but I'm not sure I want to pursue the log4j option much further.
>
> 2)Perceived problems with log4j:
>
> a)we will have to ship another jar with the code.
> b)the log4j.properties file has to be placed somewhere on the
> filesystem and I'm not sure yet where that should be. It may turn out
> that depending on your application the property file has to be
> somewhere different.
> c) I think due to a and b above we are going to make it more
> difficult for new users to get the driver up and running
>
> At this point I am thinking about how to make it default to log
> nothing, and then provide properties for the driver to turn on
> selective logging. My biggest concern is requiring the installation of
> another jar, and the associated problems building the driver
>
> Any suggestions are welcome,
>
> Dave
>
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
Hi Dave, One of the best tools I've found that "needs to work" with PostgreSQL is DbVisualizer : http://www.ideit.com/products/dbvis/ Truly awesome, free Java based tool for doing ERD type stuff. :) Regards and best wishes, Justin Clift Dave Cramer wrote: > > Ok, with the latest changes and some logging added to the driver I have > been able to fix the driver to work with staroffice6 beta > > I am having some difficulty getting it to work with druid however. At > this point druid won't even load the driver. I am pretty confident that > I can get around this today. > > Are there any other tools out there that people are using that I can > check for compatability with? > > Dave -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
I currently have it working with DbVisualizer. I will post my diff's soon Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Justin Clift Sent: October 30, 2001 9:37 PM To: Dave@micro-automation.net Cc: 'Barry Lind'; pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Staroffice compatability Hi Dave, One of the best tools I've found that "needs to work" with PostgreSQL is DbVisualizer: http://www.ideit.com/products/dbvis/ Truly awesome, free Java based tool for doing ERD type stuff. :) Regards and best wishes, Justin Clift Dave Cramer wrote: > > Ok, with the latest changes and some logging added to the driver I > have been able to fix the driver to work with staroffice6 beta > > I am having some difficulty getting it to work with druid however. At > this point druid won't even load the driver. I am pretty confident > that I can get around this today. > > Are there any other tools out there that people are using that I can > check for compatability with? > > Dave -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
On Tue, 2001-10-30 at 15:26, Dave Cramer wrote: > Ok, with the latest changes and some logging added to the driver I have > been able to fix the driver to work with staroffice6 beta Can you put the URL in your sig please Dave. That way we could click through to the latest versions as needed. Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
Philip,
Yes this works! Thanks for the help,
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Philip Crotwell
Sent: October 30, 2001 1:35 PM
To: Dave Cramer
Cc: 'Barry Lind'; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Driver Logging
Hi
I think the problem is that the property file isn't inside a
"package"???
One thing I often do with log4j properties is put the props file inside
the jar within the same directory as the other .class files, ie in
org/postgresql/. Then use a snippet of code like:
props.load((org.postgresql.Driver.class).getClassLoader().getResourceAsS
tream(
"org/postgresql/postgresql_jdbc.props" ));
That way you are using the same ClassLoader that loaded the
org.postgresql.Driver class.
Maybe helps???
PHilip
On Tue, 30 Oct 2001, Dave Cramer wrote:
> I have been experimenting with adding logging to the driver.
>
> I think it was Gunnar that suggested that I try using log4j. I am
> running into a number of difficulties with this and would like to
> throw them out to see if there are some solutions.
>
> 1) configuring log4j requires an external file to be read, or
> configuration inside the driver at startup time. I have tried putting
> the configuration file log4j.properties into the jar and letting log4j
> initialize itself. This didn't work; it seems the default
> Classloader.getSystemResource("log4j.properties") doesn't find it
> inside the jar?? So I wrote a little code to get it as a resource
> bundle much like the error messages. This worked fine for things that
> load the driver in the usual manner, but then while debugging druid, I
> found that it doesn't load the driver in the "usual" manner but
> instead uses the JarClassLoader. For some reason log4j didn't get
> initialized properly. I am sure I can figure out a way around this,
> but I'm not sure I want to pursue the log4j option much further.
>
> 2)Perceived problems with log4j:
>
> a)we will have to ship another jar with the code.
> b)the log4j.properties file has to be placed somewhere on the
> filesystem and I'm not sure yet where that should be. It may turn out
> that depending on your application the property file has to be
> somewhere different.
> c) I think due to a and b above we are going to make it more
> difficult for new users to get the driver up and running
>
> At this point I am thinking about how to make it default to log
> nothing, and then provide properties for the driver to turn on
> selective logging. My biggest concern is requiring the installation of
> another jar, and the associated problems building the driver
>
> Any suggestions are welcome,
>
> Dave
>
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
I have committed my changes which include Jason Davies patch to the repository, so if you want to build your own driver you can update your source from cvs. I have also built a binary on http://jdbc.fastcrypt.com The only one I have gotten to work is the version 1.3 jar ?? If anyone gets the 1.2 jar working let me know. It doesn't seem to connect?? Also Jason's patch fails to compile under jdk 1.1, I will get around to fixing that shortly I would appreciate it if anyone who has more extensive experience with the ERD tools exercise the driver and let me know if there are any problems Thanks, Dave
On Wed, 2001-10-31 at 21:47, Dave Cramer wrote: > I have committed my changes which include Jason Davies patch to the > repository, so if you want to build your own driver you can update your > source from cvs. I have also built a binary on http://jdbc.fastcrypt.com OK got it but... I have staroffice 6 beta installed in my /home directory and search as I might there is no /lib directory only a classes one... Cheers Tony -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
Tony, Just create a lib directory directly under your staroffice directory and place the jar there Dave -----Original Message----- From: tony [mailto:tony@animaproductions.com] Sent: November 1, 2001 12:14 PM To: Dave@micro-automation.net Cc: jdbc list Subject: RE: [JDBC] Staroffice, druid, dbvisualizer compatability On Wed, 2001-10-31 at 21:47, Dave Cramer wrote: > I have committed my changes which include Jason Davies patch to the > repository, so if you want to build your own driver you can update your > source from cvs. I have also built a binary on http://jdbc.fastcrypt.com OK got it but... I have staroffice 6 beta installed in my /home directory and search as I might there is no /lib directory only a classes one... Cheers Tony -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
> I have also built a binary on http://jdbc.fastcrypt.com Thanks for posting these Dave! > The only one I have gotten to work is the version 1.3 jar ?? If anyone > gets the 1.2 jar working let me know. It doesn't seem to connect?? It's working fine for me with DBVisualizer. I haven't played with it extensively yet, but a quick click on each tool gives me the expected results. I'll let you know if I run into any problems, but it looks good so far. -Nick -------------------------------------------------------------------------- Nick Fankhauser nickf@ontko.com Phone 1.765.935.4283 Fax 1.765.962.9788 Ray Ontko & Co. Software Consulting Services http://www.ontko.com/