java.lang.SecurityException : 클래스 "XYZ"의 서명자 정보가 같은 패키지의 다른 클래스의 서명자 정보와 일치하지 않습니다.

Question

자바 스크립트에서 호출되는 브라우저에서 실행되는 애플릿이 있습니다. PortalLauncher 및 ParamSplitter이 클래스는 기본 패키지에 있습니다. Javascript는 의 메서드를 호출합니다. PortalLauncher이 차례로 의 함수를 호출합니다. ParamSplitter. 애플릿은 서명 된 jar 파일에 있습니다.

이것은 대부분의 경우 작동합니다. 그러나 일부 사용자에게는 때때로 문제가 있습니다. 하루에 몇 시간에서 (즉,하지에 처음 액세스에) 다음과 같은 예외가 발생합니다 :

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) 

사람은 무엇을이 예외 수단에 어떤 빛을 던져 및 IT의 원인이 무엇을 할 수 있는가? 이 애플릿을 가지고있는 약 800 명의 사용자가 있지만 한 명만 영향을받으며 문제가있는 경우도 있습니다.

Answer 1

즉, 동일한 JVM 내부에는 다른 패키지에서 다른 클래스가로드되어 다른 패키지 (기본 패키지에도 다르게 서명되었거나 서명되지 않은 것)가 있음을 의미합니다.

질문을 올바르게 해석하면 애플릿 자체에 단지가 하나뿐이므로 다른 곳에서 오는 항아리 여야합니다. 일부 사용자 만이 사용할 수 있습니다. 내 첫 번째 생각은 다른 탭 (동일한 jvm 인스턴스를 사용할 수 있음)에서 실행중인 애플릿의 병일 것입니다. 하지만 다른 애플릿은 별도의 클래스 로더를 사용해야하므로 충돌하지 않아야합니다. 루트 패키지에 클래스가있는 jvm의 부트 클래스 경로에 항아리가있을 가능성이 큽니다.

어느 쪽이든 해결책/해결 방법은 단순히 기본 패키지가 아니라 자신의 패키지를 사용하는 것입니다. 그렇게하면 다른 항아리와 충돌하는 것을 피할 수 있습니다.