JDBC connection issue

Hi,

I am having some difficulties connecting to a local postgresql database via jdbc driver.

my setup is:
mandrake 10.0
j2sdk1.4.2
postgresql 7.4.3

I've configured postgresql from its source with --with-java option, make, and make install.

The default directory for the postgresql.jar is /usr/local/pgsql/share/java/postgresql.jar
I've run >jar -tf /usr/local/pgsql/share/java/postgresql.jar and the class files seem to be in the right order.

I've added the following line to the pg_hba.conf to test local connections via jdbc driver.
local all all 127.0.0.1 trust

Also, changed the postgresql.conf
tcpip_socket = true

Added CLASSPATH to bashrc file
export CLASSPATH=/usr/local/pgsql/share/java/postgresql.jar:${CLASSPATH}

and I am trying to run the following code
import java.sql.*;
import java.util.*;

public class Xlang {
public static void main(String[] args) {
try {
Class.forName("org.postgresql.Driver");
...
}
}

and I am getting the following exception..

java.lang.ClassNotFoundException: org.postgresql.Driver

Any ideas would be very much appreciated.

YJ

On Tue, 13 Jul 2004, Young Nam wrote:

> The default directory for the postgresql.jar is
> /usr/local/pgsql/share/java/postgresql.jar I've run >jar -tf
> /usr/local/pgsql/share/java/postgresql.jar and the class files seem to
> be in the right order.
>
> I've added the following line to the pg_hba.conf to test local
> connections via jdbc driver.
> local all all 127.0.0.1 trust

You need to use "host" not "local" here. Local is only for unix sockets
which cannot be used with Java.

> Added CLASSPATH to bashrc file
> export CLASSPATH=/usr/local/pgsql/share/java/postgresql.jar:${CLASSPATH}
>
> java.lang.ClassNotFoundException: org.postgresql.Driver
>

When you check the classpath with something like echo $CLASSPATH is it set
as you specified?

Kris Jurka

JDBC with anything...can be a real pain in the ass!!!!
why don't you learn to connect to the DB using PHP...there's
no drivers involved! Also, the latest thing,
is using DBCP with Jakara Struts...why don't you read about that?
good luck
Ynam(at)sharedmarketing(dot)com ("Young Nam") wrote in message news:<581C48EBC132FF459E62A6809D0D72AE22C749(at)mail(dot)sharedmarketing(dot)com>...
> Hi,
>
> I am having some difficulties connecting to a local postgresql database via
> jdbc driver.
>
> my setup is:
> mandrake 10.0
> j2sdk1.4.2
> postgresql 7.4.3
>
> I've configured postgresql from its source with --with-java option, make, a
> nd make install.
>
> The default directory for the postgresql.jar is /usr/local/pgsql/share/java
> /postgresql.jar
> I've run >jar -tf /usr/local/pgsql/share/java/postgresql.jar and the class
> files seem to be in the right order.
>
> I've added the following line to the pg hba.conf to test local connections
> via jdbc driver.
> local all all 127.0.0.1 trust
>
> Also, changed the postgresql.conf
> tcpip socket = true
>
> Added CLASSPATH to bashrc file
> export CLASSPATH=/usr/local/pgsql/share/java/postgresql.jar:${CLASSPATH}
>
> and I am trying to run the following code
> import java.sql.*;
> import java.util.*;
>
> public class Xlang {
> public static void main(String[] args) {
> try {
> Class.forName("org.postgresql.Driver");
> ...
> }
> }
>
> and I am getting the following exception..
>
> java.lang.ClassNotFoundException: org.postgresql.Driver
>
> Any ideas would be very much appreciated.
>
> YJ
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

Use "md5" instead of "trust". Besides trust having all sorts of
problems to do
with ident daemons, I don't even know if the JDBC driver will work with
ident,
since JDBC network drivers generally pass a username and password. First
get psql working locally before trying to get the JDBC driver to work, like

psql -h hostname -U blaine dbname

Here's a typical md5 record:

host all all 192.168.100.0 255.255.255.0 md5

Where, as you probably know, 192.168.100.0/255.255.255.0 is the permitted
source IP range.

I've worked with about a dozen network JDBC drivers over the past several
years, as a driver developer and a user. Contrary to what some
Java-phobes say,
JDBC drivers are very easy to use directly from Java clients. The
difficulty comes when vendors build shitty abstraction, pooling, and
management functions to isolate your code from the JDBC drivers. Load
your JDBC driver directly with your own code and everything is simple.

I recommend you try my SqlTool client as a utility to get your setup
working.
http://hsqldb.sourceforge.net/guide/ch07.html

>>Hi,
>>
>>I am having some difficulties connecting to a local postgresql database via
>> jdbc driver.
>>
>>my setup is:
>>mandrake 10.0
>>j2sdk1.4.2
>>postgresql 7.4.3
>>
>>I've configured postgresql from its source with --with-java option, make, a
>>nd make install.
>>
>>The default directory for the postgresql.jar is /usr/local/pgsql/share/java
>>/postgresql.jar
>>I've run >jar -tf /usr/local/pgsql/share/java/postgresql.jar and the class
>>files seem to be in the right order.
>>
>>I've added the following line to the pg hba.conf to test local connections
>>via jdbc driver.
>>local all all 127.0.0.1 trust
>>
>>Also, changed the postgresql.conf
>>tcpip socket = true
>>
>>Added CLASSPATH to bashrc file
>>export CLASSPATH=/usr/local/pgsql/share/java/postgresql.jar:${CLASSPATH}
>>
>>and I am trying to run the following code
>>import java.sql.*;
>>import java.util.*;
>>
>>public class Xlang {
>> public static void main(String[] args) {
>> try {
>> Class.forName("org.postgresql.Driver");
>> ...
>> }
>>}
>>
>>and I am getting the following exception..
>>
>>java.lang.ClassNotFoundException: org.postgresql.Driver
>>
>>Any ideas would be very much appreciated.
>>
>>YJ
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 9: the planner will ignore your desire to choose an index scan if your
>> joining column's datatypes do not match
>>
>>

--
ICF: 703-934-3692 Cell: 703-944-9317

On Wed, 21 Jul 2004, Blaine Simpson wrote:

> Use "md5" instead of "trust". Besides trust having all sorts of
> problems to do with ident daemons, I don't even know if the JDBC driver
> will work with ident, since JDBC network drivers generally pass a
> username and password.

"trust" has nothing to do with "ident" authentication, trust does not do
any authentication at all and just lets you in. Using ident
authentication can be a little tricky with JDBC simply because it uses
tcp/ip to connect as opposed to unix sockets. On the server side these
use different code paths for ident authentication with unix sockets
requiring kernel support for passing user information and tcp/ip sockets
requiring an ident server.

In any case the JDBC driver works fine with both trust and ident
authentication, as far as I know the only authentication method that are
unsupported by the JDBC driver is kerberos.

Kris Jurka

Kris Jurka wrote:

>On Wed, 21 Jul 2004, Blaine Simpson wrote:
>
>
>
>>Use "md5" instead of "trust". Besides trust having all sorts of
>>problems to do with ident daemons, I don't even know if the JDBC driver
>>will work with ident, since JDBC network drivers generally pass a
>>username and password.
>>
>>
>
>"trust" has nothing to do with "ident" authentication, trust does not do
>any authentication at all and just lets you in. Using ident
>authentication can be a little tricky with JDBC simply because it uses
>tcp/ip to connect as opposed to unix sockets. On the server side these
>use different code paths for ident authentication with unix sockets
>requiring kernel support for passing user information and tcp/ip sockets
>requiring an ident server.
>
>
Thanks for the correction. I understand now that ident should work if
you can satisfy
the ident requirements.

I still stand by what I said about trust. If you use TCP/IP, with or
without JDBC,
then if you use "trust" you will have to deal with "... problems to do
with ident
deamons". You just said that if you use "trust" with TCP/IP you need
an ident
server (due to differences in local vs. network socket handling in
server code).
Therefore, if you're running TCP/IP, "trust" has a lot to do with
"ident" authentication.
You don't need an ident server if you use "md5", you do need an ident
server if you
use "trust".

>In any case the JDBC driver works fine with both trust and ident
>authentication, as far as I know the only authentication method that are
>unsupported by the JDBC driver is kerberos.
>
>Kris Jurka
>
>

--
ICF: 703-934-3692 Cell: 703-944-9317

Oliver Jowett wrote:

> Blaine Simpson wrote:
>
>> Oliver Jowett wrote:
>>
>>> Blaine Simpson wrote:
>>>
>>>> You don't need an ident server if you use "md5", you do need an
>>>> ident server if you
>>>> use "trust".
>>>
>>>
>>>
>>>
>>> No. Please read
>>> http://www.postgresql.org/docs/7.4/static/auth-methods.html#AUTH-TRUST
>>
>>
>>
>> I did. It says nothing about setting up trust for networks sockets,
>> implying that it is wide open.
>
>
> Are we reading the same document? The URL I provided explicitly talks
> about network sockets & trust auth. I quote:
>
> trust authentication is only suitable for TCP/IP connections if you
> trust every user on every machine that is allowed to connect to the
> server by the pg_hba.conf lines that specify trust. It is seldom
> reasonable to use trust for any TCP/IP connections other than those
> from localhost (127.0.0.1).

I have very good reading comprehension. It says when TCP/IP suitable to
use, but says nothing
about what the requirements are. As I said, that IMPLIES that there are
no additional requirements
and it is wide open.

The reason I question the implication is not that I can't read, but
because I have tried to use
psql (not JDBC) over tcpip sockets with "ident", and, what do you know,
just like Kris said,
there were system log messages about ident failures. This is because
identd is disabled on
our servers and blocked by our firewalls.

>> But, as I've found in practice, and as Kris Jurka has pointed out,
>> you do have to satisfy ident
>> protocol requirements to use trust with network sockets.
>
>
> You are misquoting Kris. He said:
>
>>> "trust" has nothing to do with "ident" authentication, trust does
>>> not do
>>> any authentication at all and just lets you in.
>>
I know he said that, and I disagree with that because immediately after
he says that
"Using ident authentication can be tricky with JDBC" (you can't do
non-network socket
ident with JDBC according to everything I've read about using the JDBC
Driver) and
"On the server side... requiring kernel support for passing user
infomation and tcp/ip sockets requiring an ident server.". Yes, PG
server-side code
requires identd setup to use ident & tcp/ip.

> When trust auth is configured (for a particular source address), no
> ident query is done at all, so whether that source IP is running an
> ident server or not is irrelevant.
>
> -O

--
ICF: 703-934-3692 Cell: 703-944-9317

Blaine Simpson wrote:
> Oliver Jowett wrote:
>
>> Blaine Simpson wrote:
>>
>>> Oliver Jowett wrote:
>>>
>>>> Blaine Simpson wrote:
>>>>
>>>>> You don't need an ident server if you use "md5", you do need an
>>>>> ident server if you
>>>>> use "trust".

To reiterate -- the second half of this statement is wrong.

> The reason I question the implication is not that I can't read, but
> because I have tried to use
> psql (not JDBC) over tcpip sockets with "ident", and, what do you know,
> just like Kris said,
> there were system log messages about ident failures. This is because
> identd is disabled on
> our servers and blocked by our firewalls.

Sure -- to use ident authentication over TCP/IP, you need an ident
server. There's no disagreement there. But trust authentication is a
completely separate mechanism. It does not require an ident server.

To make sure I wasn't going crazy, I just doublechecked against the
7.4.1 server here. It does not make outgoing ident connections when
accepting connections from an IP that is configured for 'trust'.

>>> But, as I've found in practice, and as Kris Jurka has pointed out,
>>> you do have to satisfy ident
>>> protocol requirements to use trust with network sockets.

[... more about ident authentication needing an ident server ...]

I'm not disagreeing with you about ident authentication -- it's trust
authentication we're talking about.

-O