Давайте проанализируем нижнюю часть стека трассировки:
Caused by: com.cerner.system.exception.ExceptionAdapter
at com.cerner.system.util.lang.ClassAssistant.lookupClass(ClassAssistant.java:50)
Я думаю, здесь все ясно: строка 50 из com.cerner.system.util.lang.ClassAssistant
вызывает com.cerner.system.exception.ExceptionAdapter
.
at com.cerner.system.util.lang.ClassAssistant.lookupClass(ClassAssistant.java:66)
at com.cerner.system.instrument.logging.edc.EdcAssistant.getResourceBundle(EdcAssistant.java:113)
at com.cerner.system.instrument.logging.edc.EdcLogger.<init>(EdcLogger.java:26)
at com.cerner.system.instrument.logging.edc.EdcLoggerManager.getLogger(EdcLoggerManager.java:50)
Кажется, что фактическая конструкция com.cerner.system.instrument.logging.edc.EdcLoggerManager
пытается найти какой-то класс, чтобы получил логгер .
at com.cerner.edc.ccm.host.drivers.framework.Util.<clinit>(Util.java:65)
Здесь вы видите <clinit>
вместо имени метода, это означает, что это статическая часть класса. Это означает, что класс Util
не может быть корректно загружен JVM, поскольку ExceptionAdapter
повышается, когда EdcLoggerManger
равен , получая регистратор (строка 65 класса Util).
Затем при последующих попытках создания экземпляра класса Util
JVM скажет, что этот класс не найден, т. Е. Ваш ClassNotFound
.
Как это исправить?
У меня не так много информации о вашем фактическом коде. Но вы должны проверить, почему эта строка com.cerner.system.util.lang.ClassAssistant.lookupClass(ClassAssistant.java:66)
на самом деле выдает com.cerner.system.exception.ExceptionAdapter
.
Или, в конце концов, вы можете издеваться над EdcLoggerManager.getLogger (...).
В качестве напоминания, если этот код не является устаревшим, я настоятельно рекомендую вам избегать PowerMock, поскольку он не защитит вас от плохого дизайна (плохо проверяемый код, эволюция порра, плохая ремонтопригодность). Вместо этого используйте истинный дизайн ООП с хорошей практикой и схемами, где это уместно.