Подтвердить что ты не робот

Отсутствует атрибут кода в методе, который не является родным или абстрактным в файле класса 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

4b9b3361

Ответ 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 как имеющий "отсутствующий атрибут кода" и используя то же, что и цель отладки. Все вернулись к нормальной жизни.