New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The specification is not clear on whether hierarchical library names are supported or not #740
Comments
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
|
Section 2.6.1.3 specifies the rules for valid resource identifiers. The only
constraint placed on the characters that may occur in identifiers is "Every
character in a resource identifier must be a valid character suitable for use in
a string passed to the constructor of java.io.File that takes a single String
argument."
This makes it appear as if hierarchical library names in resources, such as
components/util/login.xhtml
might be valid.
This actually works in Mojarra. You can define a composite component in
resources/components/util/login.xhtml and define a namespace
xmlns:util="http://java.sun.com/jsf/composite/components/util"
But apparently, this generality was not envisioned for 2.0, and a backing
component with the fully qualified class name
components.util.login
will not be associated with the composite component, as is specified by the API
docs for Application#createComponent. "Create a fully qualified Java class name
by removing any file extension from resource-name and let fqcn be library-name +
"." + resource-name".
When fixing this, it would be good also to address other potential issues in
2.6.1.3.
util". Both in Windows and Unix/Linux, '
' is
"a valid character suitable for use in a string passed to the constructor of
java.io.File that takes a single String argument." But the resulting
java.io.File is a very different thing in each case. As a result, a WAR file may
deploy on one OS and not another.
Even worse, "c:util" could mean a drive letter in Windows.
It seems wise to restrict oneself to some subset of characters that is likely to
OS-independent results when passed to java.io.File(String). Perhaps an XML
NameChar (http://www.w3.org/TR/REC-xml/#NT-NameChar) excepting the colon.
Is this version 2.1 of de/login.xhtml or is it the German version of
2_1/login.xhtml? Without specifying that a library name may not be an
underscore-separated sequence of nonnegative integers, either one is a valid
interpretation.
Similarly, consider "de/header.css" in the table on p. 2-24. How is one to know
that this isn't in the library with name "de"?
Potential resolution:
Specify in 2.6.1.3 that
a libraryName or resourceName contains only XML NameChar, but not a colon
a libraryName or resourceName does not match the regex [0-9]([0-9])* or
[A-Za-z] {2}([A-Za-z]{2}
(_[A-Za-z]+)*)?
Environment
Operating System: All
Platform: All
Affected Versions
[2.0]
The text was updated successfully, but these errors were encountered: