[
https://issues.jboss.org/browse/RF-12190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12686826#comment-12686826
]
Lukáš Fryč commented on RF-12190:
---------------------------------
As the workaround, you can:
* turn off resource optimizations
** web.xml: {{org.richfaces.resourceOptimization.enabled = false}}
* or reconfigure how resource mapping URL is built
** serve resources without FacesServlet (see "Moving resources to servers with
static content" in [1])
** web.xml: {{org.richfaces.resourceMapping.location}} option (undocumented ATM)
*** default value [2] is:
{code}
#{facesContext.externalContext.requestContextPath}/org.richfaces.resources/javax.faces.resource/#{resourceLocation}
{code}
[1]
http://rik-ansikter.blogspot.com/2012/02/re-routing-jsf-resource-requests-with.html
[2]
https://github.com/richfaces/core/blob/develop/impl/src/main/java/org/richfaces/resource/ResourceMappingFeature.java#L46
> ResourceServlet resources cannot be downloaded by a WSRP Consumer
> -----------------------------------------------------------------
>
> Key: RF-12190
> URL: https://issues.jboss.org/browse/RF-12190
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.2.1.Final
> Reporter: Neil Griffin
> Fix For: 4.3-Tracking
>
>
> 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.
--
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
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
