[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663205#comment-12663205
]
Brendan Healey commented on RF-11888:
-------------------------------------
Hello Brian, apologies for not responding earlier and thanks for the follow up.
Here's
my perspective. My initial bug report was clearly erroneous in that I'd fixated
on the
appending of a version string and failed to take into account the fact that the
URL
contains the richfaces release version. As such my concerns that stale
richfaces resources
with a long max-age (set by my application) could be served from browser cache
following
a richfaces upgrade were invalid.
On this basis I'd be happy for the ticket to be closed. However...
I think you need to consider the fact that unless you are able to handle the
appending
of a version string you'll be fielding a slow but steady stream of enquiries
from now
to eternity.
As part of the very simple implementation of the ResourceHandler interface you
have to
extend the ResourceHandlerWrapper class and override the createResource()
method. In this
method you will deal with any exclusions, any URLs to which you do not wish to
append a
version string. Here is the implementation I use:
@Override
public Resource createResource(String resourceName, String libraryName) {
Resource resource = super.createResource(resourceName, libraryName);
if(resourceName.equals("jquery.js") || (libraryName != null &&
(libraryName.equals("org.richfaces") ||
libraryName.equals(SQCC_LIBRARY)))) {
return resource;
}
else {
return new CustomResource(resource);
}
}
The thing that is that when you use <h:outputScript name="jquery.js"/> you are
using jquery
bundled with the richfaces libraries, as we all know. When you're using
resource mapping it's
this <h:outputScript ../> tag which triggers the loading of packed.js, not the
first richfaces
component on the page.
I'm already seeing people on the forum hitting this problem where they get the
'jsf is undefined'
error, which can be alleviated by using <h:outputScript library="javax.faces"
name="jsf.js" before
<h:outputScript name="jquery.js"/>.
Although entirely logical, especially with the benefit of hindsight, it's not
immediately
obvious that using the richfaces jquery is going to load the packed/compressed
richfaces
resources.
As relevant to the resource handler, as you can see from my implementation of
the createResource()
method above that it's presently necessary to exclude the resource name (not
the library name)
"jquery.js" from having a version string appended, or it won't work.
I'd say this took me half a day to fully debug and put a workaround into place,
so the question
is whether you wish to proliferate this scenario for other developers, or just
handle the version
string. I recommend the latter option.
Thanks for your help.
Brendan.
> Resource Servlet can't handle query string appended to resource url
> -------------------------------------------------------------------
>
> Key: RF-11888
> URL: https://issues.jboss.org/browse/RF-11888
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.1.0.Final
> Environment: Glassfish 3.1.1 (NO Tomcat)/Mojarra 2.1.3 Chrome browser
> -
> Reporter: Brendan Healey
> Priority: Critical
> Labels: waiting_on_user
>
> A custom resource handler
> (http://blogs.oracle.com/rlubke/entry/jsf_2_0_new_feature)
> can be used to append a version string (i.e. ?v=23) to a resource url to
> force a
> browser to refresh a resource rather than use any cached version.
> At present any appending of a version string causes a 404 response status,
> for example:
> Request URL:
> https://localhost:8181/MyApp/org.richfaces.resources/javax.faces.resource/org.richfaces.staticResource/4.1.0.Final/PackedCompressed/blueSky/packed/packed.css?v=23
> Removing the url parameter makes it work ok. As you can see I have
> resourceMapping
> enabled.
> This is essential to cause a browser to issue a request to the server if a
> static
> resource is held in a browser cache and is not expired, but you've upgraded
> the
> richfaces version. You have to have a way to invalidate the cache, and I'm not
> seeing how this can be done in a sensible way. You can set the Cache-Control
> no-cache header, but I'd need to do this in a way that says "I've just
> upgraded
> richfaces, so don't use the cache, issue a request to the server for the
> resource,
> but cache the result and use this until the next time".
--
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
