2013-04-27 3 views
2

Я знаю, что java.lang.NoSuchMethodError означает, что версия класса, используемого для компиляции, отличается от версии, используемой во время выполнения. Обычно, когда я вижу эту проблему, я запускаю app.server в java -verbose режиме, который сообщает мне файл jar, из которого загружен класс. Если этот файл jar не тот, который я намеревался использовать, я знаю, что использую неправильную версию файла jar.Как устранить проблему java.lang.NoSuchMethodError?

Другим подходом, который я использую, является использование javap, чтобы посмотреть на методы подписи класса в файле jar, который я использую во время выполнения, чтобы подтвердить, что в jar действительно содержится класс с другой сигнатурой метода.

Я вижу эту ошибку сейчас в Karaf, контейнере OSGi, и ни один из вышеперечисленных подходов не помогает. java -verbose показывает мне банку, javap показывает, что подпись метода и сигнатура метода такие же, как в случае ошибки stacktrace. Другими словами, я вижу, что класс из jar, который используется во время выполнения , имеет, имеет такую ​​же подпись метода, что jvm говорит, что он не может найти.

Вот точный трассировки стека, если это помогает:

java.lang.NoSuchMethodError: org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/axiom/soap/SOAPModelBuilder; 
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55) 
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179) 
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145) 
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108) 
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67) 
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354) 
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421) 
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229) 
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165) 
at org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659) 

Существуют ли какие-либо другие подходы, я могу/должен использовать? Спасибо за вашу помощь.

+0

Откуда у вас этот класс? Вы получаете его из Сервиса? Вы используете maven или любую библиотеку управления зависимостями? – Peter

+0

Привет, Джон, в конце концов вы исправили проблему и нашли причину? У меня такая же проблема. –

ответ

1

Karaf команды exports [ids], imports [ids] и classes [ids] может использоваться в комбинации с grep (каждая команда имеет --help вариант).

Из комплекта, сбрасывающего ошибку (с идентификатором N), imports N | grep org.apache.axiom.om расскажет вам, какой пакет он фактически импортирует из этого пакета.

И с другой стороны, exports | grep org.apache.axiom.om будет перечислять пакеты, которые экспортируют этот пакет.

Я ожидаю, что вы увидите более одной строки из экспорта, а команда импорта покажет неправильную версию.

0

Вы также можете использовать класс java -verbose: для просмотра загруженных классов, что может показать, что проблемный класс загружен из другого пакета, который вы ожидали.

+0

Спасибо за ваш ответ. Я уже указал, что я использую этот подход. –

Смежные вопросы