Я перекомпилировал свои классы, как обычно, и неожиданно получил следующее сообщение об ошибке. Зачем? Как я могу это исправить?
java.lang.SecurityException: class "Chinese_English_Dictionary" signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
Это происходит, когда классы, относящиеся к одному и тому же пакету, загружаются из разных JAR файлов, и эти файлы JAR имеют подписи с разными сертификатами - или, возможно, чаще, по крайней мере один из них подписан, а один или несколько других - нет (что включает классы, загруженные из каталогов, поскольку AFAIK не может быть подписан).
Итак, убедитесь, что все JAR (или, по крайней мере, те, которые содержат классы из тех же пакетов) подписываются с использованием того же сертификата или удаляют подписи из манифеста JAR файлов с перекрывающимися пакетами.
Простой способ обойти это просто попробуйте изменить порядок импортированных файлов jar, которые можно сделать из (Eclipse). Щелкните правой кнопкой мыши на своем пакете → Путь сборки → Настроить путь сборки → Ссылки и библиотеки → Заказ и экспорт. Попробуйте изменить порядок банок, содержащих файлы подписи.
а. Если вы используете maven, полезный способ отлаживать конфликтующие банки:
mvn dependency:tree
Например, для исключения:
java.lang.SecurityException: class "javax.servlet.HttpConstraintElement" signer information does not match signer information of other classes in the same package
делаем:
mvn dependency:tree|grep servlet
Его вывод:
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- javax.servlet:jstl:jar:1.2:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile
[INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile
показывает сбой servlet-api 2.5 и javax.servlet 3.0.0.x.
В. Другие полезные советы (как отладить исключение безопасности и как исключить maven deps) находятся в вопросе Информация о подписчиках не соответствует.
В моем случае у меня была дублированная версия JAR BouncyCastle в моем пути к библиотеке: S
У меня было подобное исключение:
java.lang.SecurityException: class "org.hamcrest.Matchers" signer information does not match signer information of other classes in the same package
Коренная проблема заключалась в том, что я дважды включил библиотеку Hamcrest. После использования файла Maven pom. И я также добавил библиотеку JUnit 4 (которая также содержит библиотеку Hamcrest) к пути построения проекта. Мне просто пришлось удалить JUnit из пути сборки, и все было в порядке.
Это может произойти с прокси-серверами cglib-instrumented, потому что CGLIB использует свою собственную информацию подписчика вместо информации подписчика целевого класса приложения.
Имя: net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.c девушка SHA-256-дайджест: q3B5wW + hLX/+ lP2 + L0/6wRVXRHq1mISBo1dkixT6Vxc =
Если вы запускаете его в Eclipse, проверьте банки любых проектов, добавленных в путь сборки; или выполните control-shift-T и сканируйте несколько банок, соответствующих одному и тому же пространству имен. Затем удалите избыточные или устаревшие банки из пути сборки проекта.
В моем случае это был конфликт имен пакетов. В текущем проекте и подписанной библиотеке ссылок есть один общий пакет package.foo.utils. Просто изменил текущее имя пакета, подверженного ошибкам проекта, на что-то еще.
Немного слишком старая нить, но поскольку я некоторое время застрял на этом, вот исправление (надеюсь, что это кому-то помогает)
Мой сценарий:
Имя пакета: com.abc.def. Есть 2 файла jar, которые содержат классы из этого пакета, говорят jar1 и jar2, то есть некоторые классы присутствуют в jar1 и другие в jar2. Эти файлы jar подписываются с использованием одного и того же хранилища ключей, но в разное время сборки (т.е. Отдельно). Это, похоже, приводит к различной сигнатуре для файлов в jar1 и jar2.
Я поместил все файлы в jar1 и создал (и подписал) их все вместе. Проблема уходит.
PS: имена пакетов и имена файлов jar являются примерами
Это также происходит, если вы дважды включаете один файл с разными именами или из разных мест, особенно если это две разные версии одного и того же файла.
Я мог бы это исправить.
Корневая причина: Это обычная проблема при использовании Sun JAXB с подписанными банками. По сути, реализация JAXB пытается избежать отражения, создавая класс для прямого доступа к свойствам без использования рефлексии. К сожалению, он генерирует этот новый класс в том же пакете, что и к классу, к которому осуществляется доступ, откуда приходит эта ошибка.
Разрешение: Добавьте следующее системное свойство, чтобы отключить оптимизацию JAXB, которые не совместимы с подписанными банками: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = истина
Основываясь на ответе @Mohit Phougat, если вы используете Groovy с аннотациями @Grab, вы можете попытаться переопределить такие аннотации.
Если вы добавили все файлы jar из bouncycastle.org (в моем случае из crypto-159.zip), просто удалите те файлы JDK, которые к вам не относятся. Есть увольнения. Вам, вероятно, нужны только банки jdk15on.
Этот вопрос длился долго, но я хочу кое-что обсудить. Я работал над проектом Spring и обнаружил это в Eclipse IDE. Если вы используете Maven или Gradle для Spring Boot Rest API, вы должны удалить Junit 4 или 5 в пути сборки и включить Junit в ваш файл сборки pom.xml или Gradle. Я думаю, это относится и к файлу конфигурации yml.
это случилось со мной при использовании JUnit + быть уверенным + hamcrest, в этом случае не добавляйте junit для построения пути, если у вас есть проект maven, это решило меня, ниже pom.xml
<dependencies>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
</dependency>
<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
</dependencies>