java.lang.SecurityException: classe “XYZ”, signataire de l'information ne correspond pas signataire de l'information des autres classes du même package
J'ai une applet qui s'exécute dans un navigateur et est appelé à partir de Javascript. Il y a 2 classes: PortalLauncher et ParamSplitter et ceux-ci sont dans le package par défaut. Javascript appelle une méthode dans PortalLauncher qui à son tour appelle une fonction dans ParamSplitter. L'applet est signée jar.
Cela fonctionne la plupart du temps. Cependant, peu d'utilisateurs ont des problèmes de temps à autre. À un certain moment dans la journée (c'est à dire pas au premier accès), l'exception suivante est générée:
java.lang.SecurityException: class "ParamSplitter"'s signer information does not
match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at PortalLauncher.openFile(PortalLauncher.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.Exception: java.lang.SecurityException: class "ParamSplitter"'s signer
information does not match signer information of other classes in the same package
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Quelqu'un peut jeter toute la lumière sur ce qu'est cette exception signifie et ce qui pourrait être la cause? Il y a environ 800 utilisateurs qui ont cette applet, mais seulement une poignée sont affectés, et même ceux qui ont le problème que occaisionally.
OriginalL'auteur paul | 2009-08-27
Vous devez vous connecter pour publier un commentaire.
Cela signifie qu'à l'intérieur de la même JVM, il y a d'autres classes chargées à partir d'autres pots qui ont été signés différemment (ou non signé peut-être), également dans le package par défaut.
Si j'interprète votre question correctement votre applet elle-même n'a qu'un seul pot, donc ça doit être un pot de venir d'ailleurs; et que seuls certains utilisateurs ont.
Ma première pensée c'est peut-être le pot d'une application s'exécutant dans un autre onglet (qui peuvent être à l'aide de la même jvm exemple). Mais d'autres applets doivent être en utilisant un chargeur de classe, de sorte qu'ils ne devraient pas entrer en collision comme ça.
Plus probablement, ils ont un pot dans le démarrage classpath de leur jvm qui a également une classe dans le package racine.
Soit, la solution est tout simplement de ne pas utiliser le package par défaut, mais votre propre paquet. De cette façon, vous éviter la collision avec l'autre pot.
OriginalL'auteur Wouter Coekaerts