[JBoss JIRA] Created: (RF-1021) Caching not working for internet resources on Firefox + secure web app
by Jason Anderson (JIRA)
Caching not working for internet resources on Firefox + secure web app
----------------------------------------------------------------------
Key: RF-1021
URL: http://jira.jboss.com/jira/browse/RF-1021
Project: RichFaces
Issue Type: Feature Request
Affects Versions: 3.1.1
Environment: JSF-RI 1.2p02, Seam 2.0.0.CR1, JBoss 4.0.3+Tomcat 5.5 (patched to JSF 1.2)
Reporter: Jason Anderson
All internet resources being returned by RichFaces/ajax4jsf (e.g. /a4j*/*.jsf) have a custom response header set (e.g. max-age=....).
For secure applications using SSL, Tomcat automatically tries to set Pragma: no-cache on everything, so you have to write a custom servlet filter for the rest of the application that overrides the no-cache, and sets the cache settings to "public" etc. for resources which are truely static.
The problem is that the custom filter cannot override resources returned by RichFaces (doesn't seem to matter where in the filter chain the custom filter is, calling response.setHeader will not override the one set in InternetResourceBase.sendHeader ).
The effect of this is that we can get resources caching correctly in IE, but for Firefox what Richfaces return is incomplete and Firefox refuses to cache any of the RichFaces resources.
I'm not sure what to recommend, either to allow web app to optionally turn off InternetResourceBase.sendHeaders and allow application to control this itself, or to simply fix the InternerResourceBase to setup addition response header cache control items like "PUBLIC" or "must-revalidate".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (RF-940) Integrate dropDownMenu with Seam s:link
by Joshua Jackson (JIRA)
Integrate dropDownMenu with Seam s:link
----------------------------------------
Key: RF-940
URL: http://jira.jboss.com/jira/browse/RF-940
Project: RichFaces
Issue Type: Feature Request
Affects Versions: 3.1.0
Environment: JBoss 4.2.1.GA
Reporter: Joshua Jackson
Priority: Trivial
Fix For: 3.2.0
Seam s:link has a very nice attribute like view which does not do form submission unlike action attribute but only redirects to the page. Besides that s:link has conversationPropagation which able to demarcate Seam conversation. I think it would be nice to have incorporate these to Richfaces dropDownMenu.
I've tried embedding s:link in rich:dropDownMenu but I found it really uncomfortable for user because user must click right on the link otherwise the menu won't do anything and besides that we must adjust the style of the link that is nested in css.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (RF-995) SkinFactory cannot be overriden reliably.
by Chris Rudd (JIRA)
SkinFactory cannot be overriden reliably.
-----------------------------------------
Key: RF-995
URL: http://jira.jboss.com/jira/browse/RF-995
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Chris Rudd
Prior to 3.1.0 the default SkinFactory could be replaced by specifing the implementation class in the resource : META-INF/services/org.richfaces.skin.SkinFactory
As of 3.1.0 there is no "default" implementation, and the richfaces-impl.jar now defines the resource inorder to specify the implementation.
This causes a problem when attempting to override the implemenation, as resources are found in whatever order the jars are in the classpath. There is no reliable way to ensure that the resource located in the jar providing the overriding implementation appears first (before the richfaces-impl).
I would suggest reserving the service file for the ability to override the default implementation, and introduce a new file to define the default implementation, or reference the default implemenation by name (to prevent the hard reference)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months