java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
Я разрабатываю сервлет, который получает многочастный запрос с содержимым нескольких файлов, и я использую библиотеки загрузки файлов Apache Commons.
Когда я звоню parseRequest(request);
Метод сервлет выдает следующее исключение:
GRAVE: Servlet.service() for servlet DiffOntology threw exception
java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest
at org.apache.commons.fileupload.servlet.ServletRequestContext.getContentType(ServletRequestContext.java:73)
at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:882)
at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349)
at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at DiffOntology.doPost(DiffOntology.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Я поместил все библиотеки в WEB-INF/lib.
РЕДАКТИРОВАТЬ:
servlet-api.jar находится в правильном каталоге (tomcat/lib), а все остальные библиотеки находятся в WEB-INF / lib
Я думаю, возможно, проблема может быть в следующем: я разрабатываю этот веб-проект в Eclipse, и я импортировал библиотеки загрузки файлов в classpath.
Как это не работает?
Я в отчаянии!
7 ответов
Это может произойти, если вы разместили серверные библиотеки в веб-приложении. /WEB-INF/lib
или, возможно, JRE/lib
, Большой шанс, что вы скопировали Tomcat /lib/servlet-api.jar
в там. Ты не должен этого делать. Это приведет только к конфликтам в пути к классам, что приведет к такого рода ошибкам, и это сделает ваше веб-приложение непереносимым (т. Е. Оно связано только с Tomcat, его нельзя запускать на других серверах, таких как Glassfish, JBoss AS, Websphere)., так далее). Вы должны хранить серверные библиотеки в их расположении по умолчанию. Очистить /WEB-INF/lib
из любых серверных библиотек и очистки JRE/lib
из любых сторонних библиотек.
Вы, вероятно, скопировали туда серверные библиотеки, потому что не смогли скомпилировать свои сервлеты. Копирование библиотек в /WEB-INF/lib
это неправильное решение. Вы должны просто указать эти библиотеки в classpath времени компиляции. Поскольку вы используете Eclipse, это можно сделать легко: сначала добавьте Tomcat в представлении Servers, затем свяжите ваш проект веб-приложения с интегрированным экземпляром Tomcat. Таким образом, Eclipse автоматически добавит серверные библиотеки в путь сборки проекта. В новом веб-проекте вы можете выбрать сервер во время создания проекта. В существующих веб-проектах вы можете изменить его в разделе " Целевые среды выполнения " в свойствах проекта.
Смотрите также:
Вы должны неправильно скопировать файл commons-fileupload.jar в JRE/lib/ext
, JRE/lib/endorsed
или иным образом поместил его в путь к классам, который не имеет видимости для API сервлетов. Запустите JVM с -verbose:class
, который выведет какой путь к классу загрузил ServletFileUpload
учебный класс. Если класс загружен из любого места, кроме WEB-INF/lib
вам нужно будет удалить его.
Старый поток, но все еще может помочь кому-то. Я увидел, что у меня есть javax-сервлет в зависимости, включенной в область тестирования. Я сделал это в предусмотренном объеме. Проверьте граф зависимостей, если вы используете Eclipse +Maven.
Я получил эту ошибку, когда по ошибке использовал образ Docker Tomcat 10 для моей сборки файла WAR для Tomcat 9. Я использовал образ Docker без определенного тега, который поставлялся с последней версией Tomcat (в моем случае 10) (tomcat:jdk17-temurin
).
Использование Tomcat 10 потребует корректировок, как указано в документе Tomcat 10 :
Между Tomcat 9.0.x и Tomcat 10.0.x есть существенные критические изменения. Пакет Java, используемый спецификационными API, был изменен с javax... на jakarta.... Необходимо будет перекомпилировать веб-приложения для новых API.
В моем случае я просто разрешил эту ошибку, указав образ с определенной версией Tomcat (например,
tomcat:9.0.56-jdk17-temurin
).
Удалите все сервлеты-api.jar или общие файлы jar для загрузки из JRE/lib или JRE/lib/ext. Это помогло мне решить проблему.
У меня такая же проблема. Причина, по которой у меня возникла эта проблема, заключается в том, что, поскольку я использую jakarta-servlet-api, я предположил, что нужный мне класс находится в пакете jakarta. Однако, когда я извлек API, я увидел, что пакет называется javax, поэтому вместо этого я импортировал javax.servlet.http.HttpServlet, и он работал нормально.
В Gentoo Linux, используя Tomcat 9, в целях разработки приложений Java EE в Eclipse я получаю это сообщение об ошибке при попытке запустить сервер из окна «Серверы» в перспективе Eclipse Java EE. Я пытался вручную добавить/usr/share/tomcat-servlet-api-4.0/lib/servlet-api.jar
к пути к классам моего проекта не сработало. Я попытался вручную добавить этот файл в переменную CLASSPATH на/usr/share/tomcat-9/package.env
, не сработало.
После многих безуспешных попыток исправить это моя интуиция подсказывала мне, что, возможно, дистрибутив Portage предназначен для работы как автономный демон, управляемый из оболочки, а не из Eclipse, и что, возможно, для целей разработки мне пришлось установить простой экземпляр vanilla Кот. Поэтому я вручную загрузил Tomcat 9 с официальной веб-страницы и вручную извлек его; я использовал/opt/apache/tomcat/tomcat9
, но теоретически подойдет любой каталог. Я сделал это, и Tomcat, наконец, успешно запустился.
Вкратце: если вы разрабатываете приложения Java EE на Gentoo, не используйте дистрибутив Portage, вместо этого загрузите и установите его вручную с официального веб-сайта.