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

        Hide
        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
        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
        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
        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
        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.
        Hide
        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
        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.
        Hide
        Ken Fyten added a comment -

        Resolved.

        Show
        Ken Fyten added a comment - Resolved.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: