Thread: Problem with connecting to postgres using jdbc7.0-1.2.jar

Problem with connecting to postgres using jdbc7.0-1.2.jar

From
Peter Adamek
Date:
Hey folks,

This may be a rookie mistake.  I'm trying to use Tomcat 4.0 stand alone
(without using Apache) along with postgres 7.0.3 and jdbc7.0-1.2.jar to
connect from a servlet to the postgres server.
Here is my servlet (it compiles without any problems).

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.sql.*;

public class TestServlet extends HttpServlet {

    Connection db = null;

    public void init (ServletConfig config) throws ServletException {
        super.init(config);

        /* Load the driver */
        try {Class.forName("org.postgresql.Driver");}
        catch (ClassNotFoundException e) {}

        /* Connect to the database */
        try {db =
DriverManager.getConnection("jdbc:postgresql:peter","padamek","");}
        catch (SQLException e) {}
    }

    public void service (HttpServletRequest request,HttpServletResponse
response) throws ServletException, IOException {
        // set content type and other response header fields first
        response.setContentType("text/html");

        // get the communication channel with the requesting client
        PrintWriter out = response.getWriter();

        /* Standard top bit */
        out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML
3.2//EN\">\n"
                    + "<HTML>\n"
                    + "<HEAD>\n"
                    + " <TITLE>Test</TITLE>\n"
                    + "</HEAD>\n"
                    + "<BODY BGCOLOR=\"#FFFFFF\">\n");

        try {
            Statement sql = db.createStatement();
            ResultSet rs = sql.executeQuery("select count(*) from
tblCourses");
            rs.next();
            out.println("<p>There are" +
                        rs.getInt("count")+
                        "rows in this table</p>");
        }
        catch (SQLException e) { out.println(e.toString());}

        /* Standard bottom bit */
        out.println("</BODY>\n"
                    + "</HTML>\n");
        out.close();
    }

    public void destroy() {
        try {db.close();}
        catch (SQLException e) {}
    }
}

When I compile it with the verbose javac option, here is what I get:

[parsing started TestServlet.java]
[parsing completed 116ms]
[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/http/HttpServlet.class)]

[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/GenericServlet.class)]

[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/Object.class)]
[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/Servlet.class)]

[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/ServletConfig.class)]

[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/io/Serializable.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/sql/Connection.class)]
[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/ServletException.class)]

[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/http/HttpServletRequest.class)]

[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/http/HttpServletResponse.class)]

[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/io/IOException.class)]
[checking TestServlet]
[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/Error.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/Exception.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/Throwable.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/RuntimeException.class)]
[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/Class.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/ClassNotFoundException.class)]

[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/sql/DriverManager.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/util/Properties.class)]
[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/String.class)]
[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/sql/SQLException.class)]
[loading
/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar(javax/servlet/ServletResponse.class)]

[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/io/PrintWriter.class)]
[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/io/Writer.class)]
[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/sql/Statement.class)]

[loading /usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/sql/ResultSet.class)]

[loading
/usr/java/jdk1.3.1_02/jre/lib/rt.jar(java/lang/StringBuffer.class)]
[wrote TestServlet.class]
[total 605ms]

My Classpath is set to
CLASSPATH=".:/usr/lib/pgsql/jdbc7.0-1.2.jar:/var/jakarta-tomcat-4.0.1/common/lib/servlet.jar"

When I try to run the servlet, I get the following error (it seems like
the database connection is not being made - db is assigned a null
value):

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.
exception
java.lang.NullPointerException
        at TestServlet.service(TestServlet.java:40)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

        at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)

        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)

        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)

        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)

        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)

        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)

        at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)

        at java.lang.Thread.run(Thread.java:484)

Does anyone have any suggestions?  It seems strage to me that if I
change the driver name that reads
Class.forName("org.postgresql.Driver"), I get no errors when I compile.
I could change it to Class.forName("heyYou") and it would still compile
with no errors.  The other thing that seems strange is that if you look
at the verbose output of my javac call, it seems like the sql
DriverManagement and ResultSet classes are coming from the Java JDK
1.3.1 install and not the postgres 7.0-1.2 JDBC java driver that was
supplied from postgres.org.  Is this just the order of the classes in my
classpath (I only have 2 not including the current directory).

Any help would greately be appreciated.  Or at least a direction in
which to go look.  Thanks in advance.

Peter


Re: Problem with connecting to postgres using jdbc7.0-1.2.jar

From
Rene Pijlman
Date:
On Mon, 24 Dec 2001 00:33:41 -0500, you wrote:
>This may be a rookie mistake.
[...]
>        try {Class.forName("org.postgresql.Driver");}
[...]
>        try {db =
>DriverManager.getConnection("jdbc:postgresql:peter","padamek","");}
>        catch (SQLException e) {}
>    }

At first glance this looks OK (if you can logon using this
connect string and username, and without a password).

