tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Disable class monitoring for reloading container classes
Date Thu, 07 Oct 2010 20:34:19 GMT
Jane Muse wrote:
..
 > The reason why there's a problem when the application gets reloaded is due to we are

loading a JNI native library that the application requires. According to the following 
link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more 
than one class loader. When the application is shut down by tomcat, the native library 
does not get unloaded from the class loader. This only happens when the JVM is brought 
down. Thus when the application starts up after tomcat reloads it, we get an 
UnsatisfiedLinkError.
 >
Ok, I can really not comment on that one.  It seems a valid reason to me, but I am by no 
means a specialist here.


> There are several Java's on the IBM machine. Yesterday I performed tests by changing
JAVA_HOME in the catalina startup script to Sun's Java 1.5 and Sun's java 1.6. Previously
it was IBM's J9 1.5.0. The results were the same with the various JVM's.
> 
Are you sure that wherever you changed it, is really being used ?
If you go to the "bin" directory of your Tomcat installation, and execute the 
"./version.sh" script, what does it tell you ?

The reason I am asking, is that when Tomcat comes "pre-packaged" for some given OS, the 
packagers may have provided their own startup scripts, which may not use the standard 
Tomcat startup scripts, or which may overwrite the "JAVA_HOME" environment value before 
actually launching Tomcat.

We on this list generally do not know the exact contents of these packages, so you really

have to make sure, by following the chain of what happens when you start Tomcat on that 
machine.
If you know where the line is which actually launches Tomcat, you could insert an 
instruction just before, such as
echo "Java Home : $JAVA_HOME"
just to make sure.

And there is always the workaround mentioned by Pid..

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message