jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [jsr-344-experts] Clarification about JAVASERVERFACES_SPEC_PUBLIC-1141 Specify that all parts of a resource identifier must not have "/".

From: Frank Caputo <frank_at_frankcaputo.de>
Date: Mon, 5 Nov 2012 16:08:32 +0100

Hi Leonardo,

+1 for the whole text.

It seems that we have some trouble with resource handling and we should not break existing behavior. Maybe we should use the next 3 weeks to clarify how resource handling should work (and how it is actually used, e.g. is anybody using versioning?).

Ciao Frank


Am 03.11.2012 um 18:54 schrieb Leonardo Uribe <lu4242_at_gmail.com>:

> Hi
>
> Recently I saw this change in the spec:
>
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1141
>
> It claims that:
>
> "... resourceHandler.createResource("css/images/background.png")
>
> This is not valid and should never have been valid. ...."
>
> I have some concerns about this one. Some time ago, I realize that reading
> the spec in a strict way, libraryName should not contain slash caracters, but
> the spec doesn't forbid slashes in resourceName.
>
> JSF 2.0 spec section 2.6.1.3 Resource Identifiers says this about libraryName :
>
> "... The run-time must enforce the following rules to consider a
> <resourceIdentifier>s
> valid. A <resourceIdentifier> 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, 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."
> - 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]+)*)?
>
> ..."
>
> so any libraryName that contain slashes like in the example
> (components/mycomp) is considered invalid.
>
> In that time, this issue was created:
>
> https://issues.apache.org/jira/browse/MYFACES-3454
> https://issues.apache.org/jira/browse/MYFACES-3529
>
> In MyFaces dev list and stackoverflow site we received some feedback
> about this one:
>
> http://markmail.org/message/mant42lx5rs465hl?q=h:outputStylesheet+order:date-backward&page=6
>
> http://stackoverflow.com/questions/10094568/jsf-2-0-myfaces-have-problems-rendering-composite-components
>
> In few words, the problem is people already relies on the fact that
> resourceName allow
> slashes and take advantage of that. So, if resourceName is restricted
> to do not allow slashes,
> it will break code that works on JSF 2.0/2.1 .
>
> My question is simple: which is the benefit of this change? Isn't this
> make things harder?
> After all, it is very useful to have a tree structure to organize
> files inside a library, right?
> I know originally, allow slashes was not intended, but I think in this
> case we have to take a
> look at how users really use JSF 2.0 stuff. For example, see this link:
>
> http://www.mkyong.com/jsf2/resources-library-in-jsf-2-0/
>
> Obviously, the problem resides on the fact that a resource can be
> located using two different syntax.
> For example, if a resource is located in
> META-INF/resources/default/css/mystyles.css, you can retrieve it
> using:
>
> <h:outputStylesheet library="default" name="css/mystyles.css"/>
>
> or
>
> <h:outputStylesheet name="default/css/mystyles.css"/>
>
> Both generated request paths are different but the served resource is the same.
>
> regards,
>
> Leonardo Uribe
>