The most common rookie mistake is not to configure the
PostgreSQL server to accept incoming connections on a TCP/IP
socket.

Documentation is available on
http://jdbc.postgresql.org/doc.html,
http://www.postgresql.org/idocs/index.php?jdbc.html#JDBC-PREPARE,
http://www.fankhausers.com/postgresql/jdbc/ and
http://www.fankhausers.com/tomcat/jdbc/.

>When I compile it with the verbose javac option, here is what I get:

I don't see a problem in this log.

>When I try to run the servlet, I get the following error (it seems like
>the database connection is not being made - db is assigned a null
>value):

I don't see any mention of 'db' or PostgreSQL in this exception
stack trace.

>It seems strage to me that if I
>change the driver name that reads
>Class.forName("org.postgresql.Driver"), I get no errors when I compile.
>I could change it to Class.forName("heyYou") and it would still compile
>with no errors.

That's normal. Class.forName() is a runtime statement. You would
get another exception if this class can't be found at runtime.

>The other thing that seems strange is that if you look
>at the verbose output of my javac call, it seems like the sql
>DriverManagement and ResultSet classes are coming from the Java JDK
>1.3.1 install and not the postgres 7.0-1.2 JDBC java driver that was
>supplied from postgres.org.

The JDK provides the java.sql interfaces, the driver implements
them.

Have you tried to connect to the same PostgreSQL database from
the same client with a simple 'hello world' application that
does the same class.forName() and uses the same connect string?

Regards,
René Pijlman <rene@lab.applinet.nl>

Re: Problem with connecting to postgres using jdbc7.0-1.2.jar

From
Jens Carlberg
Date:
<snip>
> Here is my servlet (it compiles without any problems).

I've trimmed it to save some space, keeping just the part I have
comments on.

>     public void init (ServletConfig config) throws ServletException {
>         super.init(config);
>
>         /* Load the driver */
>         try {Class.forName("org.postgresql.Driver");}
>         catch (ClassNotFoundException e) {}

While this is an effective way to make the class compile, it raises a
couple of questions:

1. What do you do if the driver class isn't available? If your
application won't work without it, perhaps you should throw a
'show-stopper' instead.

2. Do the JVM find the driver class? The least you should do is _log_
the exception; if you see that message, you'll know the problem lies
with finding the driver.

>         /* Connect to the database */
>         try {db =
> DriverManager.getConnection("jdbc:postgresql:peter","padamek","");}

This doesn't look right to me. Isn't the syntax
jdbc:postgresql://host-name/db-name?

>         catch (SQLException e) {}

OK, your class compiles, but once again you're left without a clue on
why the application doesn't do what you expect. Place a log statement
inside the catch, and you'll be a lot wiser if this is where is goes
awry.

>     }
<snip>
>         try {
>             Statement sql = db.createStatement();

My guess is that db weren't initialized properly in the init() method.
Thus the above statement generates a NullPointer exception. If you want
to be sure, check for db == null and print something instead of trying
to query the DB.

<snip>

> Does anyone have any suggestions?  It seems strage to me that if I
> change the driver name that reads
> Class.forName("org.postgresql.Driver"), I get no errors when I compile.

Since it's a string that will be used at runtime to identify a class, it
cannot be caught at compile time. Pro: you don't have to have the
postgresql jar in the compile classpath, only the servers. Con: You have
to consider and write code for handling a ClassNotFoundException at
runtime.

If you wan't to handle it at compile time, look up the method
DriverManager.registerDriver(Driver driver). The driver calls this
itself when it is loaded, so it would be extra work without any good
effects besides that you no longer need to catch CLasNotFound but a
SQLException. :-)

Yours,
///Jens Carlberg

Re: Problem with connecting to postgres using jdbc7.0-1.2.jar

From
"K. Ari Krupnikov"
Date:
Jens Carlberg wrote:
>
> > Does anyone have any suggestions?  It seems strage to me that if I
> > change the driver name that reads
> > Class.forName("org.postgresql.Driver"), I get no errors when I compile.

[...]

> If you wan't to handle it at compile time, look up the method
> DriverManager.registerDriver(Driver driver). The driver calls this
> itself when it is loaded, so it would be extra work without any good
> effects besides that you no longer need to catch CLasNotFound but a
> SQLException. :-)

You can simply say

new org.postgresql.Driver ();

The constructor (actually the static initialization) will call
registerDriver() for you.

Ari.

Problem with connecting to postgres using JDBC with JSP, but not JDBC with Java

From
Peter Adamek
Date:
First off, many thanks to Rene Pijlman, Jens Carlberg and K.Ari Kruprikov
for your previous emails regarding the subcect Problem with connecting to
postgres using jdbc7.0-1.2.jar.  Your suggestions have been very
informative.

