Развертывание ресурсов Джерси в контейнере с интерфейсом Servlet 3.0 API с треском проваливается

Question

_{(Я случайно удалил суть, на которую ссылаюсь в этом вопросе; извините за неудобства.)}

Вопрос

Япытаясь использовать Servlet 3.0 API для развертывания корневых ресурсов Джерси (с аннотацией @Path), следуя руководству пользователя Джерси .

Я создал гист на GitHub , содержащий два класса: Foo.java, который является подклассом Application, который выставляет Bar.java (класс ресурсов) через метод getClasses().(Существует также pom.xml, так что любой может легко попробовать это самостоятельно.)

Однако, когда я пытаюсь развернуть упакованную войну на Jetty 8.0.xНапример, я получаю вывод , доступный здесь на pastebin .

Foo.java, вызывается, его метод getClasses() также вызывается, в то время как Bar.java никогда не вызывается.Я могу зайти на страницу приветствия Jetty по номеру http://localhost:8080/, но не могу достичь ни http://localhost:8080/foo, ни http://localhost:8080/foo/bar.Последние два приводят к следующей ошибке:

Не найдено ОШИБКА

пользовательская страница 404

Что можетбыть проблема?Я что-то здесь не так делаю?

Ответ

Учитывая использованную мною WAR (test-0.0.1-SNAPSHOT.war), мой путь к приложению стал http://localhost:8080/test-0.0.1-SNAPSHOT/foo/bar вместо http://localhost:8080/foo/bar.Видишь, что я там сделал?Хорошо.Выгравируйте это у себя на уме или потеряйте 3-5 драгоценных часов своей жизни!

Answer 1

OK.Я решил проблему.

Путь моего приложения не в http://localhost:8080/foo/bar, а в http://localhost:8080/<the name of my war file>foo/bar.Так что, учитывая pom.xml я опубликовал это становится http://localhost:8080/test-0.0.1-SNAPSHOT/foo/bar.

Я ненавижу файлы WAR.

Answer 2

Хотя это не было вашей проблемой, если вы пытаетесь развернуть Jetty 8 в Cargo, вы, скорее всего, получите эту ошибку:

Answer 3

У вас есть один вызов с @ Path , в то время как у другого есть @ ApplicationPath без NO @Path в методе.

Как вы можете здесь ,

API JAX-RS (начиная с версии 1.1.4) представил специальную аннотацию (@ javax.ws.rs.ApplicationPath), которая предоставляет альтернативу конфигурации web.xml:

Но вам понадобится хотя бы @Path для вызываемого метода. Однако, самое простое, вероятно, начать с классического старого файла web.xml, а затем использовать @Path для ресурсов. В сети вы получите множество примеров, в то время как @ApplicationPath встречается редко.