javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-740

The specification is not clear on whether hierarchical library names are supported or not

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0 Rev a
    • Component/s: Resources
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      740
    • Status Whiteboard:
      Hide

      cat1 frame changelog

      Show
      cat1 frame changelog

      Description

      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.

      2) 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]+)*)?

        Activity

        Hide
        Ed Burns added a comment -

        cat1

        Show
        Ed Burns added a comment - cat1
        Hide
        Ed Burns added a comment -

        frame

        Show
        Ed Burns added a comment - frame
        Hide
        Ed Burns added a comment -

        These are valid 2.0 Rev a issues

        Show
        Ed Burns added a comment - These are valid 2.0 Rev a issues
        Hide
        Ed Burns added a comment -

        Fix checked in

        Show
        Ed Burns added a comment - Fix checked in
        Hide
        rogerk added a comment -

        changelog

        Show
        rogerk added a comment - changelog
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            javaserverfowner
            Reporter:
            cayhorstmann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: