[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-12802:
----------------------------------
I have updated the PR according to its comments.
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Juraj Húska
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (RF-13280) RF 5 packed resources cause conflict in RF 4.5
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13280?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13280:
---------------------------------
Michal, note that I have copied the missing resources to META-INF/resources folder now.
So the only required step is now separating ui.js and core.js and adequeate changes in RF 4.5, so that:
RF 4.5 loads core.js and packed.js
RF 5.0 loads core.js and ui.js
> RF 5 packed resources cause conflict in RF 4.5
> ----------------------------------------------
>
> Key: RF-13280
> URL: https://issues.jboss.org/browse/RF-13280
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.5.0.Alpha1
> Reporter: Michal Petrov
> Assignee: Lukáš Fryč
> Fix For: 4.5.0.Alpha1, 5.0.0.Alpha2
>
>
> Showcase uses resource from RF 5 core instead of using the proper ones from RF 4.5 components. (e.g. packed.js)
> The solution is to split core and ui resources in RF 5. RF 4.5 will only generate ui resources and use core resources from RF 5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (RF-13294) Broken caching of static resources in IE
by Nicholas Oxhøj (JIRA)
[ https://issues.jboss.org/browse/RF-13294?page=com.atlassian.jira.plugin.s... ]
Nicholas Oxhøj updated RF-13294:
--------------------------------
Description:
There seems to be a problem with the caching headers sent by RichFaces in relation to IE (IE8 at least which is the one I have tested).
The default for RichFaces, is to tell the browser to cache static resources for 24 hours:
{code}
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-control: max-age=86400
Last-Modified: Tue, 29 Oct 2013 13:01:56 GMT
Expires: Wed, 30 Oct 2013 13:02:39 GMT
Content-Type: text/javascript
Content-Length: 117992
Date: Tue, 29 Oct 2013 13:02:39 GMT
{code}
But it seems that when IE, after 24 hours, validates the file with a "If-Modified-Since" and receives a "304 Not Modified" response
{code}
HTTP/1.1 304 Not Modified
Server: Apache-Coyote/1.1
Date: Tue, 29 Oct 2013 13:07:56 GMT
{code}
it will *keep* re-validating the file on all subsequent pages/uses, whereas e.g. FireFox _seems_ to reapply the "max-age" of 24 hours, that it was told on the initial GET of the file.
I haven't been able to find any specifications, blog posts or anything else related to how the browser should react _after_ having received a "304 Not Modified" response.
But it seems that if you add a "Cache-control: max-age=..." header to the "304 Not Modified" response in InternetResourceService#serviceResource(), IE will not re-validate the file until that max-age has expired.
{code}
HTTP/1.1 304 Not Modified
Server: Apache-Coyote/1.1
Cache-control: max-age=86400
Date: Tue, 29 Oct 2013 13:07:56 GMT
{code}
was:
There seems to be a problem with the caching headers sent by RichFaces in relation to IE (IE8 at least which is the one I have tested).
The default for RichFaces, is to tell the browser to cache static resources for 24 hours. But it seems that when IE, after 24 hours, validates the file with a "If-Modified-Since" and receives a "304 Not Modified" response, it will KEEP re-validating the file on all subsequent pages/uses, whereas e.g. FireFox _seems_ to reapply the "max-age" of 24 hours, that it was told on the initial GET of the file.
I haven't been able to find any specifications, blog posts or anything else related to how the browser should react _after_ having received a "304 Not Modified" response.
But it seems that if you add a "Cache-control: max-age=..." header to the "304 Not Modified" response in InternetResourceService#serviceResource(), IE will not re-validate the file until that max-age has expired.
> Broken caching of static resources in IE
> ----------------------------------------
>
> Key: RF-13294
> URL: https://issues.jboss.org/browse/RF-13294
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.3.3.Final
> Reporter: Nicholas Oxhøj
>
> There seems to be a problem with the caching headers sent by RichFaces in relation to IE (IE8 at least which is the one I have tested).
> The default for RichFaces, is to tell the browser to cache static resources for 24 hours:
> {code}
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Cache-control: max-age=86400
> Last-Modified: Tue, 29 Oct 2013 13:01:56 GMT
> Expires: Wed, 30 Oct 2013 13:02:39 GMT
> Content-Type: text/javascript
> Content-Length: 117992
> Date: Tue, 29 Oct 2013 13:02:39 GMT
> {code}
> But it seems that when IE, after 24 hours, validates the file with a "If-Modified-Since" and receives a "304 Not Modified" response
> {code}
> HTTP/1.1 304 Not Modified
> Server: Apache-Coyote/1.1
> Date: Tue, 29 Oct 2013 13:07:56 GMT
> {code}
> it will *keep* re-validating the file on all subsequent pages/uses, whereas e.g. FireFox _seems_ to reapply the "max-age" of 24 hours, that it was told on the initial GET of the file.
> I haven't been able to find any specifications, blog posts or anything else related to how the browser should react _after_ having received a "304 Not Modified" response.
> But it seems that if you add a "Cache-control: max-age=..." header to the "304 Not Modified" response in InternetResourceService#serviceResource(), IE will not re-validate the file until that max-age has expired.
> {code}
> HTTP/1.1 304 Not Modified
> Server: Apache-Coyote/1.1
> Cache-control: max-age=86400
> Date: Tue, 29 Oct 2013 13:07:56 GMT
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (RF-13294) Broken caching of static resources in IE
by Nicholas Oxhøj (JIRA)
Nicholas Oxhøj created RF-13294:
-----------------------------------
Summary: Broken caching of static resources in IE
Key: RF-13294
URL: https://issues.jboss.org/browse/RF-13294
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.3.3.Final
Reporter: Nicholas Oxhøj
There seems to be a problem with the caching headers sent by RichFaces in relation to IE (IE8 at least which is the one I have tested).
The default for RichFaces, is to tell the browser to cache static resources for 24 hours. But it seems that when IE, after 24 hours, validates the file with a "If-Modified-Since" and receives a "304 Not Modified" response, it will KEEP re-validating the file on all subsequent pages/uses, whereas e.g. FireFox _seems_ to reapply the "max-age" of 24 hours, that it was told on the initial GET of the file.
I haven't been able to find any specifications, blog posts or anything else related to how the browser should react _after_ having received a "304 Not Modified" response.
But it seems that if you add a "Cache-control: max-age=..." header to the "304 Not Modified" response in InternetResourceService#serviceResource(), IE will not re-validate the file until that max-age has expired.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months