[ https://issues.jboss.org/browse/RF-12190?page=com.atlassian.jira.plugin.s... ] Neil Griffin updated RF-12190: ------------------------------ Description: RichFaces 4 is generally working in Liferay Portal 6.1 WSRP and Liferay Faces Bridge, but components like rich:calendar aren't rendering properly. The problem stems from the fact that some components rely on context-path relative URLs, rather than the JSF2 resource mechanism. For example, with rich:calendar, the popup button is rendered as an image like this: {code} <img alt="" class="rf-cal-btn " id="A5352:l1:c1:f1:fs1:c1b:dateOfBirthPopupButton" src="/my-portlet/org.richfaces.resources/javax.faces.resource/org.richfaces.staticResource/4.2.0.Final/Packed/DEFAULT/org.richfaces.images/calendarIcon.png" style="vertical-align: middle"> {code} This is a problem because it ultimately relies on the /my-portlet context-path of the request, which is not compatible with WSRP. If the URL for calendarIcon.png was created by ExternalContext.encodeResourceURL(String) then then the WSRP problem would be solved, because it would be retrieved with a portlet ResourceURL that WSRP knows how to rewrite for the WSRP Consumer to download. But this wouldn't solve the problem entirely -- here is a fragment of CSS from packed.css: {code} .rf-cal-btn-close { background-image: url(../org.richfaces.images/calendarSeparator.png); } {code} The problem here is that calendarSeparator.png is expected to live relative to the packed.css file, in a URL like "/my-portlet/.../4.2.0.Final/Packed/calendarSeparator.png" but you can't make that context-path-relative assumption with WSRP. To fix this problem, the #{resource} EL keyword would have to be used within the packed.css file for each image resource, something similar to this: {code} .rf-cal-btn-close { background-image: url("#{resource['richfaces-theme:org.richfaces.images/calendarSeparator.png']}"); } {code} I *thought* that a workaround could be to deploy a lightweight webapp in the same server as the WSRP Consumer that contains the ResourceServlet and theme resources. But it isn't good enough, because the relative URLs from packed.css would produce WSRP errors because they can't simply be appended to a wsrp_rewrite URL. was: RichFaces 4 is generally working in Liferay Portal 6.1 WSRP and Liferay Faces Bridge, but components like rich:calendar aren't rendering properly. The problem stems from the fact that some components rely on context-path relative URLs, rather than the JSF2 resource mechanism. For example, with rich:calendar, the popup button is rendered as an image like this: {code} <img alt="" class="rf-cal-btn " id="A5352:l1:c1:f1:fs1:c1b:dateOfBirthPopupButton" src="/my-portlet/org.richfaces.resources/javax.faces.resource/org.richfaces.staticResource/4.2.0.Final/Packed/DEFAULT/org.richfaces.images/calendarIcon.png" style="vertical-align: middle"> {code} This is a problem because it ultimately relies on the /my-portlet context-path of the request, which is not compatible with WSRP. If the URL for calendarIcon.png was created by ExternalContext.encodeResourceURL(String) then then the WSRP problem would be solved, because it would be retrieved with a portlet ResourceURL that WSRP knows how to rewrite for the WSRP Consumer to download. But this wouldn't solve the problem entirely -- here is a fragment of CSS from packed.css: {code} .rf-cal-btn-close { background-image: url(../org.richfaces.images/calendarSeparator.png); } {code} The problem here is that calendarSeparator.png is expected to live relative to the packed.css file, in a URL like "/my-portlet/.../4.2.0.Final/Packed/calendarSeparator.png" but you can't make that context-path-relative assumption with WSRP. To fix this problem, the #{resource} EL keyword would have to be used within the packed.css file for each image resource, something similar to this: {code} .rf-cal-btn-close { background-image: url("#{resource['richfaces-theme:org.richfaces.images/calendarSeparator.png']}"); } {code} One workaround would be to deploy a lightweight webapp in the same server as the WSRP Consumer that contains the ResourceServlet and theme resources, but that doesn't exactly achieve what WSRP is trying to accomplish, which is to have the entire portlet (and it's resources) deployed to a remote portal server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12190?page=com.atlassian.jira.plugin.s... ] Neil Griffin commented on RF-12190: ----------------------------------- Thanks Brian :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12190?page=com.atlassian.jira.plugin.s... ] Neil Griffin commented on RF-12190: ----------------------------------- I tried org.richfaces.resourceOptimization.enabled = false in web.xml but the context-path still always appears in the rendered URL which doesn't work with WSRP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira