I am trying to set up Tomcat 5 on Fedora Core 5 and everything iw
working find but i do not know how to set my classpath when using
tomcat below is a few things that i have tried.
I have found i can use the following code to print out the classpath
that my program is actaully using, the code is:
Get the System Classloader
ClassLoader sysClassLoader = ClassLoader.getSystemClassLoader();
//Get the URLs
URL urls = ((URLClassLoader)sysClassLoader).getURLs();
for(int i=0; i< urls.length; i++)
and the classpath that is printed is:
But i am not sure where this is getting set, i do have the following
in my /tomcat5/bin/startup.sh
so why is this not my classpath at run time??
I am able to compile a java mapscript file from the command line using:
javac -classpath ./mapscript.jar MapServerTest.java
But when i try to turn my code into a servelt and run it over Tomcat i keep
java.lang.UnsatisfiedLinkError: no mapscript in java.library.path
I have tried adding: export CLASSPATH=./mapscript.jar
to my ./tomcat5/bin/startup.sh file but that does not seem to help. Am i
missing a setting somewhere, why cant Tomcat find the .jar file? I have it
in the same directory as my .java file and also in /common/lib and
Thank you for any help that you can provide
On Mon, 2006-07-31 at 13:24 -0700, Casey Marshall wrote:
> Most GNU/Linux distributions have packages for a list of root
> certificates, usually as just a bunch of separate PEM files. Does
> Fedora have something like that?
Yes. It looks like openssl ships with certificates. kdelibs does as
well. Perhaps there are others.
> If so, one good way to fix this
> would be to generate a cacerts file (using gkeytool) that contains
> the same list of certificates, and add that to the GCJ RPM. It is
> somewhat preferable for distributions to figure out which root
> certificates they want to use, than for Classpath to arbitrarily
> decide what certificates to include, IMO.
Sounds good. This should probably go in the java-1.4.2-gcj-compat
package (our JDK compatibility layer on top of gcj). We could simply
"BuildRequire" openssl to generate and package the cacerts files.
> Does that make sense? I can explain how to generate such a cacerts
> file from a bunch of separate certificates, if you like.
That would be great. I've never run gkeytool before.
> Additionally, loading cacerts isn't even necessary with Classpath:
> Jessie uses an internal list of root certificates (approximately the
> same list you'll find by default in e.g. Firefox) if no other
> certificates are provided. Nice to see that the RSSOwl people had to
> make this crap so "Easy." A bug (or maybe just some harsh words)
> upstream is also advisable.
gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Rawhide last night
along with java-1.4.2-gcj-compat-plugin which installs an alternatives-managed
"libjavaplugin.so" symlink in /usr/lib/mozilla/plugins.
I closed the long-standing "Inclusion of gcjwebplugin" bug:
and updated the release notes with a "Handling Java Applets" section:
Rawhide users can install gcjwebplugin with "yum install
java-1.4.2-gcj-compat-plugin". Please try this out, file bugs and comment on
the release note additions.
The GNU Classpath AWT and Swing code was in a state of flux when the backport
that included gcjwebplugin was done (because of a large Java2D rewrite to make
the Cairo backend the default), so there are some regressions in AWT and Swing
applications for FC6test2.
My post-test2 plan for gcjwebplugin is to gage the reaction of Rawhide users,
and also to do another GUI backport from GNU Classpath HEAD to Fedora's libgcj,
to fix the AWT and Swing regressions. If the reaction turns out to be overly
negative, even after the new AWT and Swing backport, we can always make
gcjwebplugin not installed by default, for FC6test3. For FC6test2 though, it is
installed by default if the Internet group is selected.
Things are a little ugly in fc6 extras java land...
* Azureus makes my computer practically unusable because of libgcj's new
SecureRandom implementation. I've filed a bug for a work around here:
Mark tells me this is the root cause of some crypto test timeout
problems on the autobuilder as well. Casey says that this same code
doesn't seem to have a problem on jamvm.
* RSSOwl no longer fails to start because of the zip problem (thanks
tromey!), but now crashes in _Jv_ClassReader::checkExtends (super =
0x3). I'm rebuilding libgcj with -O0 -g3 to debug.
* I've updated jogl to jsr231 1.0 beta 5. The good news is that it
builds sans patching! The bad news is that demos crash the X server
(like, try resizing the gears demo). I think this is an X problem, so
I'm going to push this out anyways because the latest WW2D (and "WW2D
plus one", which looks awesome --
http://www.alpix.com/3d/worldwin/WW2d_Java.html) use this version of the
* kawa is fine.