Details
-
Type: Task
-
Status: Closed
-
Priority: 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.
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
- blocks
-
ICE-7768 Verify compatibility with JSF 2.2
- Closed
Linking to parent case