[JBoss JIRA] (RF-13107) rich:message in tabPanel is not shown if other message is not rendered
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13107?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13107:
-------------------------------
Fix Version/s: 4.3.4
> rich:message in tabPanel is not shown if other message is not rendered
> ----------------------------------------------------------------------
>
> Key: RF-13107
> URL: https://issues.jboss.org/browse/RF-13107
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.2
> Reporter: Jonáš Trantina
> Fix For: 4.3.4
>
> Attachments: bug_reproducer.zip
>
>
> We have a form with a tabPanel component with two tabs A and B. In A there is an input and its rich:message in B the same plus a button that submits and re-renders B. When B is opened (thus A is not rendered) and the form is submitted and validation fails, then no message is shown.
> Note that:
> 1) switchType must be set to server to ensure the A's rich:message is really not on the page.
> 2) button in B must re-render only content of B
> This is only a specific scenario, the issue might occur also in other situations (e.g. global messages tag outside of tabPanel is not rendered).
> Please find the enclosed reproducer.
--
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
10 years, 9 months
[JBoss JIRA] (RF-13109) a4j:push transaction flood
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13109?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13109:
------------------------------------
A google search suggests setting the FlushPackets in mod_jk:
http://tomcat.apache.org/connectors-doc/reference/apache.html
Alternatively, try using mod_proxy instead of mod_jk. Here is a link to a discussion on using mod_proxy with Glassfish and Atmosphere:
https://groups.google.com/d/topic/atmosphere-framework/7fT4nIk2b3Y/discus...
> a4j:push transaction flood
> ---------------------------
>
> Key: RF-13109
> URL: https://issues.jboss.org/browse/RF-13109
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.2.2.Final, 4.2.3.Final, 4.3.1
> Environment: CHROME,Jboss 7.1.1.Final, Jboss 7.1.3.Final, CentoOS6.X, Windows 7
> Reporter: nathan dennis
> Labels: a4j:push, richfaces
> Attachments: a4jPushFlood.tar.gz
>
>
> long poll doesnt refresh at the 30 second mark. After 5 minutes, Chrome goes into meltdown, sending a transaction back to the server approx. ever 8 ms causing DOS and browser lock after about 3 seconds.
> Firefox on the other hand returns a cancelled transaction, exits abnormally, and goes back to behaving as expected with the appearance that it is working correctly.
> This took me forever to find out why this was happening as I couldn't replicate it with the showcase code... or the test project i built specifically for figuring this out. In the end I was removing one component at a time until it started working.
> The cause of the issue is found in the jboss-web.xml file. For years, I have ran apache in front of my jboss installations. I would specify root context to / and map the domain straight to it using a virtual host in the jboss server config file (regardless of the version). AJP in front and away you go. a4j:push will crash if this context is mapped to / instead of /foo.
> I'm going to attempt to attach the sample project to recreate this with. Map the alias from jboss-web.xml to a virtual server in your standalone.xml file and start it up. navigate to the consumer link at the top of the app. turn on your developer tools and wait for the chaos. at the five minute mark you are going to see death and destruction.
--
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
10 years, 9 months
[JBoss JIRA] (RF-13109) a4j:push transaction flood
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/RF-13109?page=com.atlassian.jira.plugin.s... ]
nathan dennis commented on RF-13109:
------------------------------------
apache 2.2.15-28
Mod JK 1.3
centos 6.4 final
kernel 2.6.32-358.11.1.el6.x86_64
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.3.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
<VirtualHost 10.2.8.2:80>
ServerAdmin "webmaster(a)a4jpushflood.localhost"
ServerName a4jpushflood.localhost
ErrorLog /var/log/httpd/forms_errmr_log
JkMount /* ajp13w
DocumentRoot "/"
<Directory "/home/nbd/public_html">
Options +Indexes +FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
<Location /usage>
Order allow,deny
Allow from all
</Location>
</VirtualHost>
worker.list=wlb,jkstatus,ajp13w
#
#
# Defining a worker named ajp13w and of type ajp13
# Note that the name and the type do not have to match.
#
worker.ajp13w.type=ajp13
worker.ajp13w.host=10.2.8.2
#
# Defining a load balancer
#
worker.wlb.type=lb
worker.wlb.balance_workers=ajp13w
#
# Define status worker
#
worker.jkstatus.type=status
> a4j:push transaction flood
> ---------------------------
>
> Key: RF-13109
> URL: https://issues.jboss.org/browse/RF-13109
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.2.2.Final, 4.2.3.Final, 4.3.1
> Environment: CHROME,Jboss 7.1.1.Final, Jboss 7.1.3.Final, CentoOS6.X, Windows 7
> Reporter: nathan dennis
> Labels: a4j:push, richfaces
> Attachments: a4jPushFlood.tar.gz
>
>
> long poll doesnt refresh at the 30 second mark. After 5 minutes, Chrome goes into meltdown, sending a transaction back to the server approx. ever 8 ms causing DOS and browser lock after about 3 seconds.
> Firefox on the other hand returns a cancelled transaction, exits abnormally, and goes back to behaving as expected with the appearance that it is working correctly.
> This took me forever to find out why this was happening as I couldn't replicate it with the showcase code... or the test project i built specifically for figuring this out. In the end I was removing one component at a time until it started working.
> The cause of the issue is found in the jboss-web.xml file. For years, I have ran apache in front of my jboss installations. I would specify root context to / and map the domain straight to it using a virtual host in the jboss server config file (regardless of the version). AJP in front and away you go. a4j:push will crash if this context is mapped to / instead of /foo.
> I'm going to attempt to attach the sample project to recreate this with. Map the alias from jboss-web.xml to a virtual server in your standalone.xml file and start it up. navigate to the consumer link at the top of the app. turn on your developer tools and wait for the chaos. at the five minute mark you are going to see death and destruction.
--
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
10 years, 9 months
[JBoss JIRA] (RF-13109) a4j:push transaction flood
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/RF-13109?page=com.atlassian.jira.plugin.s... ]
nathan dennis commented on RF-13109:
------------------------------------
turns out that even with the context mapping added, if you place Apache in front this happens. ie... if you map the virtual host with context .... foo.bar.net/contextname it will still DOS your server. in fact this stuff only works when you are running through 8080 straight to the appserver.
> a4j:push transaction flood
> ---------------------------
>
> Key: RF-13109
> URL: https://issues.jboss.org/browse/RF-13109
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.2.2.Final, 4.2.3.Final, 4.3.1
> Environment: CHROME,Jboss 7.1.1.Final, Jboss 7.1.3.Final, CentoOS6.X, Windows 7
> Reporter: nathan dennis
> Labels: a4j:push, richfaces
> Attachments: a4jPushFlood.tar.gz
>
>
> long poll doesnt refresh at the 30 second mark. After 5 minutes, Chrome goes into meltdown, sending a transaction back to the server approx. ever 8 ms causing DOS and browser lock after about 3 seconds.
> Firefox on the other hand returns a cancelled transaction, exits abnormally, and goes back to behaving as expected with the appearance that it is working correctly.
> This took me forever to find out why this was happening as I couldn't replicate it with the showcase code... or the test project i built specifically for figuring this out. In the end I was removing one component at a time until it started working.
> The cause of the issue is found in the jboss-web.xml file. For years, I have ran apache in front of my jboss installations. I would specify root context to / and map the domain straight to it using a virtual host in the jboss server config file (regardless of the version). AJP in front and away you go. a4j:push will crash if this context is mapped to / instead of /foo.
> I'm going to attempt to attach the sample project to recreate this with. Map the alias from jboss-web.xml to a virtual server in your standalone.xml file and start it up. navigate to the consumer link at the top of the app. turn on your developer tools and wait for the chaos. at the five minute mark you are going to see death and destruction.
--
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
10 years, 9 months
[JBoss JIRA] (RF-12225) rich:tabPanel first tab issue
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-12225?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak resolved RF-12225.
--------------------------------
Resolution: Out of Date
I cannot reproduce the issue with neither 4.3.2.Final nor 5.0.0-SNAPSHOT. Closing.
> rich:tabPanel first tab issue
> -----------------------------
>
> Key: RF-12225
> URL: https://issues.jboss.org/browse/RF-12225
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.1.Final
> Environment: Tomcat 7, JSF 2.2, RF 4.2.1.FINAL
> Reporter: Philip Maes
> Assignee: Pavol Pitonak
> Fix For: 5-Tracking
>
>
> Hello,
> there is a weird behavior with rich:tabPanel. And the bug (for me it's a bug) is present in your showcase.
> When you first load a page that contains a tabPanel, the first tab has a nested js script for the toggle. The problem is that this js script is also present at its normal position (after tab declaration). And it causes that when you click on this tab, 2 ajax requests are sent. But only once. After, the nested js script isn't present anymore.
> {code:title=|borderStyle=solid}
> <div id="j_idt2821:j_idt2827" class="rf-tab">
> <div id="j_idt2821:j_idt2827:content" class="rf-tab-cnt"> Here is tab #1 </div>
> <!-- anormal js script -->
> <script type="text/javascript">
> new RichFaces.ui.Tab("j_idt2821:j_idt2827", "index":0,"leave":null,"togglePanelId":"j_idt2821:tp","switchMode":"ajax","name":"j_idt2827","enter":null,"disabled":false} )
> </script>
> </div>
> <div id="j_idt2821:j_idt2829" style="display:none;"></div>
> <div id="j_idt2821:j_idt2831" style="display:none;"></div>
> <!-- normal place -->
> <script type="text/javascript">
> new RichFaces.ui.Tab("j_idt2821:j_idt2827",{"index":0,"leave":null,"togglePanelId":"j_idt2821:tp","switchMode":"ajax","name":"j_idt2827","enter":null,"disabled":false} )
> </script>
> {code}
> Steps to reproduce it:
> -go to: http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=tabPane...
> -open a js console (for me it's firebug, console tab) to see ajax requests;
> -use html inspector to check that in the body of tab "First" you have the js script;
> -click on tab named "Second";
> -then click on tab named "First" and there are 2 ajax requests sent;
> -now reclick on another tab;
> -then click on tab named "First" and there is only 1 ajax request sent;
> -recheck the content of the tab and you can see that the js script isn't present anymore.
--
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
10 years, 9 months
[JBoss JIRA] (RF-13109) a4j:push transaction flood
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/RF-13109?page=com.atlassian.jira.plugin.s... ]
nathan dennis updated RF-13109:
-------------------------------
Attachment: a4jPushFlood.tar.gz
map the virtual server in standalone.xml to the alias found in the jboss-web.xml. update host file if needed.
> a4j:push transaction flood
> ---------------------------
>
> Key: RF-13109
> URL: https://issues.jboss.org/browse/RF-13109
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.2.2.Final, 4.2.3.Final, 4.3.1
> Environment: CHROME,Jboss 7.1.1.Final, Jboss 7.1.3.Final, CentoOS6.X, Windows 7
> Reporter: nathan dennis
> Labels: a4j:push, richfaces
> Attachments: a4jPushFlood.tar.gz
>
>
> long poll doesnt refresh at the 30 second mark. After 5 minutes, Chrome goes into meltdown, sending a transaction back to the server approx. ever 8 ms causing DOS and browser lock after about 3 seconds.
> Firefox on the other hand returns a cancelled transaction, exits abnormally, and goes back to behaving as expected with the appearance that it is working correctly.
> This took me forever to find out why this was happening as I couldn't replicate it with the showcase code... or the test project i built specifically for figuring this out. In the end I was removing one component at a time until it started working.
> The cause of the issue is found in the jboss-web.xml file. For years, I have ran apache in front of my jboss installations. I would specify root context to / and map the domain straight to it using a virtual host in the jboss server config file (regardless of the version). AJP in front and away you go. a4j:push will crash if this context is mapped to / instead of /foo.
> I'm going to attempt to attach the sample project to recreate this with. Map the alias from jboss-web.xml to a virtual server in your standalone.xml file and start it up. navigate to the consumer link at the top of the app. turn on your developer tools and wait for the chaos. at the five minute mark you are going to see death and destruction.
--
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
10 years, 9 months
[JBoss JIRA] (RF-13109) a4j:push transaction flood
by nathan dennis (JIRA)
nathan dennis created RF-13109:
----------------------------------
Summary: a4j:push transaction flood
Key: RF-13109
URL: https://issues.jboss.org/browse/RF-13109
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: component-a4j-core
Affects Versions: 4.3.1, 4.2.3.Final, 4.2.2.Final
Environment: CHROME,Jboss 7.1.1.Final, Jboss 7.1.3.Final, CentoOS6.X, Windows 7
Reporter: nathan dennis
long poll doesnt refresh at the 30 second mark. After 5 minutes, Chrome goes into meltdown, sending a transaction back to the server approx. ever 8 ms causing DOS and browser lock after about 3 seconds.
Firefox on the other hand returns a cancelled transaction, exits abnormally, and goes back to behaving as expected with the appearance that it is working correctly.
This took me forever to find out why this was happening as I couldn't replicate it with the showcase code... or the test project i built specifically for figuring this out. In the end I was removing one component at a time until it started working.
The cause of the issue is found in the jboss-web.xml file. For years, I have ran apache in front of my jboss installations. I would specify root context to / and map the domain straight to it using a virtual host in the jboss server config file (regardless of the version). AJP in front and away you go. a4j:push will crash if this context is mapped to / instead of /foo.
I'm going to attempt to attach the sample project to recreate this with. Map the alias from jboss-web.xml to a virtual server in your standalone.xml file and start it up. navigate to the consumer link at the top of the app. turn on your developer tools and wait for the chaos. at the five minute mark you are going to see death and destruction.
--
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
10 years, 9 months
[JBoss JIRA] (RF-11021) rich:select should show first item in list if defaultLabel is not set
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-11021?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-11021:
----------------------------
Fix Version/s: 4.5.0.Alpha1
(was: 5.0.0.Alpha2)
> rich:select should show first item in list if defaultLabel is not set
> ---------------------------------------------------------------------
>
> Key: RF-11021
> URL: https://issues.jboss.org/browse/RF-11021
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.0.0.Final
> Environment: GAE, Win7-64
> Reporter: Ara Minosian
> Labels: richfaces
> Fix For: 4.5.0.Alpha1
>
>
> This code does not display first value. Id displays emty item.
> {code:xml}
> <rich:select id="unitSelect" value="#{editBean.paramEditor1.unitKeyWithRange}" selectFirst="true">
> <f:selectItems value="#{editBean.paramEditor1.availableUnits}"/>
> </rich:select>
> {code}
> This code dispays first value
> {code:xml}
> <h:selectOneMenu id="unitSelect" value="#{editBean.paramEditor1.unitKeyWithRange}">
> <f:selectItems value="#{editBean.paramEditor1.availableUnits}"/>
> </h:selectOneMenu>
> {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
10 years, 9 months