ICEfaces
  1. ICEfaces
  2. ICE-6846

ACE YUI loader script issue when wrapping request

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major 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

            The customer has reported the following. They have upgraded their application from 2.0.0 to 2.0.1 and upon startup are seeing requests for javascript resources with a URI that does not include the context path and results in a 404. The incorrect resources are:

            * 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

              Activity

              Ascending order - Click to sort in descending order
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #24481 Thu May 05 09:10:07 MDT 2011 mark.collette ICE-6846 : ACE YUI loader script issue when wrapping request
              Files Changed
              Commit graph MODIFY /icefaces2/scratchpads/ICE-6728/icefaces-2.0.x-maintenance/icefaces/ace/component/resources/org.icefaces.component.util/util.js
              Commit graph MODIFY /icefaces2/scratchpads/ICE-6728/icefaces-2.0.x-maintenance/icefaces/ace/component/src/org/icefaces/component/tab/TabSetMeta.java
              Commit graph MODIFY /icefaces2/scratchpads/ICE-6728/icefaces-2.0.x-maintenance/icefaces/ace/component/resources/org.icefaces.component.tab/tabset.js
              Commit graph MODIFY /icefaces2/scratchpads/ICE-6728/icefaces-2.0.x-maintenance/icefaces/ace/component/src/org/icefaces/component/utils/JSONBuilder.java
              Commit graph MODIFY /icefaces2/scratchpads/ICE-6728/icefaces-2.0.x-maintenance/icefaces/ace/component/src/org/icefaces/component/tab/TabSetRenderer.java
              Tyler Johnson created issue -
              Tyler Johnson made changes -
              Field Original Value New Value
              Attachment test-jsf2.war [ 13206 ]
              Tyler Johnson made changes -
              Salesforce Case [5007000000GuKdA]
              Tyler Johnson made changes -
              Attachment JS-errors.jpg [ 13207 ]
              Tyler Johnson made changes -
              Attachment Missing-scripts.jpg [ 13208 ]
              Ken Fyten made changes -
              Fix Version/s 2.0.2 [ 10273 ]
              Fix Version/s 2.1 [ 10241 ]
              Affects [Compatibility/Configuration]
              Assignee Priority P1
              Assignee Arturo Zambrano [ artzambrano ]
              Hide
              Permalink
              Mark Collette added a comment -

              Guys, for the Missing-scripts.jpg screenshot, I need the complete list of all GETs, with the whole path.

              Show
              Mark Collette added a comment - Guys, for the Missing-scripts.jpg screenshot, I need the complete list of all GETs, with the whole path.
              Hide
              Permalink
              Mark Collette added a comment -

              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>

              Show
              Mark Collette added a comment - 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>
              Hide
              Permalink
              Mark Collette added a comment -

              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.

              Show
              Mark Collette added a comment - 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.
              Hide
              Permalink
              Tyler Johnson added a comment -

              Setting the mandatoryResourceConfiguration to false removes the Y.isPlugin JS error but adds additional script errors.

              Show
              Tyler Johnson added a comment - Setting the mandatoryResourceConfiguration to false removes the Y.isPlugin JS error but adds additional script errors.
              Hide
              Permalink
              Arturo Zambrano added a comment -

              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.

              Show
              Arturo Zambrano added a comment - 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.
              Ken Fyten made changes -
              Fix Version/s EE-2.0.0.GA_P01 [ 10271 ]
              Fix Version/s 2.0.2 [ 10273 ]
              Affects Version/s EE-2.0.0.GA [ 10263 ]
              Hide
              Permalink
              Arturo Zambrano added a comment -

              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.:

              http://localhost:8080/test-jsf2/TEST/javax.faces.resource/event-custom/event-custom-min.js.jsf?ln=yui/3_1_1

              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?

              Show
              Arturo Zambrano added a comment - 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.: http://localhost:8080/test-jsf2/TEST/javax.faces.resource/event-custom/event-custom-min.js.jsf?ln=yui/3_1_1 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?
              Hide
              Permalink
              Arturo Zambrano added a comment -

              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.

              Show
              Arturo Zambrano added a comment - 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.
              Ken Fyten made changes -
              Fix Version/s 2.0.2 [ 10273 ]
              Fix Version/s 2.1 [ 10241 ]
              Assignee Priority P1
              Hide
              Permalink
              Ken Fyten added a comment -

              Resolved.

              Show
              Ken Fyten added a comment - Resolved.
              Ken Fyten made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Arturo Zambrano
                  Reporter:
                  Tyler Johnson
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: