Resource localization is too rigid and forces undesirable duplication

[eclipse-faces-bot]

Consider this situation, which is not uncommon.

• I need a JavaScript library for all locales
• I need images that vary by locale
  Resource handling, as described in section 2.6, makes it impossible to vary the
  images by locale without also unnecessary duplicating the JavaScript.

In order to have images vary by locale, it is necessary to add keys
javax.faces.resource.localePrefix into the the application's message bundle for
each locale. Once that has been done, the prefix is used for ALL resource lookups.

1. It forces unnecessary duplication of resources. (I now have to put the SAME
   JavaScript libraries under the locale prefix for each locale)
2. The spec is not clear what happens when a resource is obtained from a
   component library. If the locale prefix is also prepended in that case, it is
   possible (even likely) that the library will break.

Suggested fix: Abolish the javax.faces.resource.localePrefix approach. Instead,
get the actual application locale, and look for resources at
language_country_variant, language_country, language, and no prefix, just like a
ResourceBundle does.

Environment

Operating System: All
Platform: All

Affected Versions

[2.0]

[eclipse-faces-bot]

@glassfishrobot Commented
Reported by cayhorstmann

[eclipse-faces-bot]

@glassfishrobot Commented
Parent-Task: JAVASERVERFACES_SPEC_PUBLIC-947

[eclipse-faces-bot]

@glassfishrobot Commented
@rlubke said:
Assigned to the spec team.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
I'm afraid we have to fix this in the maintenance release.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
For audio describing this issue, see
<http://weblogs.java.net/blog/edburns/archive/2009/07/brief_interview.html>.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
move to 2.1

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Prepare to delete "spec" subcomponent.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
cat2

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
frame

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
These are targeted at 2.1.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
triage

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
GlassFish 3.1 M6 at the latest.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Move these to M5

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Move these to 2.2

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
This is closely related to https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1858

[eclipse-faces-bot]

@glassfishrobot Commented
kito75 said:
Even though this doesn't have that many votes, it's absolutely essential that we fix this, especially if we push more features on top of the resource handling (like http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809).

[eclipse-faces-bot]

@glassfishrobot Commented
lamine_ba said:
Totally agree, the key words of our strategy should be " make it cohesive " and " keep it simple".

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Sending build.xml
Sending jsf-api/src/main/java/javax/faces/application/Resource.java
Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ClientResourceInfo.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/LibraryInfo.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceInfo.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/WebappResourceHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Sending jsf-ri/systest-per-webapp/resource-locale-prefix/src/java/com/sun/faces/systest/ResourceLocalePrefixTestCase.java
Adding (bin) jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/duke-non-localized-non-lib.gif
Adding jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/lib
Adding (bin) jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/lib/duke-non-localized.gif
Sending jsf-ri/systest-per-webapp/resource-locale-prefix/web/test.jsp
Transmitting file data ...............
Committed revision 9778.

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-548 http://java.net/jira/browse/JAVASERVERFACES-2348

• The central feature of this changebundle enables an additional check
  when rendering a resource, and serving up the bytes of the resource.
  The additional check is to look for a non-localized version of the
  resource in the case when the user has provided a localePrefix, but
  there is no localized version of the resource. This solves the case
  that Cay Horstmann is talking about in the bug report.

Consider this situation, which is not uncommon.

I need a JavaScript library for all locales

I need images that vary by locale
Resource handling, as described in section 2.6, makes it impossible to vary the
images by locale without also unnecessary duplicating the JavaScript.

This feature is referred to as "additional check" for discussion in
this changebundle.

SECTION: Modified Files

M requestProcessingLifecycle.fm

• Fix 2.6.1.4 so that it correctly handles the additional check.

M jsf-api/src/main/java/javax/faces/application/ResourceHandler.java

• for all variants of createResource() that reference section
  JSF.2.6.1.4, mention that there are new requirements in that section
  that fix the problem described in Resource localization is too rigid and forces undesirable duplication #548.

• libraryExists(), new requirements. "If there is a localePrefix for
  this application, as defined in LOCALE_PREFIX, first look for the
  library with the prefix. If no such library is found, look for the
  library without the prefix. This allows developers to avoid
  duplication of files. For example, consider the case where the
  developer wants to have a resource library containing a localized
  image resource and a non-localized script resource. By checking both
  locations for the existence of the library, along with other spec
  changes in section 2.6.1.4, this scenario is enabled."

M jsf-api/src/main/java/javax/faces/application/Resource.java

• changes to getRequestPath().

JSF 2.0 should have specified the "loc" query parameter, but it did
not. Fix that.

M jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java

• Implement javax.faces.WebAppResourcesDirectory, but need to add tests.

M jsf-ri/src/main/java/com/sun/faces/application/resource/ClientResourceInfo.java

• Add copy ctor, and copy method. These are necessary to support the
  additional check.

• Move equals() and hashcode() up to superclass.

M jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceInfo.java

• Move ivars to top of class definition.

• Add copy ctor, and copy method. These are necessary to support the
  additional check.

• Take on equals and hashCode().

M jsf-ri/src/main/java/com/sun/faces/application/resource/FaceletResourceHelper.jav

• implement equals() and hashCode()

M jsf-ri/src/main/java/com/sun/faces/application/resource/LibraryInfo.java

• Add copy ctor, to support the additional check.

• add getPath(String localePrefix) to support the additional check.

M jsf-ri/src/main/java/com/sun/faces/application/resource/WebappResourceHelper.java

• implement WebAppResourcesDirectory configurability.

• Add equals() and hashCode().

• use getPath(localePrefix)

M jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHelper.java

• In method getInputStream() move the heart of the method into a new
  method, getInputStreamFromClientInfo(). Call this method first, it
  will cause the resource to be looked for given the localePrefix, if
  one exists for this app. If it is not found, use the new copy methods
  on ClientResourceInfo to create a resourceInfo with its localePrefix
  artifically removed. Pass this to getInputStreamFromClientInfo(). If
  the resource is found, use the copy() method to modify the resource
  and effectively remove its localePrefix. Otherwise, return null.

Because this method is called from both WebappResourceHelper and
ClasspathResourceHelper, both cases are covered.

M jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java

• add equals() and hashCode().

M jsf-ri/systest-per-webapp/resource-locale-prefix/src/java/com/sun/faces/systest/ResourceLocalePrefixTestCase.java
M jsf-ri/systest-per-webapp/resource-locale-prefix/web/test.jsp
A jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/duke-non-localized-non-lib.gif
A jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/lib
A jsf-ri/systest-per-webapp/resource-locale-prefix/web/resources/lib/duke-non-localized.gif

• New test content.

[eclipse-faces-bot]

@glassfishrobot Commented
Marked as fixed on Thursday, March 22nd 2012, 1:25:12 pm

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
Closing resolved issue out

[eclipse-faces-bot]

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

[eclipse-faces-bot]

• Issue Imported From: Resource localization is too rigid and forces undesirable duplication javaee/javaserverfaces-spec#548
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @edburns
• Original Issue Closed By:@glassfishrobot