<h:outputStylesheet library="resource:///com/testing/test/html/css/" name="style.xcss" />
не будет работать по одной причине - имя библиотеки не является местоположением ресурса, скорее оно используется для определения местоположения ресурса.
Способ, которым служит среда выполнения JSFРесурсы подробно описаны в спецификации JSF 2.0 в главе 2 под названием «Жизненный цикл обработки запросов».Обработка ресурсов выполняется вне пределов обычного жизненного цикла Execute и Render JSF (который используется для обслуживания запросов View).Во время выполнения ResourceHandler
, связанный с Application
, отвечает за обслуживание запросов ресурсов.
ResourceHandler
использует основанный на пути подход для поиска запросов.Реализация по умолчанию позволяет размещать ресурсы в двух местах:
- В корне веб-приложения.Ресурсы с идентификатором должны быть размещены в каталоге
/resources
в корневом каталоге веб-приложения, как /resources/<resourceIdentifier>
. - в пути к классам.Ресурсы с идентификатором должны присутствовать в Classpath в каталоге
META-INF/resources
, также как META-INF/resources/<resourceIdentifier>
.В веб-приложении я заметил, что каталог должен быть каталогом Web Application Root/WEB-INF/classes/META-INF/resources
или каталогом META-INF/resources
в одном из каталогов родительского загрузчика классов или даже в JAR, присутствующем в Classpath.По-видимому, последний вариант - это вариант, используемый библиотеками / инфраструктурами JSF 2, такими как PrimeFaces.
Спецификация JSF также определяет, как <resourceIdentifier>
может состоять из локалей, версий библиотек и версий ресурсов, кромесамо название ресурса.Это кратко описано в документации ResourceHandler
API :
Упаковочные ресурсы
ResourceHandler определяет соглашение об упаковке на основе пути для ресурсов.Реализация ResourceHandler по умолчанию должна поддерживать упаковку ресурсов в пути к классам или в корне веб-приложения.См. Раздел JSF.2.6.1 спецификационного документа, связанный в кратком обзоре, для нормативной спецификации ресурсов упаковки.
Вкратце, реализация по умолчанию должна поддерживать ресурсы упаковки в корне веб-приложения по пути
resources/<resourceIdentifier>
относительно корня веб-приложения.
Для реализации по умолчанию ресурсы, упакованные в classpath, должны находиться под именем записи JAR
META-INF/resources/<resourceIdentifier>
состоит из нескольких сегментов, определяется следующим образом.
[localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]
Ни один из сегментов в resourceIdentifier не может быть относительным путем, таким как '../otherLibraryName'.Реализация не обязана поддерживать сегменты libraryVersion и resourceVersion для случая упаковки JAR.
Обратите внимание, что resourceName является единственным обязательным сегментом.
Исходя из вышеизложенного, следующее можетработа:
<h:outputStylesheet library="com/testing/test/html/css" name="style.xcss" />
при условии, что таблица стилей style.xcss
присутствует в структуре каталогов com/testing/test/html/css
, расположенной в любой из двух областей, упомянутых выше.Исходя из того, что вам нужно разместить его вне корневого контекста, единственным возможным вариантом будет Web Application Root/WEB-INF/classes/META-INF/resources
или любой другой подходящий каталог / JAR в classpath (содержащий каталог META-INF/resources
. Это, конечно, при условии, что RichFaces делаетне предоставлять собственную реализацию ResourceHandler
; если она действительно есть, вы должны посмотреть, как она расширяет реализацию по умолчанию, позволяя размещать ресурсы в других местах.
В МохарреКласс com.sun.faces.application.resource.ResourceHandlerImpl
расширяет класс ResourceHandler
. ResourceHanderImpl
использует класс com.sun.faces.application.resource.ResourceManager
для поиска ресурсов. В свою очередь, ResourceManager
делегирует загрузку ресурсов классам com.sun.faces.application.resource.WebappResourceHelper
и com.sun.faces.application.resource.ClasspathResourceHelper
. В качестве их именподразумевается, что первый отвечает за поиск ресурсов в корне веб-приложения, тогда как первый отвечает за загрузку ресурсов из пути к классам. Пройдя по этим классам, можно обнаружить, что неудачные попытки загрузки библиотек регистрируются в журнале сервера;RES_NOT_FOUND
значение не генерируется этими классами, скорее это связано срендереру, ответственному за генерацию вывода страницы.