W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 2000

Re: jdbc access works but not from servlets in Jigsaw

From: Robert Futrelle <futrelle@ccs.neu.edu>
Date: Sat, 5 Aug 2000 20:16:43 -0400 (EDT)
Message-Id: <200008060016.e760Ghs13572@alphacentauri.ccs.neu.edu>
To: simon@weft.co.uk (Simon Brooke)
Cc: www-jigsaw@w3.org, futrelle@ncsa.uiuc.edu, futrelle@ccs.neu.edu (Robert Futrelle)
Thanks for your prompt reply.  I've included the cut and pasted
classpath info below. I think you'll agree that they *are* the same
paths, for Jigsaw and for my no-problems standalone code from the
comand line (java and javac aliases).

This is why I am so perplexed.

Here are the aliases I use for compilation.  Servlets and JDBC work
fine, separately.  Thus, in a standalone test from the command line,
no servlet involved, this line works in my code:

  Class.forName("oracle.jdbc.driver.OracleDriver");
  
and full database access follows, without any problems.

But placed in a servlet, the same line throws a ClassNotFound exception.
That's the *same* code cut and pasted.
 
All code was  compiled and run with the following aliases 
(all paths below have been folded for ease in mailing -- 
inspection of the orginals in emacs or in very large windows shows
that they have no spurious newlines or blanks):

sjava='java -cp
/home/rnd/rpf/www/jswdk-1.0.1/lib/servlet.jar:
/home/rnd/rpf/www/Jigsaw/Jigsaw/WWW/servlet/:
/oracle/u01/app/oracle/product/8.1.6/jdbc/lib/classes12.zip:.'

sjavac='javac -classpath
/home/rnd/rpf/www/jswdk-1.0.1/lib/servlet.jar:
/home/rnd/rpf/www/Jigsaw/Jigsaw/WWW/servlet/:
/oracle/u01/app/oracle/product/8.1.6/jdbc/lib/classes12.zip:.'

The scripts/jigsaw.sh has the following classpath setup (among other things):

CLASSPATH=/oracle/u01/app/oracle/product/8.1.6/jdbc/lib/classes12.zip:
${JIGSAW_HOME}/classes/jigsaw.zip:/home/rnd/rpf/www/jswdk-1.0.1/lib/servlet.jar
export CLASSPATH

My aliases are set up to include WWW/servlet/ directory, because the
directories for my packages live under that.

It's clear from jar tf of the .jar and .zip files involved that the
oracle class is nowhere else than in the oracle zip.  So the classpath
ordering can't be a factor, as you say.

As I said, calling the main() of the code that worked standalone, but
calling it from inside the servlet, causes that standalone code to
fail to find the driver class also.  Calling it from the command
line works fine.

Bottom line:  These classpaths really do appear to be the same.  I have grepped
to check the zero vs. upper-case "oh" problem and that's not a problem either.

I realize that people mix Jigsaw and JDBC every day.  Don't know why I can't.

(Jigsaw) puzzled,

 -- Bob


> Robert Futrelle wrote:
> > 
> > If I do a standalone test for JDBC access of an Oracle DB, it works
> > fine.  (Oracle 8.1.6, Oracle JDBC classes12.zip, java 1.2.1,
> > jswdk-1.0.1 on Sun Solaris).  My servlets work fine under Jigsaw
> > 2.0.1.  I include the Oracle JDBC classes12.zip in my java classpath
> > when I start up Jigsaw.  But when I call my JDBC standalone test's
> > main() from inside the servlet, I get an exception for ClassNotFound
> > when it tries to find the Oracle driver, which of course it had no
> > trouble finding when I called the same standalone test from the
> > command line.
> > 
> > The classpath changes were made in the scripts/jigsaw.sh file by
> > adding both additional path components to the path specification,
> > the servlet.jar and the classes12.zip.  I've proofread the paths
> > carefully -- they're the same in the standalone test and servlet
> > tests.
> 
> No, they aren't, otherwise your driver will be found. Trust me on this.
> My solution is to hack the jigsaw.sh script to add the desired archives
> to the classpath.
> 
> > 
> > Is there some other aspect of the installation process that I needed
> > to do to configure Jigsaw properly to allow it to find the appropriate
> > classes?
> 
> No.
> 
> > Is it necessary to recompile Jigsaw with the jdbc classes in the path?
> 
> No.
> 
> > Does the classpath order matter? ....
> 
> Yes, but not much, and in your case it isn't the problem.
> 
> -- 
> Simon Brooke, Technical Director, Weft Technology Ltd --
> http://www.weft.co.uk/
> 
> 	the weft is not just what binds the web: it is what makes it a web
> 
Received on Saturday, 5 August 2000 20:16:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:34 GMT