Re: using shared objects from tomcat
Benson Margulies wrote: -- Tomcat can't 'ignore' LD_ environment variables. They control how ld.so loads the JVM into the process address space and links it. You put env settings in bin/setenv.sh. You will need such a setting for LD_LIBRARY_PATH, at least. Thanks! The LD_DEBUG environment variable told me tomcat was looking for the wrong .so-file. Apperently it's looking for the file including the package structure Java_com_mycompany_myClass_myLib instead of myLib. The test applications has no package (except the default package) and tomcat on windows seams to ignore them. So, I'm off to relink the .so with a packagestructure (thats my next problem :). Thanks for the help! -- 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]
RE: using shared objects from tomcat
Andreas, You need to apply the javap command to your third-party code. Perhaps first, you need to read the Sun JNI book. There are two levels of naming. First, when some Java code calls System.loadLibrary(foo), the JVM will look for libfoo.so in java.library.path. Then, unless the library manually registers native function, the JVM will dlsym for functions based on the fully-packaged-name of the classes containing the native functions. The test application's package doesn't matter. The classes with native methods matter. -Original Message- From: Andreas Andersson [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 3:49 AM To: Tomcat Users List Subject: Re: using shared objects from tomcat Benson Margulies wrote: -- Tomcat can't 'ignore' LD_ environment variables. They control how ld.so loads the JVM into the process address space and links it. You put env settings in bin/setenv.sh. You will need such a setting for LD_LIBRARY_PATH, at least. Thanks! The LD_DEBUG environment variable told me tomcat was looking for the wrong .so-file. Apperently it's looking for the file including the package structure Java_com_mycompany_myClass_myLib instead of myLib. The test applications has no package (except the default package) and tomcat on windows seams to ignore them. So, I'm off to relink the .so with a packagestructure (thats my next problem :). Thanks for the help! -- 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]
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]
RE: using shared objects from tomcat
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]
Re: using shared objects from tomcat
Benson Margulies wrote:
First of all, thanks for the answer, I've been fighting this one for
quite som time now.
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:
This is a debian suggesting strace to be the one for me. Can I attach
strace to my .so-file or do I have to start tomcat via strace?
2) Generally, you can get some clues on UnsatisfiedLinkError, in a
pinch, by using LD_DEBUG or strace (or truss or whatever).
If I'm not misstaken tomcat ignores environment variables so how can I
set LD_DEBUG?
A) Any .so has to be in java.library.path and in LD_LIBRARY_PATH. Any
dependencies of the .so (visible with 'ldd', likewise).
java.library.path _AND_ LD_LIBRARY_PATH? Thats intersting and might very
well be the solution to my problem. As I just wrote I think tomcat
ignores these evironment variabels. I was under the impression that
LD_LIBRARY_PATH was the same as java.library.path, if that is not the
case then how do I set LD_LIBRARY_PATH?
Thus, I always put native classes in the 'common' classloader by adding
the jars to common.loader in catalina.properties.
Is it also OK to add .so-files? I have
grant codeBase file:${catalina.home}/common/- {
permission java.security.AllPermission;
};
in my catalina.properties. Would that suggest that if I only placed all
.so-files under /common they would be loaded or at least accessable?
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.
Unfortunatly the codes in the .so-files isn't mine. It's a third party
product that we can't alter or even have altered for us.
--
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]
RE: using shared objects from tomcat
This is a debian suggesting strace to be the one for me. Can I attach
strace to my .so-file or do I have to start tomcat via strace?
-- .so.s don't have independent existence. You run strace on a process.
I recommend using the -p option to attach it to the JVM after the JVM is
up but before you try to touch your code.
2) Generally, you can get some clues on UnsatisfiedLinkError, in a
pinch, by using LD_DEBUG or strace (or truss or whatever).
If I'm not misstaken tomcat ignores environment variables so how can I
set LD_DEBUG?
-- Tomcat can't 'ignore' LD_ environment variables. They control how
ld.so loads the JVM into the process address space and links it. You put
env settings in bin/setenv.sh. You will need such a setting for
LD_LIBRARY_PATH, at least.
A) Any .so has to be in java.library.path and in LD_LIBRARY_PATH. Any
dependencies of the .so (visible with 'ldd', likewise).
java.library.path _AND_ LD_LIBRARY_PATH? Thats intersting and might very
well be the solution to my problem. As I just wrote I think tomcat
ignores these evironment variabels. I was under the impression that
LD_LIBRARY_PATH was the same as java.library.path, if that is not the
case then how do I set LD_LIBRARY_PATH?
-- you set the environment variable in bin/setenv.sh or the equivalent.
You also set java.library.path there, generally.
Thus, I always put native classes in the 'common' classloader by
adding the jars to common.loader in catalina.properties.
Is it also OK to add .so-files? I have
grant codeBase file:${catalina.home}/common/- {
permission java.security.AllPermission; };
in my catalina.properties. Would that suggest that if I only placed all
.so-files under /common they would be loaded or at least accessable?
-- you can never 'add a .so' to a classpath. You add the Java class with
the 'native' methods, and when it calls System.loadLibrary, the fun
begins. The jar containing the native-method classes is the important
one.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: using shared objects from tomcat
On Tue, Feb 08, 2005 at 10:53:37PM +0100, Andreas Andersson wrote: This is a debian suggesting strace to be the one for me. Can I attach strace to my .so-file or do I have to start tomcat via strace? I'm not certain about debian, but under NetBSD you can turn on tracing for an already running process. (ktrace -p pid) I'd imagine there'd be something similar under linux. Check the strace man page. Keep in mind that this can create a _lot_ of output. 2) Generally, you can get some clues on UnsatisfiedLinkError, in a pinch, by using LD_DEBUG or strace (or truss or whatever). If I'm not misstaken tomcat ignores environment variables so how can I set LD_DEBUG? The LD_DEBUG env variable would actually be interpreted by the dynamic linker code, so it's irrelevant whether tomcat ignores it or not. Tomcat will rely on the JVM's library loading functions, which in turn should use dlopen() and related functions. 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. Unfortunatly the codes in the .so-files isn't mine. It's a third party product that we can't alter or even have altered for us. That really depends on how much the library depends on java. If it's a C/C++ library that had a thin JNI layer added on afterwards you can probably write a C/C++ program to use it fairly easily. A good indicator of this is if the .so comes with C/C++ header files, and if the java interface is light on it's use of objects. (e.g. all function arguments and return values are primitives, or data-only objects) Of course, if the library wasn't written that way you might not have an easy to use C function to call. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
