[JAVASERVERFACES_SPEC_PUBLIC-886] Allow hierarchical resource library names Created: 17/Sep/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 886
Status Whiteboard:

size_medium importance_medium


 Description   

The spec is a bit unclear about this, but it appears that hierarchical resource
library names are not supported. It is desirable to support them for two reasons.

1) It allows developers greater flexibility in structuring their resources and
composite components
2) It allows for longer package names with backing components for composite
components.

(NB. Mojarra will load hierarchical names such as components/util.)

Two changes are required.

1) In section 2.6.1.3, add a bullet that a libraryName is a /-separated sequence
of libraryDirname. If
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=884 is
adopted, specify that each libraryDirname must not match the regexes for
versions or locales.

2) In
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#createComponent(javax.faces.context.FacesContext,%20javax.faces.application.Resource),
change

let fqcn be library-name + "." + resource-name

to

let fqcn be library-name.replace("/", ".") + "." + resource-name



 Comments   
Comment by cayhorstmann [ 17/Sep/10 ]

Changed to Enhancement

Comment by cayhorstmann [ 17/Sep/10 ]

That's
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885, not
884 in part 1).

Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Tue May 26 01:31:30 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.