Instantiation Error in JAR file
I have a Sybase database using jConnect-5_5.
When I run the main class directly --
java MainClass arguments
-- it works fine.
Then I try creating a JAR file. The manifest file reads:
Main-Class: MainClass
Class-Path: path to jconn2.jar
But when I run it --
java -jar jarfile arguments
-- I get this error:
Error instantiating class java.lang.ClassNotFoundException: com.sybase.jdbc2.jdbc.SybDriver
So what am I doing wrong?
[496 byte] By [
Unca_Albya] at [2007-11-27 5:37:55]
# 1
> Class-Path: path to jconn2.jarIn this line you're supposed to provide the path, relative to the executable jar file itself. Maybe you did that wrong. Or maybe you didn't have a blank line after that in the manifest.
# 2
Ok, I got something working --
What I did was this:
Class-path: /usr/sybase/jConnect-5_5/jconn2.jar
But I have a new question for this --
Why doesn't what I tried before work? Which was:
Class-path: .:./class:/usr/sybase/jConnect-5_5/jconn2.jar
It seems to me that should be more flexible, such as if I have class files in the same directory or a subdirectory.
BUT -- a more important question:
Ok, now I've got it working when jconn2.jar is in a specific directory.
How do I make it flexible enough to run on a different machine where the jar file is someplace else? E.g.:
/export2/home/sybase/12.5.4/jConnect-5_5/jconn2.jar
Or - - -
C:\sybase\lib\jconn2.jar
etc.
# 3
> Why doesn't what I tried before work? Which was:
> Class-path:
> .:./class:/usr/sybase/jConnect-5_5/jconn2.jar
>
> It seems to me that should be more flexible, such as
> if I have class files in the same directory or a subdirectory.
Because that's the wrong format. Inventing your own format isn't going to work, no matter how terrific you think it is.
> How do I make it flexible enough to run on a
> different machine where the jar file is someplace else?
Don't put the jar file in random locations. When you install your jar file, ensure that other jar file is installed in the same directory.
# 4
> > It seems to me that should be more flexible, such as
> > if I have class files in the same directory or a subdirectory.
>
> Because that's the wrong format. Inventing your own
> format isn't going to work, no matter how terrific
> you think it is.
I'm not trying to invent anything -- it says "Class-path", right? So naturally I stick in the value of "CLASSPATH". Or I stick in the value that I'd put on the java "-classpath" command-line parameter, both of which will work perfectly with the same identical format. Why doesn't that make perfect sense? Other than the folks at Sun, for reasons of their own, chose not to do it that way?
>
> How do I make it flexible enough to run on a
> different machine where the jar file is someplace
> else?
>
> Don't put the jar file in random locations. When you
> install your jar file, ensure that other jar file is
> installed in the same directory.
So you're saying it's impossible to create a JAR file with a manifest file that points to a location which can be configured after the fact? E.g., SYBASE_JDBC=/path/to/jconn2.jar
So the only way to be assured that third-party tools are where we can find them is to include those tools with our product?
# 5
> I'm not trying to invent anything -- it says
> "Class-path", right? So naturally I stick in the
> value of "CLASSPATH". Or I stick in the value that
> I'd put on the java "-classpath" command-line
> parameter, both of which will work perfectly with the
> same identical format. Why doesn't that make perfect
> sense? Other than the folks at Sun, for reasons of
> their own, chose not to do it that way?
Sorry, I guess you must have skipped right past the example in the tutorial that showed the classpath entries separated by spaces. Not by colons. I don't know why Sun chose that, but since they did, that's the rule.
> So you're saying it's impossible to create a
> JAR file with a manifest file that points to a
> location which can be configured after the fact?
It's almost impossible to update a JAR file in any way at all after you have created it, short of creating a new JAR file and copying everything from the old one to the new one.
> the only way to be assured that third-party
> tools are where we can find them is to include
> those tools with our product?
That may not be the only way, but it's by far the easiest way. What were you planning to do, have a dialog asking the user to locate their version of those tools? And what if they don't have one? No, it's better just to distribute everything you need and install it all in the same directory. That's the industry-standard process for installing software.
# 6
Dang -- it's a good thing they sell hard drives at under a dollar a gig these days.
# 7
> Dang -- it's a good thing they sell hard drives at> under a dollar a gig these days.No kidding. Now you too can produce bloatware in the privacy of your own home.:)
