|When this problem occurs, often the stacktrace will contain:
One example of such a message might be something like:
java.lang.UnsatisfiedLinkError: Native Library C:\weblogic\ecs\bin\ecsVerity.dll already loaded in another classloader
This is a limitation in the JVM. A DLL can only be loaded into a JVM once by a classloader. To work around this, have your DLL loaded by a class that is in the main ServletExec classpath so that it is loaded by the System classloader instead of the web application's custom classloader.
That way you'll be able to reload your web application without running into this problem.
Stopping and restarting the JVM (ServletExec) is another way to workaround this problem.
The same sort of problem can occur from within an Applet, even with ServletExec no where in the picture. This fact is discussed at:
In the event that the information at the above link is removed, here is an excerpt from that link:
"... two things have to happen in order for the native methods to be accessible from Java.
First the DLL has to be loaded ("dynamically linked") into the JVM process,
then the JVM does some magic under the covers to bind the native methods
with the corresponding Java symbols within the class that declares them.
First time the DLL is loaded works fine. If a different class (well, the
same byte codes loaded via a different class loader) tries to access the
same DLL there are no explicit errors but the native methods remain
unresolved and any attempt to invoke the native methods fail (unsatisfied
link error). I guess what has happened is the DLL is already loaded into the
process and so it is assumed to be already bound to the class. But of course
that was a different class that just happened to have the same name so the
symbols in the new class aren't bound to the methods in the DLL. ..."