Внешний контекст JSF getRealPath возвращает null в приложении на основе jsf omnifaces joinfaces
Я пытаюсь загрузить локальный файл, расположенный в каталоге src/main/resources/META-INF/resources/resources/. Приложение представляет собой приложение на основе joinfaces, которое включает в себя myfaces, omnifaces и rewrite. Перед переносом моего проекта (классической JSF WAR) на joinfaces я делал это, предоставляя реальный путь к файлу следующим образом:
FacesContext.getCurrentInstance().getExternalContext().getRealPath("/resources");
Поскольку в моем проекте используются омнифейсы, getExternalContext() возвращает org.omnifaces.context.OmniExternalContext, а все выражение возвращает null.
Если я просто бегу:
FacesContext.getCurrentInstance().getExternalContext().getRealPath("/")
он возвращает путь к пустому временному каталогу, созданному встроенным tomcat (например, C:\Users\User\AppData\Local\Temp\tomcat-docbase.4856998207101083356.8443\).
В этом случае мне действительно не нужен абсолютный путь к статическому ресурсу, содержащемуся внутри моего приложения, это был всего лишь один способ сделать это, но все же я не могу найти способа для этого, а документация по объединениям минимальна. Любые идеи?
В проекте нет ничего плохого. В joinfaces 4.x META-INF/resources/ является корневым веб-каталогом (я знаю, что это странно), и мой веб-корневой каталог также получил каталог с именем resources, что нормально для веб-приложений Java. Очевидно, что src/main/resources/ не будет существовать в скомпилированном JAR, я упомянул об этом только для объяснения структуры проекта. Поменял тег на пружинную загрузку.
Это скомпилированная структура jar-файла ontalsoft.com.mx/downloads/jar_struct.png.
Упоминание об этом только вызвало путаницу, и вы можете использовать обычную структуру папок war с joinfaces: github.com/joinfaces/joinfaces/issues/315 и, пожалуйста, прочтите stackoverflow.com/questions/12160639/…
Да, я видел это обсуждение с участием стыковок. Проблема в том, что я не использую военную упаковку. Кроме того, все примеры исходного кода в их репозиториях на github имеют старые версии, поэтому вы также не можете получить какую-либо полезную информацию о путях / альтернативах структуры проекта оттуда. А что касается последнего, я знаю, что это плохая практика. Обсуждение stackoverflow, о котором вы упомянули, не помогает, потому что оно применимо только к стандартным веб-проектам, что идеально работает в моем случае (как я упоминал в своем первом посте).
Использование абсолютных путей для каждого слова - неплохая практика, но использование getRealPath - плохая практика, поскольку он не переносится (разные версии tomcat могут вести себя по-разному даже), поэтому для меня усилия по дальнейшей помощи здесь заканчиваются (без использования spring, joinfaces и т. д. ) Удачи
Спасибо, в любом случае. Думаю, я просто перейду к альтернативным решениям. Это было больше связано с интересом к причине проблемы и поиском способа обнаружения физического пути динамического ресурса в проектах joinfaces 4.
Вы не должны пытаться загрузить локальный файл в
src/main/resources/META-INF/resources/resources/, поскольку это путь в вашем источнике в среде IDE. Вам также не следует полагаться на метод getRealPath. И папка «ресурсы» внутри «ресурсов» внутри META-INF внутри папки ресурсов звучит так, как будто что-то уже не так. Пожалуйста, улучшите основы. А joinfaces - это «весенняя загрузка», связанная со встроенным tomcat. Так что лучше удалить тег java и добавить туда spring -boot.