-
1. Re: Caching of Ajax.js
gkiesel May 18, 2009 11:03 AM (in response to gkiesel)Ok, I could just answer the version change question myself: the version no. is included in the returned uri so a new version would have a different one. Due to the new uri cached versions would become irrelevant.
That leaves me wondering whether I'm correct about my assumption that an error occuring while reading/compressing the script stream could lead to a valid response without content, blocking the application from using ajax for atleast a day?
Wouldn't it be better to also throw the exception as done when compression is turned of? -
2. Re: Caching of Ajax.js
jbalunas May 24, 2009 7:33 AM (in response to gkiesel)Please use the RichFaces forum for user questions. This forum is specifically for design and development of the RichFaces project. I will move this post there.
-
3. Re: Caching of Ajax.js
gkiesel May 27, 2009 2:45 AM (in response to gkiesel)In my opinion discussing the way RichFaces handles internal errors is a development question. However I'm more interested in an answer then where the topic is located. ;o)
-
4. Re: Caching of Ajax.js
nbelaevski May 27, 2009 7:06 AM (in response to gkiesel)"gkiesel" wrote:
Ok, I could just answer the version change question myself: the version no. is included in the returned uri so a new version would have a different one. Due to the new uri cached versions would become irrelevant.
Exactly."gkiesel" wrote:
That leaves me wondering whether I'm correct about my assumption that an error occuring while reading/compressing the script stream could lead to a valid response without content, blocking the application from using ajax for atleast a day?
Wouldn't it be better to also throw the exception as done when compression is turned of?
As far as I remember, this problem happened in one old version of Ajax4JSF - the first response came with '0' content-length, others were ok. That was not the issue in script minimization (scripts worked ok, furthermore you can turn the compression off), but coding error. Ctrl + F5 should solve the issue either as upgrade to a newer RF version (is it an option for you?). -
5. Re: Caching of Ajax.js
agrimm May 27, 2009 7:40 AM (in response to gkiesel)Hi,
we are facing a similar behavior and a update of the A4J-Libs would be a option for us. But can you tell me, what version causes that bug?
Thank you for your help anyway. :-)
Achim -
6. Re: Caching of Ajax.js
gkiesel Jun 2, 2009 5:38 AM (in response to gkiesel)Hello,
thank you for your answer.Ctrl + F5 should solve the issue either as upgrade to a newer RF version (is it an option for you?).
Ctrl+F5 didn't help in our case. The proxy between client and app-server still returned the cached 0 byte script. Upgrading to a newer RF version is something we plan to do, but it requires a new app-server version and is thus no short term solution.
Let me show the piece of code that is the heart of the problem from my point of view from class ScriptRenderer (Revision: 1.1.2.1):public int send(InternetResource base, ResourceContext context) throws IOException { InputStream in = base.getResourceAsStream(context); if (null == in) { String message = Messages.getMessage( Messages.NO_INPUT_STREAM_ERROR, base.getKey()); throw new IOException(message); } OutputStream out = context.getOutputStream(); // Compress JavaScript output by JSMin ( true by default ) if( ! "false".equalsIgnoreCase(context.getInitParameter(COMPRESS_SCRIPTS_PARAMETER))){ CountingOutputStream countingStream = new CountingOutputStream(out); JSMin jsmin = new JSMin(in,countingStream); try { jsmin.jsmin(); } catch (Exception e) { _log.error("Error send script to client for resource "+base.getKey(), e); } finally { in.close(); countingStream.flush(); countingStream.close(); } int written = countingStream.getWritten(); if(_log.isDebugEnabled()){ _log.debug("Send "+written+" bytes to client for JavaScript resource "+base.getKey()); } return written; } else { return sendStream(in, out); } }
I think the catch block when using the jsmin option should throw an exception and not just log it.
As Nick says turning compression of avoids the problem and that is what we did (however we ofcourse have to transfer some bytes more now). -
7. Re: Caching of Ajax.js
nbelaevski Jun 2, 2009 3:39 PM (in response to gkiesel)I think the catch block when using the jsmin option should throw an exception and not just log it.
Browser doesn't show resources loading errors, so it's better to do explicit logging. -
8. Re: Caching of Ajax.js
gkiesel Jun 8, 2009 9:41 AM (in response to gkiesel)Browser doesn't show resources loading errors, so it's better to do explicit logging.
Do log the error is definitely a good idea. But in this case an exception should be thrown as well.