Christopher Schultz-2 wrote: > > So, now you want Tomcat to launch multiple copies of itself as hot > standbys for /potential future webapp deployments/? We'll never do this. >
The exact mechanism is not fixed in stone (I'm sure we could improve on the initial idea). One approach is that administrators should be able to configure webapps in "development" mode, and in only such a case you'd launch a hot standby. Christopher Schultz-2 wrote: > >> * A webapp must invoke System.loadLibrary() to use JNI. > > Must it? You can load a native library at a higher-level instead of in > the webapp itself and avoid all of this. > That's not good enough. Webapps that use JNI will modify DLLs between reloads. Even if you If you load the DLL in some parent ClassLoader you'll still need to unload it every time the webapp is reloaded, otherwise you'll miss changes to the DLL. Christopher Schultz-2 wrote: > >> * If a library is loaded by one ClassLoader and another ClassLoader >> invokes >> System.loadLibrary() the JVM will throw: java.lang.UnsatisfiedLinkError: >> Native Library x already loaded in another classloader. > > I don't believe this has anything to do with ClassLoaders. > Yes it does. Read the evaluation of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4286309 You may only load a library into one ClassLoader at a time. The library is only unloaded from the JVM when the ClassLoader is garbage-collected. Christopher Schultz-2 wrote: > > I don't think the ClassLoader ever unloads the native library. I haven't > found any documentation that suggests that it will. > This was indeed hard to track down. See the evaluation of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4119554 and http://codethesis.com/tutorial.php?id=1 Worse-case scenario we could run independent tests to verify this but either way I think we can both agree the safest and easiest way to ensure proper reloading of native libraries is to restart the JVM. Christopher Schultz-2 wrote: > > Or you can put your .jar that wraps your native library in Tomcat's lib > directory and take it out of your webapp. That's not the most portable > solution, but neither is using a native library in the first place. > That's not an option because as I've mentioned before the native library is potentially the very thing you are redeploying. Christopher Schultz-2 wrote: > > It's not a good excuse, but native libraries are a pain in the ass in > Java. If you use one, be prepared to have your ass hurt. > :) With all due respect, they are only painful to use in web containers. They are extremely simple to use in desktop applications. Christopher Schultz-2 wrote: > > Aah, you are a REST guy. That explains the constant appeals against > practicality. ;) > > If you wrapped your JNI library with a REST interface, couldn't you > avoid all this foolishness? > That's precisely what I'm doing :) I still need to be able to redeploy the native library though. Think of the native library + RESTful interface + Tomcat as an "appliance". I'm making regular updates to the library and I need to restart it quickly to speed up the debugging process. Gili -- View this message in context: http://old.nabble.com/One-process-per-webapp-tp31836121p31847177.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
