Отсутствует атрибут кода в методе, который не является родным или абстрактным в файле класса javax/servlet/ServletException
Я планирую использовать Java-сервлеты в своем приложении. Я включил следующее в проект POM.xml файл для загрузки Java-сервлета 3.0. Jar.
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.servlet</artifactId>
<version>3.2-b05</version>
</dependency>
Проект компилируется отлично. Однако, когда я запускаю его, я получаю следующую ошибку:
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/servlet/ServletException
Я искал его здесь и нашел хорошие ответы.
Я понял из них, что эта ошибка возникает, когда мы включаем JAR, который содержит только интерфейсы, определенные API сервлета, а не фактическую реализацию. Итак, я проверил, что ящик стеклянной рыбы, который я использую, является просто интерфейсом или он также содержит реализацию. Я обнаружил, что это реализация, а не только интерфейсы.
Итак, теперь мне интересно, почему я получаю эту ошибку во время выполнения. Кто-нибудь?
UPDATE:
Как раз сейчас, я узнал, что это была явная ошибка с моей стороны (я добавлял банку в один проект, в то время как был запущен совсем другой проект!). Прошу прощения за это. Добавление реализации сервлета из морской рыбы. Решает проблему.
Спасибо,
Sandeep
Ответы
Ответ 1
Я боролся последние 2 часа или около того с проблемой, связанной с зависимостями javaee-api и javaee-web-api, используемыми для плагина surefire. Поскольку ребята на форуме JBoss любезно опубликованные некоторое время назад, он выглядит так, как вся библиотека JEE6 была разделена (согласно решению Sun/Oracle) на API (только интерфейсы/заглушки) JAR и провайдеры.
Как это относится к этому? Если у вас есть проблема, скажем FacesContext class, вы получите сообщение об ошибке:
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/faces/context/FacesContext
Если вы посмотрите на дерево зависимостей, вы найдете API-интерфейс API по умолчанию в пути к классу компиляции, который также мешает работе во время выполнения:
javax.faces:javax.faces-api:jar:2.1:provided
Добавление явного исключения для конфигурации плагина surefire обеспечит использование использования зависимостей JAR-провайдера провайдера во время тестирования:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<classpathDependencyExcludes>
<!-- exclude code absent api -->
<classpathDependencyExclude>javax.faces:javax.faces-api</classpathDependencyExclude>
</classpathDependencyExcludes>
</configuration>
</plugin>
Надеюсь, что это поможет, это сработало для меня.
Ответ 2
Я обменялся на стеклянную вставку и решил это.
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2.2</version>
<scope>provided</scope>
</dependency>
Ответ 3
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2.2</version>
<scope>provided</scope>
Это сработало для меня. Благодарю.
Но порядок в pom.xml также имеет значение для меня
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2.2</version>
<scope>test</scope>
</dependency>
Выше заказа не работает
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Работа над заказом
Ответ 4
Я столкнулся с такой же ошибкой, используя Джерси, когда я запускал свои тесты (JUnit + Mockito). Что для меня работает, это добавить код ниже в файл pom.xml.
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-test-framework</artifactId>
<version>1.1.5.1</version>
<scope>test</scope>
</dependency>
Примечание: я использую Jersey 1.17
Ответ 5
Недавно я столкнулся с этой же ошибкой и, благодаря этому вопросу и приведенным выше ответам - особенно leandro.freitos - я смог разрешить его с помощью
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2.2</version>
<scope>provided</scope>
</dependency>
Оказывается, мой имел отношение к javax.servlet
Ответ 6
У меня был похожий случай с тем, что у одного дзёдда (такая же ошибка, также во время работы JUnit с Mockito), но без Джерси. Итак, здесь было создано независимое от Джерси решение:
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-servlet_3.0_spec</artifactId>
<version>1.0</version>
<scope>test</scope>
</dependency>
Ответ 7
Такая же проблема. Хотя оказалось, что я был приказ, в котором я декларировал зависимости. Взаимозависимость от встроенной стеклянной рыбы должна быть объявлена перед установленной зависимостью javaee-web-api.
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Я не уверен, почему путь класса запутался, когда встроенная стеклянная рыба разместилась после тестов javaee-web-api. Я предполагаю, что JVM пытается разрешить классы javax в предоставленном первом, а затем отказывается во время тестирования. Я бы понял, что объявление области для теста будет иметь приоритет, но, похоже, это не так в моей ситуации. Надеюсь, это поможет кому-то.
Ответ 8
получилась та же самая проблема компиляции с netbeans 7.2.1.
Однако вывод указал один из моих собственных исходных файлов java как имеющий "отсутствующий атрибут кода....... и т.д."
В то же время я могу скомпилировать и запустить тот же проект с помощью JDeveloper. После нескольких "чисток" и перезагрузки netbeans все еще бросает ту же проблему.
Я, наконец, исправил это, добавив основной метод в сообщение java как имеющий "отсутствующий атрибут кода" и используя то же, что и цель отладки. Все вернулись к нормальной жизни.