Как настроить встроенный причал для использования военного файла в исполняемой банке в качестве ресурса

Question

У меня есть исполняемый jar-файл с военным файлом. Запуск jar извлекает файл войны и создает из него WebAppContext, используя webAppContext.setWar(warFile). Хотя это работает, похоже, что webAppContext.setWarResource(warResource) должно работать. Я пробовал создать ресурс, используя new PathResource("file.war"), который показывает путь типа "jar: file: / Users /.../ jetty-1.0.0-jar-with-dependencies.jar! /File.war «. Звучит многообещающе и условно, но когда я пробую его, я получаю "java .lang.IllegalArgumentException: not file: scheme" . Мне действительно нужно извлекать военный файл или есть уловка?

Answer 1

Это будет ссылка на вложенный jar-файл, и никакая программа Java не может этого сделать.

Вариант 1: используйте вместо этого живую войну (также известную как исполняемая война).

Это будет военный файл, который можно развернуть традиционно, если вы хотите, но также можно использовать автономно из командной строки java (и при необходимости запустит свой собственный сервер).

Пример проекта поддерживается проектом Eclipse Jetty по адресу ... https://github.com/jetty-project/embedded-jetty-live-war

Примечание: концепция живой войны была вдохновлена ​​работой, проделанной проектом Jenkins и их live-war.

Вариант 2: полностью удалите уровень файла WAR в JAR

Не упаковывайте содержимое WAR в JAR как filename.war , рассмотрите возможность использования его в качестве развернутой WAR (или военной директории).

Просто распакуйте WAR в ваш JAR-файл где-нибудь в безопасном месте (например, /META-INF/webapps/<app-id>/), а затем укажите вместо этого ссылку на этот каталог в вашем JAR-файле.

Вариант 3: устранение необходимости в WAR c Oncepts полностью

Это самый популярный выбор номер один.

Вы деконструируете файл WAR в ServletContextHandler с настроенными Servlets и Filters, это также устраняет необходимость в таких вещах, как сканирование аннотаций / сканирование байт-кода (что довольно сложно), вам также не придется препираться с вложенным / изолированным загрузчиком классов (ваш uber-файл JAR содержит все классы и нижестоящие зависимости, необходимые для запуска вашего веб-приложения), и такой подход определенно ускорит время запуска.