ICEfaces
  1. ICEfaces
  2. ICE-9263

Resource coalescing does not work in a portlet environment

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3, EE-3.3.0.GA
    • Fix Version/s: EE-3.3.0.GA_P01, 4.0.BETA, 4.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Portlet portal resource coalescing
    • Assignee Priority:
      P3
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      Turn off resource coalescing for portlets. It's off by default but you can set it using:


      <context-param>
          <param-name>org.icefaces.coalesceResources</param-name>
          <param-value>false</param-value>
      </context-param>
      Show
      Turn off resource coalescing for portlets. It's off by default but you can set it using: <context-param>     <param-name>org.icefaces.coalesceResources</param-name>     <param-value>false</param-value> </context-param>

      Description

      Resource coalescing in a portlet environment does not behave as intended. Turning on the context parameter to enable resource coalescing and running the showcase-portlet example in Liferay results in the following errors being logged to the console:

      21:58:19,746 ERROR [MissingResourceImpl:78] Resource handler=[com.liferay.faces.bridge.application.ResourceHandlerOuterImpl@10652a37] was unable to create a resource for resourceName=[coalesced.css.xhtml] libraryName=[ice.core] contentType=[null]

      21:58:19,885 ERROR [MissingResourceImpl:78] Resource handler=[com.liferay.faces.bridge.application.ResourceHandlerOuterImpl@10652a37] was unable to create a resource for resourceName=[coalesced.js.xhtml] libraryName=[ice.core] contentType=[null]

        Issue Links

          Activity

          Hide
          Mircea Toma added a comment -

          The fixes for this issue were committed referencing ICE-9338 issue.

          Show
          Mircea Toma added a comment - The fixes for this issue were committed referencing ICE-9338 issue.
          Hide
          Deryk Sinotte added a comment -

          Re-opening the issue.

          As per the analysis in ICE-9338, the resource coalescing logic doesn't factor in handling multiple views on a single page. Portlets with different sets of resources result in "gaps" where resources in one portlet are missed if they are not in the other portlets.

          Show
          Deryk Sinotte added a comment - Re-opening the issue. As per the analysis in ICE-9338 , the resource coalescing logic doesn't factor in handling multiple views on a single page. Portlets with different sets of resources result in "gaps" where resources in one portlet are missed if they are not in the other portlets.
          Hide
          Deryk Sinotte added a comment -

          Took awhile to land on a strategy that worked for portlets without breaking our existing strategy for non-portlet environments but I've checked in a fix that appears to allow resource coallescing to work in both environments.

          Portlet resources typically come back as absolute URLs (start with http) which posed a problem for some of the logic we had in there for "external" resources (like GMap). We also can't build the URLs ourselves as that is the responsibility of the bridge so instead I opted to use a dummy resource (resources/ice.core/coalesced.txt) that physically exists where the dynamic resources (coalesced.js and coalesced.css) would exist if they were actual files. Once I have a valid path to the dummy resource, I substitute the real library name in place of the dummy name.

          I modified the showcase-portlet application to have resource coalescing on by default.

          Show
          Deryk Sinotte added a comment - Took awhile to land on a strategy that worked for portlets without breaking our existing strategy for non-portlet environments but I've checked in a fix that appears to allow resource coallescing to work in both environments. Portlet resources typically come back as absolute URLs (start with http) which posed a problem for some of the logic we had in there for "external" resources (like GMap). We also can't build the URLs ourselves as that is the responsibility of the bridge so instead I opted to use a dummy resource (resources/ice.core/coalesced.txt) that physically exists where the dynamic resources (coalesced.js and coalesced.css) would exist if they were actual files. Once I have a valid path to the dummy resource, I substitute the real library name in place of the dummy name. I modified the showcase-portlet application to have resource coalescing on by default.
          Hide
          Deryk Sinotte added a comment -

          The issues is likely caused by the portlet bridge. It includes a relatively new ResourceHandler that looks to be run first. The JavaDoc for that file is:

          "Unlike the ResourceHandlerInnerImpl class, this class is designed to be the outermost javax.faces.application.ResourceHandler in the chain-of-responsibility. In order to achieve this outermost status, this class does not appear in the bridge's faces-config.xml descriptor. Rather, it is created by the ApplicationCompatImpl.getResourceHandler() method. If necessary, it wraps resources with javax.faces.application.ResourceHandlerWrapper instances that override the javax.faces.application.Resource.getRequestPath() method. This provides the bridge with the opportunity to have the final authority regarding the format of resource URLs created by ResourceHandlers like the ones provided by ICEfaces, PrimeFaces, and RichFaces."

          The resource coalescing strategy is based on creating "dynamic" resources (coalesced.js and coalesced.css) that don't exist as actual physical files on the filesystem. My guess is that when the portlet bridge ResourceHandlerOuterImpl is run and tries to create the resource, it can't find the files and constructs a MissingResourceImpl. We need to find a way to operate effectively with this handler. Simply creating dummy versions of the files did not seem to help. I tried creating:

          coalesced.js
          coalesced.css

          but that didn't help as the bridge ends up looking for:

          coalesced.js.xhtml
          coalesced.css.xhtml

          I tried creating those files and they were found but it served up the actual empty dummy files rather than the coalesced versions.

          Show
          Deryk Sinotte added a comment - The issues is likely caused by the portlet bridge. It includes a relatively new ResourceHandler that looks to be run first. The JavaDoc for that file is: "Unlike the ResourceHandlerInnerImpl class, this class is designed to be the outermost javax.faces.application.ResourceHandler in the chain-of-responsibility. In order to achieve this outermost status, this class does not appear in the bridge's faces-config.xml descriptor. Rather, it is created by the ApplicationCompatImpl.getResourceHandler() method. If necessary, it wraps resources with javax.faces.application.ResourceHandlerWrapper instances that override the javax.faces.application.Resource.getRequestPath() method. This provides the bridge with the opportunity to have the final authority regarding the format of resource URLs created by ResourceHandlers like the ones provided by ICEfaces, PrimeFaces, and RichFaces." The resource coalescing strategy is based on creating "dynamic" resources (coalesced.js and coalesced.css) that don't exist as actual physical files on the filesystem. My guess is that when the portlet bridge ResourceHandlerOuterImpl is run and tries to create the resource, it can't find the files and constructs a MissingResourceImpl. We need to find a way to operate effectively with this handler. Simply creating dummy versions of the files did not seem to help. I tried creating: coalesced.js coalesced.css but that didn't help as the bridge ends up looking for: coalesced.js.xhtml coalesced.css.xhtml I tried creating those files and they were found but it served up the actual empty dummy files rather than the coalesced versions.

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: