Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
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:
Description
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
- blocks
-
ICE-9338
Resource coalescing omitting fileentry.js
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.
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.
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.
The fixes for this issue were committed referencing
ICE-9338issue.