I must confess, I am somewhat new to JSP and Java as a whole.  My background
is in ASP development and I am dying to fully convert over.  I am getting
the hang of things pretty well.  I have a full arsenal of Oreiley and Wrox
books I've gone out to purchase at my disposal on Java 2, JSP 2nd eddition,
Databases with PostgreSQL, etc.  I'm also running Red Hat Linux 7.1.
Switched over from NT 4.0.  So please bear with me.

I have used your suggestion Rene and tried connecting to my postgresql
database using the "HelloPostgreSQL.java" pure JAVA (non-JSP) program
located at http://www.fankhausers.com/postgresql/jdbc/.  Running this
enabled me to connect to the database, create tables, insert data, delete
data and drop tables.

Subsequent to this, I tried to modify my JSP code to also connect to the
database (using the same connection string and all), but I kept on getting
the following run time error in my browser:

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.
exception
java.lang.NullPointerException
        at TestServlet.service(TestServlet.java:40)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

        at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)

        at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)

        at java.lang.Thread.run(Thread.java:484)

At this point, I followed Jens suggestion to modify my code to the
following.  In the following code, I don't run any SQL statements against
the database, but after attempting to make the database connection, I check
to see if it (the connection) is equal to null and sure enough it is.  This
is what was generating the above error.  So at this point, I'm not sure of
what to do to.  I think my problem is in the way the drivers or classes are
being initialized, but I'm not sure.  I have folllowed the standard way to
connect to the database as has been suggested in the books and on numerous
sites, but nothing seems to work.  I know the connection string works fine,
becuase the same one works in my "HelloPostgreSQL.java" pure JAVA (non-JSP)
program.

One thing that I am thinking is that it may be the way I am running Tomcat.
I have downloaded the binary, untared it as su and when I run the startup
script, I run it as su (standalone without having it be integrated with
Apache).  Could this present some problem?  What context would you suggest
running Tomcat as (there seems to be very limited documentation on
this)?  If I should run it as another user, I supposes I have to change the
ownership of all files in the $TOMCAT_HOME tree to that user context
otherwise I may not get permission to certain files.  I am also in the
middle of trying to integrate my Tomcat with Apache to see if maybe that
type of setup will do the trick.  Any suggestions once again would be
greatly appreciated (and don't be afraid to say the obvious - it may not be
obvious to me).  Many thanks again to Rene, Jens and Ari.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.sql.*;

public class TestServlet extends HttpServlet {

    Connection db;
    String database = "peter";
    String username = "myLogin";
    String password = "myPassword";

    public void init (ServletConfig config) throws ServletException {
        super.init(config);

        /* Load the driver */
        try {Class.forName("org.postgresql.Driver");}
        catch (ClassNotFoundException e) {}

        /* Connect to the database */
        try {db =
DriverManager.getConnection("jdbc:postgresql:"+database,username,password);}

        catch (SQLException e) {}
    }

    public void service (HttpServletRequest request,HttpServletResponse
response) throws ServletException, IOException {
        // set content type and other response header fields first
        response.setContentType("text/html");

        // get the communication channel with the requesting client
        PrintWriter out = response.getWriter();

        /* Standard top bit */
        out.println("<HTML>\n"
                    + "<HEAD>\n"
                    + " <TITLE>Test</TITLE>\n"
                    + "</HEAD>\n"
                    + "<BODY BGCOLOR=\"#FFFFFF\">\n");

        if (db == null) {
           out.println("Database is not being opened.<br>");

        }

        /* Standard bottom bit */
        out.println("</BODY>\n"
                    + "</HTML>\n");
        out.close();
    }

    public void destroy() {
        try {db.close();}
        catch (SQLException e) {}
    }
}



Re: Problem with connecting to postgres using JDBC with JSP, but not

From
Jens Carlberg
Date:
<snip>

> At this point, I followed Jens suggestion to modify my code to the
> following.  In the following code, I don't run any SQL statements against
> the database, but after attempting to make the database connection, I check
> to see if it (the connection) is equal to null and sure enough it is.  This
> is what was generating the above error.  So at this point, I'm not sure of
> what to do to.  I think my problem is in the way the drivers or classes are
> being initialized, but I'm not sure.  I have folllowed the standard way to
> connect to the database as has been suggested in the books and on numerous
> sites, but nothing seems to work.  I know the connection string works fine,
> becuase the same one works in my "HelloPostgreSQL.java" pure JAVA (non-JSP)
> program.

Since you don't get a Connection, the problem most likely is a CLASSPATH
problem, i.e. the JVM that runs Tomcat doesn't find the Postgresql
Driver class. I suggest you replace

/* Load the driver */
try {Class.forName("org.postgresql.Driver");}
catch (ClassNotFoundException e) {}

with

/* Load the driver */
try {new org.postgresql.Driver();}
catch (SQLException e) {}

This will have 2 effects:
1. You have to have the Postgresql jar in your CLASSPATH when you
compile (or have it in the JVMs ext-directory).
2. If the jar is missing in Tomcats JVMs CLASSPATH, you should get a
clear error in the log, stating it couldn't find the class
org.postgresql.Driver.

Hm, if I'm right in my guesses, the jar isn't in Tomcats CLASSPATH.
Perhaps you could save yourself some trouble by checking that out first.
Check this HOW-TO:

http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html

<snip>

Yours,
///Jens Carlberg

Peter,

As an aside, if you want to make the complete transition (IMO) have a
look at velocity (http://jakarta.apache.org/velocity), or
(www.webmacro.org) webmacro , and get rid of JSP too!

I see you are at U of T, I am in Orangeville!

Cheers,

Dave

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Peter Adamek
Sent: Thursday, December 27, 2001 2:16 AM
To: Jens Carlberg
Cc: pgsql-jdbc@postgresql.org
Subject: [JDBC] Problem with connecting to postgres using JDBC with JSP,
but not JDBC with Java


First off, many thanks to Rene Pijlman, Jens Carlberg and K.Ari
Kruprikov for your previous emails regarding the subcect Problem with
connecting to postgres using jdbc7.0-1.2.jar.  Your suggestions have
been very informative.

I must confess, I am somewhat new to JSP and Java as a whole.  My
background is in ASP development and I am dying to fully convert over.
I am getting the hang of things pretty well.  I have a full arsenal of
Oreiley and Wrox books I've gone out to purchase at my disposal on Java
2, JSP 2nd eddition, Databases with PostgreSQL, etc.  I'm also running
Red Hat Linux 7.1. Switched over from NT 4.0.  So please bear with me.

I have used your suggestion Rene and tried connecting to my postgresql
database using the "HelloPostgreSQL.java" pure JAVA (non-JSP) program
located at http://www.fankhausers.com/postgresql/jdbc/.  Running this
enabled me to connect to the database, create tables, insert data,
delete data and drop tables.

Subsequent to this, I tried to modify my JSP code to also connect to the
database (using the same connection string and all), but I kept on
getting the following run time error in my browser:

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error type
Exception report message Internal Server Error description The server
encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request. exception
java.lang.NullPointerException
        at TestServlet.service(TestServlet.java:40)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)

        at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:213)

        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)

        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:201)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)

        at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:472)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:234
4)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:164)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)

        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)

        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:170)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)

        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462
)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:163)

        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)

        at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
        at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
        at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1011)

        at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1106)

        at java.lang.Thread.run(Thread.java:484)

At this point, I followed Jens suggestion to modify my code to the
following.  In the following code, I don't run any SQL statements
against the database, but after attempting to make the database
connection, I check to see if it (the connection) is equal to null and
sure enough it is.  This is what was generating the above error.  So at
this point, I'm not sure of what to do to.  I think my problem is in the
way the drivers or classes are being initialized, but I'm not sure.  I
have folllowed the standard way to connect to the database as has been
suggested in the books and on numerous sites, but nothing seems to work.
I know the connection string works fine, becuase the same one works in
my "HelloPostgreSQL.java" pure JAVA (non-JSP) program.

One thing that I am thinking is that it may be the way I am running
Tomcat. I have downloaded the binary, untared it as su and when I run
the startup script, I run it as su (standalone without having it be
integrated with Apache).  Could this present some problem?  What context
would you suggest running Tomcat as (there seems to be very limited
documentation on this)?  If I should run it as another user, I supposes
I have to change the ownership of all files in the $TOMCAT_HOME tree to
that user context otherwise I may not get permission to certain files.
I am also in the middle of trying to integrate my Tomcat with Apache to
see if maybe that type of setup will do the trick.  Any suggestions once
again would be greatly appreciated (and don't be afraid to say the
obvious - it may not be obvious to me).  Many thanks again to Rene, Jens
and Ari.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.sql.*;

public class TestServlet extends HttpServlet {

    Connection db;
    String database = "peter";
    String username = "myLogin";
    String password = "myPassword";

    public void init (ServletConfig config) throws ServletException {
        super.init(config);

        /* Load the driver */
        try {Class.forName("org.postgresql.Driver");}
        catch (ClassNotFoundException e) {}

        /* Connect to the database */
        try {db =
DriverManager.getConnection("jdbc:postgresql:"+database,username,passwor
d);}

        catch (SQLException e) {}
    }

    public void service (HttpServletRequest request,HttpServletResponse
response) throws ServletException, IOException {
        // set content type and other response header fields first
        response.setContentType("text/html");

        // get the communication channel with the requesting client
        PrintWriter out = response.getWriter();

        /* Standard top bit */
        out.println("<HTML>\n"
                    + "<HEAD>\n"
                    + " <TITLE>Test</TITLE>\n"
                    + "</HEAD>\n"
                    + "<BODY BGCOLOR=\"#FFFFFF\">\n");

        if (db == null) {
           out.println("Database is not being opened.<br>");

        }

        /* Standard bottom bit */
        out.println("</BODY>\n"
                    + "</HTML>\n");
        out.close();
    }

    public void destroy() {
        try {db.close();}
        catch (SQLException e) {}
    }
}



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)



Re: Problem with connecting to postgres using JDBC with JSP, but not JDBC with Java

From
"Nick Fankhauser"
Date:
Peter-

A couple of thoughts-

Apparently the database connection is failing. You want to know why, so I'd
suggest replacing "catch (SQLException e) {}" with "catch (SQLException e)
{e.printStackTrace();}".

Since you're running Tomcat, the stack trace won't appear on the console,
but you should be able to find it in the tomcat log files.  In my case, I'm
on Debian Linux, so to look at the tomcat stdout log, I use "tail -50
/var/log/tomcat/stdout.log". The location probably varies slightly by OS.
(Get 50 lines on the tail because the stack trace will be long <grin>.)

My first guess as to what you'll find in the trace is that it's an
authentication problem. You mention that tomcat is running as su (root?).
Take a look at the pg_hba.conf file for postgresql- It's pretty standard for
it to be set up as "peer sameuser" by default for localhost connections. If
this is the case, Tomcat will be running as root, but your servlet tries to
connect as "peter" & fails the sameuser test for authentication, or even if
the auth method is "trust", root may not be a postgres user. I suppose you
could test this quickly by creating a root postgres user. (I'm not sure what
the longer-term security implications of this would be, but I assume we're
in "make it work" mode right now.)

BTW, tomcat usually runs as www-data by default in most installations (same
as apache), so In my case, I just make sure there is a www-data user in
postgresql & grant that user the privs I need it to have on each object.

I'm running Tomcat 3.2, so your mileage may vary, but it looks to me like
you've licked the Tomcat issues & you're back to postgres now.

Hope this helps-

-Nick

---------------------------------------------------------------------
Nick Fankhauser

Business:
nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
doxpop  - Court records at your fingertips - http://www.doxpop.com/

Personal:
nick@fankhausers.com   http://www.fankhausers.com


> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Peter Adamek
> Sent: Thursday, December 27, 2001 2:16 AM
> To: Jens Carlberg
> Cc: pgsql-jdbc@postgresql.org
> Subject: [JDBC] Problem with connecting to postgres using JDBC with JSP,
> but not JDBC with Java
>
>
> First off, many thanks to Rene Pijlman, Jens Carlberg and K.Ari Kruprikov
> for your previous emails regarding the subcect Problem with connecting to
> postgres using jdbc7.0-1.2.jar.  Your suggestions have been very
> informative.
>
> I must confess, I am somewhat new to JSP and Java as a whole.  My
> background
> is in ASP development and I am dying to fully convert over.  I am getting
> the hang of things pretty well.  I have a full arsenal of Oreiley and Wrox
> books I've gone out to purchase at my disposal on Java 2, JSP 2nd
> eddition,
> Databases with PostgreSQL, etc.  I'm also running Red Hat Linux 7.1.
> Switched over from NT 4.0.  So please bear with me.
>
> I have used your suggestion Rene and tried connecting to my postgresql
> database using the "HelloPostgreSQL.java" pure JAVA (non-JSP) program
> located at http://www.fankhausers.com/postgresql/jdbc/.  Running this
> enabled me to connect to the database, create tables, insert data, delete
> data and drop tables.
>
> Subsequent to this, I tried to modify my JSP code to also connect to the
> database (using the same connection string and all), but I kept on getting
> the following run time error in my browser:
>
> Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error
> type Exception report
> message Internal Server Error
> description The server encountered an internal error (Internal Server
> Error) that prevented it from fulfilling this request.
> exception
> java.lang.NullPointerException
>         at TestServlet.service(TestServlet.java:40)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
> pplicationFilterChain.java:247)
>
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
> onFilterChain.java:193)
>
>         at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
> pplicationFilterChain.java:213)
>
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
> onFilterChain.java:193)
>
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
> erValve.java:243)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:566)
>
>         at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
>         at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardConte
> xtValve.java:201)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:566)
>
>         at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authent
> icatorBase.java:472)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:564)
>
>         at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
>         at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>         at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv
> e.java:164)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:566)
>
>         at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispat
> cherValve.java:170)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:564)
>
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValv
> e.java:170)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:564)
>
>         at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:564)
>
>         at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
>         at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine
> Valve.java:163)
>
>         at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel
> ine.java:566)
>
>         at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
> java:472)
>         at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>         at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProce
> ssor.java:1011)
>
>         at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor
> .java:1106)
>
>         at java.lang.Thread.run(Thread.java:484)
>
> At this point, I followed Jens suggestion to modify my code to the
> following.  In the following code, I don't run any SQL statements against
> the database, but after attempting to make the database
> connection, I check
> to see if it (the connection) is equal to null and sure enough it
> is.  This
> is what was generating the above error.  So at this point, I'm not sure of
> what to do to.  I think my problem is in the way the drivers or
> classes are
> being initialized, but I'm not sure.  I have folllowed the standard way to
> connect to the database as has been suggested in the books and on numerous
> sites, but nothing seems to work.  I know the connection string
> works fine,
> becuase the same one works in my "HelloPostgreSQL.java" pure JAVA
> (non-JSP)
> program.
>
> One thing that I am thinking is that it may be the way I am
> running Tomcat.
> I have downloaded the binary, untared it as su and when I run the startup
> script, I run it as su (standalone without having it be integrated with
> Apache).  Could this present some problem?  What context would you suggest
> running Tomcat as (there seems to be very limited documentation on
> this)?  If I should run it as another user, I supposes I have to
> change the
> ownership of all files in the $TOMCAT_HOME tree to that user context
> otherwise I may not get permission to certain files.  I am also in the
> middle of trying to integrate my Tomcat with Apache to see if maybe that
> type of setup will do the trick.  Any suggestions once again would be
> greatly appreciated (and don't be afraid to say the obvious - it
> may not be
> obvious to me).  Many thanks again to Rene, Jens and Ari.
>
> import java.io.*;
> import javax.servlet.*;
> import javax.servlet.http.*;
> import java.sql.*;
>
> public class TestServlet extends HttpServlet {
>
>     Connection db;
>     String database = "peter";
>     String username = "myLogin";
>     String password = "myPassword";
>
>     public void init (ServletConfig config) throws ServletException {
>         super.init(config);
>
>         /* Load the driver */
>         try {Class.forName("org.postgresql.Driver");}
>         catch (ClassNotFoundException e) {}
>
>         /* Connect to the database */
>         try {db =
> DriverManager.getConnection("jdbc:postgresql:"+database,username,p
> assword);}
>
>         catch (SQLException e) {}
>     }
>
>     public void service (HttpServletRequest request,HttpServletResponse
> response) throws ServletException, IOException {
>         // set content type and other response header fields first
>         response.setContentType("text/html");
>
>         // get the communication channel with the requesting client
>         PrintWriter out = response.getWriter();
>
>         /* Standard top bit */
>         out.println("<HTML>\n"
>                     + "<HEAD>\n"
>                     + " <TITLE>Test</TITLE>\n"
>                     + "</HEAD>\n"
>                     + "<BODY BGCOLOR=\"#FFFFFF\">\n");
>
>         if (db == null) {
>            out.println("Database is not being opened.<br>");
>
>         }
>
>         /* Standard bottom bit */
>         out.println("</BODY>\n"
>                     + "</HTML>\n");
>         out.close();
>     }
>
>     public void destroy() {
>         try {db.close();}
>         catch (SQLException e) {}
>     }
> }
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>


