Prasad Rajagopal wrote:
>I followed your suggestion of "applet-context" vs "java-extension" by moving
>both the jar file and its JNI-lib to same directory (user's home
>/Library/Java/Extensions). Then tried to invoke the applet. But gave me same
>error.
Please post a stack-trace from the Java Console if possible.
There are a lot of details here I can only guess at, and those details are
important. At this point, I suggest creating a small test-case that has
the proper security context for each sub-component, and tracking down the
problem that way. Once you know what the problem is, you can apply what
you know to the more complex PKCS11-wrapper's case.
Right now, you're trying to debug complex code in a non-trivial security
environment, with no idea what's necessary for it all to work. And I'm in
even a worse position, advising about debug strategies using just emailed
descriptions of what goes wrong.
>Wondering if this comment makes any difference
>
> /* We do not call loadLibrary in a static initializer to allow better use in
> * applets. Static initialization blocks have a differrent security context.
> */
> System.loadLibrary(PKCS11_WRAPPER);
>
>where PKCS11_WRAPPER = "pkcs11wrapper" and "libpkcs11wrapper.jnilib" is
>in users' home /Library/Java/Extensions (created this new folder, wasn't
>there before) showing me the same error. Hope this helps to figure out
>what's the problem.
First, the comment is incorrect.
A class's static initializer has exactly the same security context as
anything else in the class. The designer's decision to defer the
loadLibrary() calls makes no difference at all to the security context. If
the class is loaded from an unsigned applet's class-loader, the call will
still fail, regardless of whether it's called from a static initializer or
from within a static method that your applet code explicitly invoked.
Second, you should double-check that both local files (jni-lib and jar) in
your extensions dir have the necessary permission. Enter 'ls -la
~/Library/Java/Extensions' in Terminal and paste what it says into a list
posting.
Third, you should confirm that none of the wrapper classes are in your
applet jar, and none of your applet classes are in your extensions jar.
Use 'jar tvf your.jar'.
Fourth, you might want to add some diagnostic code to your applet that gets
each class's ClassLoader, and then describes it on System.out (prints its
type, its URLs, etc). If the PKCS11-wrapper's class-loader is an applet
class-loader, then it's definitely in the wrong security context. If it's
an extension class-loader, then it should work, and something else might be
wrong.
In general, you need to zero in on the exact context where the failure
occurs, and then find out the details of that context. Context includes
the class-loaders, their URLs, the permissions and ownership of local
files, etc. All these details matter a lot.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
