1) Your monitoring options depend on what unix(-like) system you are running on. On Linux, there's strace. On Solaris, truss. On HPUX and AIX? I forget. To do this PROGRAMMATICALLY to create a sandbox? Forget it. The Unix Approach is this:
A) create a uid/gid with only the access that you want your code to have. B) Run tomcat under that UID/GID. If you want the shared lib code to have less access than Java code, you need to introduce a process boundary instead of using JNI. 2) Generally, you can get some clues on UnsatisfiedLinkError, in a pinch, by using LD_DEBUG or strace (or truss or whatever). 3) Read the JNDI-howto. I happen to have left behind some useful clues in there. However, the following might also be useful. A) Any .so has to be in java.library.path and in LD_LIBRARY_PATH. Any dependencies of the .so (visible with 'ldd', likewise). B) A native class can only be loaded in One Classloader. Tomcat has a bunch of classloaders. If you run without a security manager, you \can/ load a native class in a webapp class loader, but it will often cause you pain and suffering. If you undeploy and redeploy the webapp, chances are that the old classloader will still be around with the native class in it, unless you were amazingly careful with reference management. Thus, I always put native classes in the 'common' classloader by adding the jars to common.loader in catalina.properties. 4) I have come to believe that the shared objects that you use for JNI should be thin wrappers that make their own calls to dlopen/dlsym to find the guts of your code. This insulates you from the various stupid things that the JVM makers do from time to time in picking the wrong arguments to dlopen. 5) Consider using an RPC protocol to talk to a server written in C/C++ instead of using JNI in the first place. If the performance is acceptable, your life could be a lot simpler. -----Original Message----- From: Andreas Andersson [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 3:32 PM To: Tomcat Users List Subject: using shared objects from tomcat Hi (again)! I still have problems useing a shared library from within a tomcat webapp. The same code works from a standalone appication but not from tomcat. If anyone can answer one or more of the following questions I would be happy. 1) Is there any way to log what a .so-file attempts to do without altering the source? This so that I can see if the .so tries anything funny thats not allowed from within tomcat. 2) Is there any way to get more information from an UnsatisfiedLinkError. Now that error is all I get, no reason or root cause at all. 3) What differs in how tomcat and a standalone java application loads libraries? And what is the restrictions on loading subsekvent libraris (ie the first one loads the ones it depends on). If I could assigne Duke Dollars, Expert Exchange Dollars or some kind of Tomcat Dollars I would. -- Andreas Andersson IT Dept. Travelstart Nordic [EMAIL PROTECTED] http://www.travelstart.se --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
