Posted By:
Anonymous
Posted On:
Friday, February 21, 2003 09:27 AM
Further exploring problems I faced 14 Feb (see question about classloader), I reach the conclusion that if I run 2 applets, they will run in the same plugin jvm (in case of IE: if the same browser process started it), the 2nd applet is loaded by a new classloader. This new classloader seems to mess up the way the security provider finds its implementations. The public key I pass with the Signature.initVerify() is of type Cryptix, so the cryptix.provider.rsa.SHA1_RSA_PKCS1Signature should load, and it doesn't. (But this could also be caused by the fact it is already loaded, so maybe I am misinterpreting it all) I think I have a new classloader because in the second applet, the System.class.path is different. There are no traces of any of the Cryptix signatu
More>>
Further exploring problems I faced 14 Feb (see question about classloader), I reach the conclusion that if I run 2 applets, they will run in the same plugin jvm (in case of IE: if the same browser process started it), the 2nd applet is loaded by a new classloader. This new classloader seems to mess up the way the security provider finds its implementations. The public key I pass with the Signature.initVerify() is of type Cryptix, so the cryptix.provider.rsa.SHA1_RSA_PKCS1Signature should load, and it doesn't. (But this could also be caused by the fact it is already loaded, so maybe I am misinterpreting it all)
I think I have a new classloader because in the second applet, the System.class.path is different. There are no traces of any of the Cryptix signature impls being executed (that said: for neither of the two applets). I think sun's default implementation is incompatible with my cryptix public key. I am just guessing here...
In any case, having Cryptix as a first or second provider gives stack overflow errors when the applet loads its jars.
<<Less
