eclipse-ee4j / mojarra

Mojarra, a Jakarta Faces implementation
Other
160 stars 109 forks source link

findResource in ResourceManager fails #3111

Closed ren-zhijun-oracle closed 10 years ago

ren-zhijun-oracle commented 10 years ago

I'm developing composite and regular components and use the new JSF 2.2 feature which allows to register both in one taglib XML file. I use in my taglib XML the new syntax to register composite components below META-INF/resources. E.g.

<tag>
    <tag-name>calendar</tag-name>
    <component>
        <resource-id>
            com/mycompany/calendar.xhtml
        </resource-id>
    </component>
</tag>

The method

findResource(String resourceID)

in the

ResourceManager.java

is responsible for resource loading by resource ID. But the logic is not correct there. If you have com/mycompany/calendar.xhtml as resource ID (my path to resource under the META-INF/resources folder), the resourceName is extracted as calendar.xhtml (OK), but the libraryName is extracted as mycompany (NOT OK). The libraryName is cut off. It should be com/mycompany. As result, the composite component can not be found ==> Exception.

Environment

JSF 2.2.4

Affected Versions

[2.2.4]

ren-zhijun-oracle commented 6 years ago
ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented Reported by ova2

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented ova2 said: Someone already commented here https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1001 that this mechanism doesn't work with nested folders, but the issue seems to be ignored.

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented @manfredriem said: Can you roll this up in a reproducing example and send it to issues@javaserverfaces.java.net? That would help us a lot. Thanks!

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented ova2 said: Yes, sure Manfred. I will try. The logic in findResource(...) is simple, so that you don't really need an example An JUnit test would be good.

By the way, I think the resourceName in my example should be "mycompany/calendar.xhtml" and the libraryName is "com". This is e.g. how h:graphicImage would resolve it.

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented ova2 said: Hi Manfred,

I sent you (issues@javaserverfaces.java.net) a demo app. Simple deploy it on an JEE7 server and call http://localhost:8080/JAVASERVERFACES-3107-1.0 You will see

javax.faces.view.facelets.FaceletException: com/mycompany/message.xhtml @0,0 <> Cannot create composite component tag handler for composite-source element in taglib.xml file

The exception is raised by com.sun.faces.facelets.tag.AbstractTagLibrary in this case.

I have a composite component webapp/resources/com/mycompany/message.xhtml If you move message.xhtml to webapp/resources/com/message.xhtml and ajust the resource ID in the demo.taglib.xml as com/message.xhtml, you will see a page with "Hello World". Everything is fine. But as long as folders with composite components are nested, nothing works.

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented @manfredriem said: Thank you for the excellent reproducer, this saved me a lot of time to determine what is happening, unfortunately what you are trying to do is a specification violation. In this particular case your resource-id is invalid.

From the JSF specification you can read

2.6.1.3 Resource Identifiers

consists of several segments, specified as follows. [localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion] The run-time must enforce the following rules to consider a valid. A that does not follow these rules must not be considered valid and must be ignored silently. The set of characters that are valid for use in the localePrefix, libraryName, libraryVersion, resourceName and resourceVersion segments of the resource identifier is specififed as XML NameChar excluding the path separator and ':' characters. The specification for XML NameChar may be seen at [http://www.w3.org/TR/REC-xml/#NT-NameChar](http://www.w3.org/TR/REC-xml/#NT-NameChar). A further restriction applies to libraryName. A libraryName must not be an underscore separated sequence of non-negative integers or a locale string. More rigorously, a libraryName must not match either of the following regular expressions: [0-9](_[0-9])* [A-Za-z] {2}(_[A-Za-z]{2} (_[A-Za-z]+)*)? Segments in square brackets [] are optional. The segments must appear in the order shown above. If libraryVersion is present, it must be preceded by libraryName. If libraryVersion is present, any leaf files under libraryName must be ignored. If resourceVersion is present, it must be preceded by resourceName. There must be a '/' between adjacent segments in a If libraryVersion or resourceVersion are present, both must be a '_' separated list of integers, neither starting nor ending with '_' If resourceVersion is present, it must be a version number in the same format as libraryVersion. An optional "file extension" may be used with the resourceVersion. If "file extension" is used, a "." character, followed by a "file extension" must be appended to the version number. See the following table for an example. Since the resource-id is invalid I am closing this issue as "Works as designed".
ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented ova2 said: Hi Manfred. I read the spec. of course, but I thought we can specify nested folders for resources anyway. As I see now, libraryName can not contain path separators. That means com/mycompany/calendar.xhtml is interpreted as libraryName/libraryVersion/resourceName. Right? Or is "mycompany" interpreted as libraryName? Can you clarify please if nested folders are allowed?

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented @manfredriem said: If some code allows you to do that it goes beyond the specification and should be treated as an implementation detail.

ren-zhijun-oracle commented 7 years ago

@javaserverfaces Commented This issue was imported from java.net JIRA JAVASERVERFACES-3107

ren-zhijun-oracle commented 10 years ago

@javaserverfaces Commented Marked as works as designed on Friday, December 13th 2013, 7:36:56 am