Dennis Reedy wrote:
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 had not spoken about this issue as I was trying to recall the details. I have
not had problems with ServiceStarter based services launched in the same JVM
using my class for authentication of each service. I need to run some test to
make sure that I am recalling, correctly, what I have experienced.
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?
The PreferredClassLoader that is created by the ServiceDescriptor.create() call
is loading the service classes. I need to check to make sure I am not
misremembering how many services are using this facilitiy per JVM.
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.
