[JBoss JIRA] (RF-12254) kitchensink archetype - accessing wrong facelet is held in session and consequently accessing a correct one causes HTTP Status 500
by Juraj Huska (JIRA)
Juraj Huska created RF-12254:
--------------------------------
Summary: kitchensink archetype - accessing wrong facelet is held in session and consequently accessing a correct one causes HTTP Status 500
Key: RF-12254
URL: https://issues.jboss.org/browse/RF-12254
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: archetype, mobile
Affects Versions: 4.2.2.Final
Environment: project generated from kitchensink archetype
Reporter: Juraj Huska
Priority: Minor
When accessing wrong facelet on mobile device and consequently the right application context, then the HTTP Status 500 is returned with error message, which can be viewed in the attached screenshot.
It is caused because the {{PageBean}} hold the wrong part of the URL in the session,
{code}
public void setLocation(String location) {
this.location = location;
this.page = String.format("/mobile/%s.xhtml", location);
}
{code}
Note that I have tried to change the scope of the PageBean to RequestScoped, but then the list with members what not updated with the new created ones.
--
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
11 years, 12 months
[JBoss JIRA] (RF-12281) rich:tree is iterated multiple times when item is selected
by Alex Vb (JIRA)
Alex Vb created RF-12281:
----------------------------
Summary: rich:tree is iterated multiple times when item is selected
Key: RF-12281
URL: https://issues.jboss.org/browse/RF-12281
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-tree
Affects Versions: 4.2.2.Final
Reporter: Alex Vb
I have a decently sized tree and I'm using the selectionChangeListener in combination with toggleType="client" selectionType="ajax" render="node" to trigger a selection event on the server. The panelGroup "node" is re-rendered afterwards but it takes 1-2 seconds for each request. After enabling some debug logging I noticed that the entire tree is iterated 4 times for each request. Note a small test-tree exhibiting the same behavior:
2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - Before phase: APPLY_REQUEST_VALUES 2
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(0)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(1)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(1)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.287 DEBUG Bean - selectionChanged()
2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - After phase: APPLY_REQUEST_VALUES 2
2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - Before phase: PROCESS_VALIDATIONS 3
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(0)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(1)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(1)
2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: PROCESS_VALIDATIONS 3
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: UPDATE_MODEL_VALUES 4
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChildrenKeysIterator(0)
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(1)
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChildrenKeysIterator(1)
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: UPDATE_MODEL_VALUES 4
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: INVOKE_APPLICATION 5
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: INVOKE_APPLICATION 5
2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: RENDER_RESPONSE 6
2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChildrenKeysIterator(0)
2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(1)
2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChildrenKeysIterator(1)
2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(2)
2012-05-22 08:39:29.318 DEBUG CustomPhaseListener - After phase: RENDER_RESPONSE 6
On the rather large tree each iteration takes 300-500 ms which explains the slow behavior. I have played around with every setting I could find, if selectionType is set to "client" the tree is iterated only once (during the render response phase) but the selection event does not seem to be triggered. If toggleType is set to ajax, only the "expanded" parts of the tree are iterated.
I have no idea why the iteration is necessary for all these phases but I "fixed" it in my implementation by recompiling the org.richfaces.component.TreeRange class with an updated method:
public boolean shouldIterateChildren() {
if (tree.isLeaf())
return false;
else {
char separatorChar = UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance());
String clientId = tree.getClientId();
boolean render = false;
for (String idToRender : FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds()) {
// render the tree if you explicitly mention either the client id (e.g. "menuForm:tree") or the parent component client id (e.g. "menuForm")
// note that when clicking on an object in the tree, the following render target is requested: menuForm:tree@selection
if (clientId.equals(idToRender) || clientId.matches(idToRender + separatorChar + ".*")) {
render = true;
break;
}
}
// always render if it's not a postback
return render || !FacesContext.getCurrentInstance().isPostback();
}
}
--
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
11 years, 12 months
[JBoss JIRA] (RF-11992) cache bug in portlet
by Ivan Ravin (JIRA)
Ivan Ravin created RF-11992:
-------------------------------
Summary: cache bug in portlet
Key: RF-11992
URL: https://issues.jboss.org/browse/RF-11992
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2.0.CR1, 3.3.3.Final
Environment: jboss portal 2.7.2; Gatein portal
Reporter: Ivan Ravin
On Jboss and Gatein portal richfaces cant be cached when user is logged in.
Bug is found for richfaces 3.3.3 but i think can be reproduced for 4.x because org.richfaces.resource.AbstractCacheableResource has similar code.
The steps for reproduce bug are:
download portlet bridge 2.2 archive
deploy richFacesPortlet.war from portlet bridge archive (i used jboss portal 2.7.2 bundle and GateIn-3.1.0-FINAL-jbossas)
look at network activity (i did with firefox + firebug, the same result on any other browser). Just open page with richfaces portlet.
When user is not logged in, all richfaces resources are caching well, and this is headers returned by server:
|Cache-Control |max-age=86400|
|Content-Type |text/javascript|
|Date |Thu, 26 Jan 2012 17:57:39 GMT|
|Expires |27 Jan 2012 17:57:39 GMT|
|Last-Modified |26 Jan 2012 17:42:17 GMT|
|Server |Apache-Coyote/1.1|
|X-Powered-By |Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0|
But when user is logged in all richfaces stuff come from network every time (more than 1.3 mb).
This is headers returned by portal 2.7.2 when user logged in:
|Cache-Control |{color:red}no-cache,{color} max-age=86400|
|Content-Type |text/javascript|
|Date |Thu, 26 Jan 2012 18:26:49 GMT|
|Expires |{color:red}Thu, 01 Jan 1970 03:00:00 MSK,{color} 27 Jan 2012 18:26:49 GMT|
|Last-Modified |26 Jan 2012 18:05:56 GMT|
|{color:red}Pragma{color} |{color:red}No-cache{color}|
|Server |Apache-Coyote/1.1|
|Transfer-Encoding |chunked|
|X-Powered-By |Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0|
The same problem with GateIn-3.1.0-FINAL-jbossas bundle, but now only one wrong header:
|Cache-Control |max-age=86400|
|Content-Type |text/javascript;charset=UTF-8|
|Date |Sat, 28 Jan 2012 08:54:14 GMT|
|Expires |29 Jan 2012 08:54:14 GMT|
|Last-Modified |28 Jan 2012 08:51:11 GMT|
|{color:red}Pragma{color} |{color:red}No-cache{color}|
|Server |Apache-Coyote/1.1|
|Transfer-Encoding |chunked|
|X-Powered-By |Servlet 2.5; JBoss-5.0/JBossWeb-2.1|
This header (Pragma) appears only when user is logged in, and again, all richfaces resources come through network.
I did some debug and found that bridge create good headers, but there is some code in portal which put wrong values into real response before richfaces. I cant find this code in portal sources, so maybe it is JBoss AS problem, or third party component.
Gatein portal overwrite 2 wrong headers with values provided by richfaces, but "pragma" header is absent in richfaces response, and this way in secured portlets richfaces generate too much unnesessary traffic.
--
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
12 years