- From: Robert Futrelle <futrelle@ccs.neu.edu>
- Date: Sun, 6 Aug 2000 12:50:45 -0400 (EDT)
- To: futrelle@ccs.neu.edu (Robert Futrelle)
- Cc: simon@weft.co.uk (Simon Brooke), www-jigsaw@w3.org, futrelle@ncsa.uiuc.edu
The systems people where I'm doing the servlet/jdbc work are constantly revamping the system and things change and/or break at a good clip. (On *average* things do improve.) I spent a lot of time checking PATH and CLASSPATH and shell settings and finally ran java -version and got 1.1.7(!). So I explicitly placed java1.2 in my jigsaw.sh script file and now jdbc is accessible from my servlets. There's still a minor paradox, since when I hack such a .sh script file to only have java -version in it, it reports 1.2. I'm still confused on this point, but at least I have servlet/jdbc interoperatability. Another system strangeness is that overnight, the machine that's serving the Jigsaw pages switched. Such are the wonders of NFS and such. It's a jungle in/out there! Thanks Simon for your efforts -- you probably could never have guessed the solution without being here to muck around until something worked. -- Bob > 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 Sunday, 6 August 2000 12:50:52 UTC