Hi folks!

Great news.  I have solved my problem regarding the Subject line (originally
posted by myself on December 24th under the subject Problem with connecting to
postgres using jdbc7.0-1.2.jar).  I have been wacking my head against my
monitor for the whole week and I managed to get it to work.  It's 3:30 am local
time in Toronto and I should be exhausted, but it started working for me 10
minutes ago and I am on a real high.  I may not even sleep tonight!!!  Feel
free to skip the rest of this note as I'm not including any technical stuff
other than for what I did to fix my problem.

I was unable to execute a servlet that would connect to the database and do
something silly such as select the count(*) of a table.  At the same time I was
able to do this with a non-servlet/non-jsp java program.  I could not figure it
out and I was constantly getting the following error when trying to run the
servlet:

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.
exception
java.lang.NullPointerException

My problem:  I had installed Tomcat 4 from a binary distribution and this has
placed some startup and shutdown wrapper scripts in the $TOMCAT_HOME/bin
directory.  Well these scripts reference the file catalina.sh which is itself a
wrapper script.  Anyway, to make a long story short, the classpath that is used
in the TOMCAT processes when TOMCAT is started using the startup.sh /
catalina.sh scripts does not append to the $CLASSPATH that you define in your
.bashrc file.  So when TOMCAT starts, the jdbc7.0-1.2.jar file (which I had
included in my .bashrc $CLASSPATH variable) is not in the TOMCAT classpath and
hence I was getting the error when trying to connect to the postgresql
database.  I would not see this file when running the stand alone java program
becuase the .bashrc classpath variable was being used and this did include the
reference to the driver.

To fix it, I have very slightly modified the catalina.sh startup file so that
the classpath that it defines contains the jdbc7.0-1.2.jar driver reference.

Many thanks to everyone for all your support and valuable suggestions
especially Rene Piljman, Jens Carlberg, Ari Krupnikov, Nick Fankhauser, Tony,
Mihai Gheorghiu, Dave Cramer and anyone I may have missed.  I have read your
suggestions, but because I am still a rookie with much of this, I will be
trying to internalize everything over the next few days (as I catch up on my
sleep).  I hope you won't mind if I email you again in the next little while to
inquire about some of the details that are unclear to me at this time.

One thing I'll say right now (even though this is not the forum for this) is
that I still don't really understand how you are supposed to maintain a secure
/ consistent system when installing a binary distribution of an application.
Since you untar and unzip it as root all the internal files take on the
ownership and group of root.  Once you move the directory to where you want it,
how can you run any of it under a different user such as www or tomcat (in the
case of TOMCAT) if everything is owned by root (unless if you change the
necessary files to a different owner)?  There does not seem to be good
documentation on what files should be owned by who and I've never seen the
installation process (for any application) documented down to that level.
Maybe I'm just overly concerned about this.  It seems like RPM packages are
much more friendly to install /uninstall and they hanle file permissions
& dependencies for you (as well as creating any additional users that are
needed to run the application), but these are not always available and when
they are, the options they come with are not very customizable (not to mention
that they leave out certain things that are provided when installing a binary
distribution or installing from source).  I guess that installing from source
has the same pitfalls regarding not knowing what to set the file permissions to
as installing binary distributions (with the added worry of running accross
some error that you seem to get and no one else in the world has seen before).
I experienced this earlier tonight when I tried to compile the mod_webapp
module for Apache 1.3 and seeing the famous apxs error.  If anyone has
suggestions or tips or knows where I could go to get a good reference on how
best to install source and binary distributions while maintaining the file
permissions that were intended by the original application developers (without
just blindly setting everything to root - unless if this is exactly the way you
are supposed to do of course), I would really appreciate it.

Happy rest of the holidays everyone and a happy new year.  And once again,
thank you for offering so much support.  I hope I will one day be able to
contribute back to the board as much as you all have to me.

Nick Fankhauser wrote:

> Peter-
>
> A couple of thoughts-
>
> Apparently the database connection is failing. You want to know why, so I'd
> suggest replacing "catch (SQLException e) {}" with "catch (SQLException e)
> {e.printStackTrace();}".
>
> Since you're running Tomcat, the stack trace won't appear on the console,
> but you should be able to find it in the tomcat log files.  In my case, I'm
> on Debian Linux, so to look at the tomcat stdout log, I use "tail -50
> /var/log/tomcat/stdout.log". The location probably varies slightly by OS.
> (Get 50 lines on the tail because the stack trace will be long <grin>.)
>
> My first guess as to what you'll find in the trace is that it's an
> authentication problem. You mention that tomcat is running as su (root?).
> Take a look at the pg_hba.conf file for postgresql- It's pretty standard for
> it to be set up as "peer sameuser" by default for localhost connections. If
> this is the case, Tomcat will be running as root, but your servlet tries to
> connect as "peter" & fails the sameuser test for authentication, or even if
> the auth method is "trust", root may not be a postgres user. I suppose you
> could test this quickly by creating a root postgres user. (I'm not sure what
> the longer-term security implications of this would be, but I assume we're
> in "make it work" mode right now.)
>
> BTW, tomcat usually runs as www-data by default in most installations (same
> as apache), so In my case, I just make sure there is a www-data user in
> postgresql & grant that user the privs I need it to have on each object.
>
> I'm running Tomcat 3.2, so your mileage may vary, but it looks to me like
> you've licked the Tomcat issues & you're back to postgres now.
>
> Hope this helps-
>
> -Nick
>


Peter,

Congratulations on your perserverence!
I have to tell you that when I moved to java from C++ CLASSPATH was
probably the most frustrating thing; and TOMCAT is even more confusing!

The following link gives a good overview of classpath in TOMCAT. (Hint:
there is a much easier way)

http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html


As far as running TOMCAT as non-root goes. The startup scripts are
intended to be as easy to use as possible; so the easiest thing to do is
run as root.

Now if you want to run as non-root you will have to do a little digging.
The command on a unix box is su. Do a man su

FWIW Java is inherently more secure anyway. Buffer overflows are much
more difficult, and there is a built in security manager which you can
tweak to allow/disallow almost everything.

Cheers,
Dave

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Peter Adamek
Sent: Friday, December 28, 2001 4:17 AM
To: nickf@ontko.com
Cc: Jens Carlberg; pgsql-jdbc@postgresql.org
Subject: [JDBC] SOLVED: Problem with connecting to postgres using JDBC
with JSP, but not JDBC with Java


Hi folks!

Great news.  I have solved my problem regarding the Subject line
(originally posted by myself on December 24th under the subject Problem
with connecting to postgres using jdbc7.0-1.2.jar).  I have been wacking
my head against my monitor for the whole week and I managed to get it to
work.  It's 3:30 am local time in Toronto and I should be exhausted, but
it started working for me 10 minutes ago and I am on a real high.  I may
not even sleep tonight!!!  Feel free to skip the rest of this note as
I'm not including any technical stuff other than for what I did to fix
my problem.

I was unable to execute a servlet that would connect to the database and
do something silly such as select the count(*) of a table.  At the same
time I was able to do this with a non-servlet/non-jsp java program.  I
could not figure it out and I was constantly getting the following error
when trying to run the
servlet:

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error type
Exception report message Internal Server Error description The server
encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request. exception
java.lang.NullPointerException

My problem:  I had installed Tomcat 4 from a binary distribution and
this has placed some startup and shutdown wrapper scripts in the
$TOMCAT_HOME/bin directory.  Well these scripts reference the file
catalina.sh which is itself a wrapper script.  Anyway, to make a long
story short, the classpath that is used in the TOMCAT processes when
TOMCAT is started using the startup.sh / catalina.sh scripts does not
append to the $CLASSPATH that you define in your .bashrc file.  So when
TOMCAT starts, the jdbc7.0-1.2.jar file (which I had included in my
.bashrc $CLASSPATH variable) is not in the TOMCAT classpath and hence I
was getting the error when trying to connect to the postgresql database.
I would not see this file when running the stand alone java program
becuase the .bashrc classpath variable was being used and this did
include the reference to the driver.

To fix it, I have very slightly modified the catalina.sh startup file so
that the classpath that it defines contains the jdbc7.0-1.2.jar driver
reference.

Many thanks to everyone for all your support and valuable suggestions
especially Rene Piljman, Jens Carlberg, Ari Krupnikov, Nick Fankhauser,
Tony, Mihai Gheorghiu, Dave Cramer and anyone I may have missed.  I have
read your suggestions, but because I am still a rookie with much of
this, I will be trying to internalize everything over the next few days
(as I catch up on my sleep).  I hope you won't mind if I email you again
in the next little while to inquire about some of the details that are
unclear to me at this time.

One thing I'll say right now (even though this is not the forum for
this) is that I still don't really understand how you are supposed to
maintain a secure / consistent system when installing a binary
distribution of an application. Since you untar and unzip it as root all
the internal files take on the ownership and group of root.  Once you
move the directory to where you want it, how can you run any of it under
a different user such as www or tomcat (in the case of TOMCAT) if
everything is owned by root (unless if you change the necessary files to
a different owner)?  There does not seem to be good documentation on
what files should be owned by who and I've never seen the installation
process (for any application) documented down to that level. Maybe I'm
just overly concerned about this.  It seems like RPM packages are much
more friendly to install /uninstall and they hanle file permissions &
dependencies for you (as well as creating any additional users that are
needed to run the application), but these are not always available and
when they are, the options they come with are not very customizable (not
to mention that they leave out certain things that are provided when
installing a binary distribution or installing from source).  I guess
that installing from source has the same pitfalls regarding not knowing
what to set the file permissions to as installing binary distributions
(with the added worry of running accross some error that you seem to get
and no one else in the world has seen before). I experienced this
earlier tonight when I tried to compile the mod_webapp module for Apache
1.3 and seeing the famous apxs error.  If anyone has suggestions or tips
or knows where I could go to get a good reference on how best to install
source and binary distributions while maintaining the file permissions
that were intended by the original application developers (without just
blindly setting everything to root - unless if this is exactly the way
you are supposed to do of course), I would really appreciate it.

Happy rest of the holidays everyone and a happy new year.  And once
again, thank you for offering so much support.  I hope I will one day be
able to contribute back to the board as much as you all have to me.

Nick Fankhauser wrote:

> Peter-
>
> A couple of thoughts-
>
> Apparently the database connection is failing. You want to know why,
> so I'd suggest replacing "catch (SQLException e) {}" with "catch
> (SQLException e) {e.printStackTrace();}".
>
> Since you're running Tomcat, the stack trace won't appear on the
> console, but you should be able to find it in the tomcat log files.
> In my case, I'm on Debian Linux, so to look at the tomcat stdout log,
> I use "tail -50 /var/log/tomcat/stdout.log". The location probably
> varies slightly by OS. (Get 50 lines on the tail because the stack
> trace will be long <grin>.)
>
> My first guess as to what you'll find in the trace is that it's an
> authentication problem. You mention that tomcat is running as su
> (root?). Take a look at the pg_hba.conf file for postgresql- It's
> pretty standard for it to be set up as "peer sameuser" by default for
> localhost connections. If this is the case, Tomcat will be running as
> root, but your servlet tries to connect as "peter" & fails the
> sameuser test for authentication, or even if the auth method is
> "trust", root may not be a postgres user. I suppose you could test
> this quickly by creating a root postgres user. (I'm not sure what the
> longer-term security implications of this would be, but I assume we're

> in "make it work" mode right now.)
>
> BTW, tomcat usually runs as www-data by default in most installations
> (same as apache), so In my case, I just make sure there is a www-data
> user in postgresql & grant that user the privs I need it to have on
> each object.
>
> I'm running Tomcat 3.2, so your mileage may vary, but it looks to me
> like you've licked the Tomcat issues & you're back to postgres now.
>
> Hope this helps-
>
> -Nick
>


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster