On May 13, 2010, at 531PM, Gregg Wonderly wrote: > Dennis Reedy wrote: >> On May 13, 2010, at 1123AM, Gregg Wonderly wrote: >>> If you use System.load(), then you can use a static initialization >>> block to copy the jni bits from the jar into a temp directory and then load >>> it from that path. Associated permissions need to be granted of > >>course. >>> >> Sure, you can copy the native lib to a temp directory, and assuming you > > have set the JVM up to load native libs from that directory that would > > work, but you still need to address the class loader issue right? > > There are no requirements for "setting up the JVM" except for permissions > needed when you use System.load() as opposed to the less flexible > System.loadLibrary(). So, any code with appropriate permissions granted can > use System.load() to load a dynamic library which will bind with JNI class > definition.
FWIW, in my experience dealing with native libraries it gets very very tricky if you want different class loaders to use the same loaded native library. So *any* code is generally subjective based on the class loader, is not just the permissions. > >> I think that you'd rather want to have the native libraries required for > > authentication part of your 'platform'. > > As the service provider, you want the authentication to happen correctly. I > don't want to lead on that a client would be using a JNI JAAS authentication > implementation locally. But, I wanted to point out that System.load() works > fine. I have my JAAS authentication in a utilities jar. What classloader loads your utlities.jar? > My authentication class loads the .so from the file system, using > System.load() to load it, with no properties set in the JVM to indicate where > libraries are at. It would work just fine to use ClassLoader.getResource() > to find the library (even using the os.name or some such property to pick the > appropriate one), copy it out the the filesystem and load it from a > different, more random path.
