Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.1, EE-2.0.0.GA
-
Fix Version/s: 2.0.2, EE-2.0.0.GA_P01
-
Component/s: ACE-Components
-
Labels:None
-
Environment:-
-
Affects:Compatibility/Configuration
Description
* http://localhost:8080/Sample/javax.faces.resource/yui/3_1_1/oop/oop-min.js.xhtml
* http://localhost:8080/Sample/javax.faces.resource/yui/3_1_1/pluginhost/pluginhost-min.js.xhtml
* http://localhost:8080/Sample/javax.faces.resource/yui/2in3/yui2-tabview/yui2-tabview-min.js.xhtml
The "Sample" portion of the URI is added by a Response wrapper which is not the context path and is removed by a filter so that the normal url-mappings are applied. Other resources are correctly prefixed with the context path:
* http://localhost:8080/CONTEXTPATH/Sample/javax.faces.resource/oop/oop-min.js.xhtml?ln=yui/3_1_1
He sees that oop-min.js is added twice: once with the incorrect path and once with the correct one.
The customer is using the ACE tabset and dateTimeEntry components and as a result these errors, both are not working. The following is also shown in the Firebug console:
Y.Plugin is undefined (line 115 of animation.js)
Y.on is not a function (line 33 of tabset.js)
The problem does not occur when he removes the code that adds the prefix in the response wrapper:
<script id="yui_3_1_1_1_13045343789972" type="text/javascript" charset="utf-8" src="/CONTEXTPATH/javax.faces.resource/yui/3_1_1/oop/oop-min.js.xhtml"></script>
and here is with the wrapper:
<script id="yui_3_1_1_1_13045343789972" type="text/javascript" charset="utf-8" src="/Sample/javax.faces.resource/yui/3_1_1/oop/oop-min.js.xhtml"></script>
It appears as though only scripts with an id="yui..." have this problem. The customer has also observed that for the non working scripts, the encodeURL method of his wrapper (adds "Sample" prefix) is never called so he thinks the path of these resources is created by javascript, perhaps by only keeping the first part on the left and wrongly assuming that the path before "javax.faces.resource" only has 1 part instead of 2 (/Part1/Part2).
He was able to reproduce this by wrapping the request and overriding the getContextPath method for it to return a context path with more than one part ("/PART1/PART2") instead of wrapping the response. Here is an example:
new HttpServletRequestWrapper(request) {
@Override
public String getContextPath() {
return super.getContextPath() + "/Sample";
}};
Sample application attached http://localhost:8080/test-jsf2/TEST/test.jsf
-
Hide
-
-
META-INF/MANIFEST.MF
-
content/content1.xhtml
-
content/content2.xhtml
-
content/dragDropInsert.xhtml
-
content/fileDataTableInclude.xhtml
-
content/fileEntryInclude.xhtml
-
content/splash.xhtml
-
content/tableTest.xhtml
-
content/treeInsert.xhtml
-
css/cssLayout.css
-
css/images/employee.gif
-
css/images/icon_info.gif
-
css/showcase_layout.css
-
css/showcase_overrides.css
-
css/showcase_style.css
-
index.jsp
-
main.xhtml
-
META-INF/context.xml
-
resources/test/table.xhtml
-
templates/footer.xhtml
-
templates/header.xhtml
-
templates/navigation.xhtml
-
templates/page-template.xhtml
-
test.xhtml
-
WEB-INF/faces-config.xml
-
WEB-INF/lib/commons-beanutils-1.8.1.jar
-
WEB-INF/lib/commons-collections-3.2.jar
-
WEB-INF/lib/commons-digester-1.8.jar
-
WEB-INF/lib/commons-logging-1.1.jar
-
WEB-INF/lib/icefaces-2.0.1.jar
-
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
And if you disable mandatory resource component loading, by setting the context param, to see if it's still broken.
<context-param>
<param-name>org.icefaces.mandatoryResourceConfiguration</param-name>
<param-value>none</param-value>
</context-param>
The regex handling does one of two things, depending on how old the code is. It either exactly duplicates the yui-min.js 's url, including whatever the extension is, or it hard-codes it to .jsf There's no code that would change it from .jsf to .xhtml
Which means that since yui-min.js is being loaded as yui-min.js.xhtml, then it's either a flaw of the core @MandatoryResourceComponent handling, or from the Mojarra @ResourceDependency handling, or some other framework/app thing that's messing up that .jsf extension.
Setting the mandatoryResourceConfiguration to false removes the Y.isPlugin JS error but adds additional script errors.
I've reviewed the issue. The first thing I'm going to say is that the 2.0.1 release didn't get to benefit from some changes in the regular expressions used to compose the URLs for YUI resources in the client (the 2.0 EE release has these improvements), as noted in ICE-6821. So, the problem with the path before "javax.faces.resource" having multiple parts may have already been fixed. However, as Mark notes, there's no code that would change the extension from .jsf to .xhtml. The Javascript code is designed to take whatever extension is configured in web.xml (usually .jsf), but it's not hard-coded to always use .jsf or any other extension.
I've confirmed that this problem is not present with the current code (post 2.0.1 release). The URLs composed by the YUI loader are now prefixed by the context path, and include the second part of the path added by the Response wrapper, as desired. E.g.:
However, I haven't been able to reproduce getting URLs with the .xhtml extension. I suppose this is actually not part of the problem, and they just have configured their app to use the .xhtml extension. Am I correct?
You can test this by simply using icefaces.jar and icefaces-ace.jar of a recent build instead of the 2.0.1 release jars.
In order to solve their problem we can give them a patch of icefaces.ace.jar that uses basically the same sources used in the 2.0.1 release and just replacing a single javascript file (/resources/org.icefaces.component.util/component.js) that contains the new regular expressions. Let me know what would be best.
Guys, for the Missing-scripts.jpg screenshot, I need the complete list of all GETs, with the whole path.