Skip to content
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

Closed
eclipse-faces-bot opened this issue Feb 4, 2010 · 11 comments

Comments

@eclipse-faces-bot
Copy link

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.

  1. Consider the library name "my
    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.

  1. Consider the resource name "de/2_1/login.xhtml"

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]

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Reported by cayhorstmann

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Was assigned to javaserverfowner

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
cat1

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
frame

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
These are valid 2.0 Rev a issues

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
Fix checked in

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
rogerk said:
changelog

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Marked as fixed on Tuesday, June 22nd 2010, 1:56:04 am

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@manfredriem said:
Closing resolved issue out

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-740

@eclipse-faces-bot
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants