使用JSF2包括上下文根外部的资源 [英] Including resources outside context root with JSF2

问题描述

我目前正在将应用程序从JSF 1.2和Richfaces 3.3升级到JSF 2和Richfaces 4.

I'm currently upgrading an application from JSF 1.2 and Richfaces 3.3 to JSF 2 and Richfaces 4.

使用JSF2的新这是我的旧代码:

<a4j:loadStyle src="resource:///com/testing/test/html/css/style.xcss" />

这是我的新代码的内容(不起作用):

And here is what I have for my new code (Not working):

<h:outputStylesheet library="resource:///com/testing/test/html/css/" name="style.xcss" />

我尝试了各种变体，但没有一个奏效. 使用Firebug的css标签时，我收到一条消息RES_NOT_FOUND.

I've tried various variations but none have worked. I get a message saying RES_NOT_FOUND when using firebugs css tab.

有什么想法吗?

谢谢

推荐答案

<h:outputStylesheet library="resource:///com/testing/test/html/css/" name="style.xcss" />

由于某种原因而无法工作-库名称不是资源的位置，而是用于确定资源的位置.

will not work for one reason - the library name is not the location of the resource, rather it is used to determine the location of the resource.

JSF 2.0规范的第2章标题为请求处理生命周期"中详细介绍了JSF运行时提供资源的方式.资源处理是在通常的JSF Execute和Render生命周期(用于服务View请求)的范围之外执行的.在运行时，与Application关联的ResourceHandler负责服务资源请求.

The manner in which the JSF runtime serves resources is detailed in the JSF 2.0 specification in chapter 2 titled "Request Processing Lifecyle". Resource handling is performed outside the confines of the usual Execute and Render lifecyle of JSF (that is used to service View requests). At runtime, a ResourceHandler associated with the Application is responsible for serving Resource requests.

ResourceHandler使用基于路径的方法来查找请求.默认实现允许将资源放置在两个位置:

The ResourceHandler uses a path based approach for looking up requests. The default implementation allows for resources to be placed in two locations:

• 在Web应用程序根目录中.具有标识符的资源必须放置在Web应用程序根目录下的/resources目录中，作为/resources/<resourceIdentifier>.
• 在类路径中.具有标识符的资源必须出现在META-INF/resources目录下的类路径中，再次作为META-INF/resources/<resourceIdentifier>.在Web应用程序中，我注意到该目录应该是父类类加载器中某个目录下的Web Application Root/WEB-INF/classes/META-INF/resources目录或META-INF/resources目录，甚至应位于类路径中的JAR中.显然，最后一个选择是由诸如PrimeFaces之类的JSF 2库/框架承担的.

• In the Web-Application Root. Resources with identifier have to be placed in the /resources directory under the Web Application root, as /resources/<resourceIdentifier>.
• In the Classpath. Resources with identifier must be present in the Classpath under the META-INF/resources directory, again as META-INF/resources/<resourceIdentifier>. In a web application, I've noticed that the directory should be the Web Application Root/WEB-INF/classes/META-INF/resources directory or a META-INF/resources directory under one of the directories in the parent classloader(s), or even in a JAR present in the Classpath. Apparently, the last option is the one undertaken by JSF 2 libraries/frameworks like PrimeFaces.

除了资源名称本身之外，JSF规范还指定了<resourceIdentifier>如何由语言环境，库版本和资源版本组成.在 API文档:

The JSF specification also specifies how the <resourceIdentifier> may consist of locales, library versions and resource versions, apart from the resource name itself. This is dealt with in a concise manner, in the ResourceHandler API documentation:

包装资源

ResourceHandler为以下内容定义基于路径的打包约定 资源. ResourceHandler的默认实现必须支持 在类路径或Web应用程序根目录中打包资源. 请参阅规范散文文档中链接的JSF.2.6.1部分， 包装规范的概述 资源.

ResourceHandler defines a path based packaging convention for resources. The default implementation of ResourceHandler must support packaging resources in the classpath or in the web application root. See section JSF.2.6.1 of the spec prose document linked in the overview summary for the normative specification of packaging resources.

简而言之，默认实现必须支持打包资源 在Web应用程序根目录下的路径下

Briefly, The default implementation must support packaging resources in the web application root under the path

resources/<resourceIdentifier>

相对于网络应用根目录.

relative to the web app root.

对于默认实现，资源打包在类路径中 必须位于JAR条目名称下

For the default implementation, resources packaged in the classpath must reside under the JAR entry name

META-INF/resources/<resourceIdentifier>

由几个段组成，指定为

consists of several segments, specified as follows.

[localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]

resourceIdentifier中的任何段都不能是相对路径， 例如"../otherLibraryName".不需要执行 支持JAR的libraryVersion和resourceVersion段 包装盒.

None of the segments in the resourceIdentifier may be relative paths, such as ‘../otherLibraryName’. The implementation is not required to support the libraryVersion and resourceVersion segments for the JAR packaging case.

请注意，resourceName是唯一必需的段.

Note that resourceName is the only required segment.

按照以上所述，以下方法可能会起作用:

Going by the above, the following may work:

<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(包含META-INF/resources目录.当然，这是假定RichFaces确实这样做的)不提供它自己的ResourceHandler实现；如果确实提供了ResourceHandler，则应查看它如何扩展默认实现以允许将资源放置在其他位置.

provided that the stylesheet style.xcss is present in the directory structure com/testing/test/html/css located in either of the two areas mentioned above. Going by your need to place it outside the context root, the only possible option would be Web Application Root/WEB-INF/classes/META-INF/resources or any of the other suitable directory/JAR in the classpath (containing a META-INF/resources directory. This is of course, assuming that RichFaces does not provide it's own implementation of a ResourceHandler; if it does provide one, you should be looking at how it extends the default implementation to allow for resources to be placed elsewhere.

在Mojarra中，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类.顾名思义，前者负责在Web应用程序根目录中查找资源，而前者负责从类路径中加载资源.通过这些类，人们会发现加载库的失败尝试被记录在服务器的日志中. RES_NOT_FOUND值不是由这些类生成的，而是由于渲染器负责生成页面输出.

In Mojarra, the com.sun.faces.application.resource.ResourceHandlerImpl class extends the ResourceHandler class. ResourceHanderImpl uses the com.sun.faces.application.resource.ResourceManager class for finding resources. In turn, the ResourceManager delegates the loading of resources to the com.sun.faces.application.resource.WebappResourceHelper and com.sun.faces.application.resource.ClasspathResourceHelper classes. As their names imply, the former is responsible for looking up resources in the Web Application root, while the former is responsible for loading resources from the classpath. Going through these classes, one would find that failed attempts to load libraries get logged in the server's log; the RES_NOT_FOUND value is not generated by these classes, rather it is due to the renderer responsible for generating the page output.

这篇关于使用JSF2包括上下文根外部的资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！