ICEfaces
  1. ICEfaces
  2. ICE-8035

Normalize use of EL to bind resources in sample applications

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.1, EE-3.0.0.GA
    • Fix Version/s: 3.3
    • Component/s: ICE-Components, Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces Mojarra 2.2

      Description

      In testing compatibility with a recent snapshot of Mojarra 2.2, I discovered some issues with how we access resource in the components and the sample apps. It appears that Mojarra 2.2 may be becoming more strict in how resources are specified. I've discovered two scenarios where the way we specify resources works in the previous 2.1 implementation and now fails in the 2.2 implementation:

      1) Both the RichTextEntryResourceHandler and the InputRichTextResourceHandler use a similar strategy from trying to determine extension mappings (they are both based on the same code). To do this, they currently try to do:

          private static final String INPUTRICHTEXT_CKEDITOR_DIR = "icefaces.ace/richtextentry/ckeditor/";
          private static final String CKEDITOR_JS = "ckeditor.js";

          Resource resource = super.createResource(INPUTRICHTEXT_CKEDITOR_DIR + CKEDITOR_JS);

      However, that particular version of the createResource() API will not resolve "icefaces.ace/richtextentry/ckeditor/ckeditor.js" as a resource which results in a NullPointerException. To get it to work, I changed the string literals around and used the version of the API that includes the library and the content type:

          private static final String INPUTRICHTEXT_CKEDITOR_DIR = "icefaces.ace";
          private static final String CKEDITOR_JS = "/richtextentry/ckeditor/ckeditor.js";
          
          Resource resource = super.createResource(CKEDITOR_JS, INPUTRICHTEXT_CKEDITOR_DIR, "text/javascript");

      2) The use of EL to specify resources in our CSS files seems to have the same issue. For example, in the showcase example we have a file called demo_template.css that contains the following:

          background: url("#{resource['css/images/topBannerImages/showcaseHeaderBlank.png']}") no-repeat;
          
      This gets resolved to:

          http://localhost:8080/showcase/javax.faces.resource/css/images/topBannerImages/showcaseHeaderBlank.png.jsf

      In development mode, this logs:

      25-Apr-2012 4:44:23 PM com.sun.faces.application.resource.ResourceHandlerImpl logMissingResource
      WARNING: JSF1064: Unable to find or serve resource, css/images/topBannerImages/showcaseHeaderBlank.png.

      and results in a 404 not found. Changing the resource EL to (basically adding a ":" after css so that is now considered the library):

          background: url("#{resource['css:images/topBannerImages/showcaseHeaderBlank.png']}") no-repeat;
          
      Ends up resolving to the following, which works:

          http://localhost:8080/showcase/javax.faces.resource/images/topBannerImages/showcaseHeaderBlank.png.jsf?ln=css

      There are numerous resources specified like this in the sample app and while they work in Mojarra 2.1, they fail in Mojarra 2.2.

      The JSF specification (see section 2.6.1.3 Resource Identifiers) outlines what is acceptable as a relocatable resource identifier. I'm not sure whether the "old" way should still be supported or not but it seems that both MyFaces and Mojarra are becoming stricter with regards to what is allowed.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          Linking to parent case

          Show
          Deryk Sinotte added a comment - Linking to parent case
          Hide
          Deryk Sinotte added a comment -

          Since this is a change behaviour from Mojarra 2.1 to 2.2, I've logged a test case indicating it's a regression:

          http://java.net/jira/browse/JAVASERVERFACES-2401

          I'm unsure whether or not it's intended behaviour but better safe than sorry.

          Show
          Deryk Sinotte added a comment - Since this is a change behaviour from Mojarra 2.1 to 2.2, I've logged a test case indicating it's a regression: http://java.net/jira/browse/JAVASERVERFACES-2401 I'm unsure whether or not it's intended behaviour but better safe than sorry.
          Hide
          Deryk Sinotte added a comment -

          The issue has been resolved in recent milestone builds of Mojarra 2.2 so resolving this as fixed.

          Show
          Deryk Sinotte added a comment - The issue has been resolved in recent milestone builds of Mojarra 2.2 so resolving this as fixed.

            People

            • Assignee:
              Deryk Sinotte
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: