- 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