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.
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. 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.
Gregg Wonderly
