Вот структура Maven моего проектаЗагрузка файла свойств внутри JAR-файла с JSF
app > common-module > webapp-module > batch-module pom.xml
common-module
выставляет Version
класс. Этот класс используется как webapp, так и пакетными модулями.
Класс Version
имеет один уникальный статический метод, называемый get
. Он возвращает глобальную версию проекта.
Глобальная версия хранится в файле свойств. Когда get
вызывается из пакетного модуля (автономного приложения Java), файл свойств успешно загружается.
В webapp все по-другому. Я создал управляемый компонент VersionBean
, который позволил бы любой странице JSF вызвать метод get
. Всякий раз, когда я пользуюсь одним из следующих
FacesContext.getCurrentInstance().getExternalContext()
FacesContext.getCurrentInstance().getExternalContext().getContext()
Thread.currentThread().getClassLoader()
Я никогда не могу найти файл properties.file.
Как загрузить файл свойств (getResourceAsStream), расположенный в файле jar из управляемого компонента?
EDIT
Вот решение, которое я придумал на основе рекомендаций от @BalusC и @eljunior
VersionBean.java
@ManagedBean(eager=true)
@ApplicationScoped
public class VersionBean {
private String version;
@PostConstruct
public void init(){
version = Version.get();
}
}
Version.java
public class Version {
public static String get() {
InputStream is = Version.class.getResourceAsStream("/version.properties");
// Read InputStream and return version string ...
}
}
Спасибо за ваши объяснения. Я не знал, что методы будут работать так по-разному. Абсолютное расположение файла свойств выглядит следующим образом: '/WEB-INF/lib/batch-module.jar!/Version.properties' – Stephan
' Thread.currentThread(). GetContextClassLoader(). GetResourceAsStream ("version.properties") 'должен тогда делать. – BalusC
Я в замешательстве. Это * * решение # 2. Ответ Eljunior (в основном решение №3, как и в моем ответе) предполагает, что он находится в том же пакете, что и класс, который, похоже, не имеет значения, учитывая ваше абсолютное местоположение в JAR (учитывая, что классы без упаковки являются плохой практикой) , Отказ от ответственности: Maven находится вне меня, поэтому я не могу сказать из головы, как именно он строит JAR и WAR. – BalusC