July 2012 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-12370) Push: Add configuration option for max session's inactive interval

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12370: ------------------------------- Summary: Push: Add configuration option for max session's inactive interval Key: RF-12370 URL: https://issues.jboss.org/browse/RF-12370 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: core Affects Versions: 4.2.2.Final Reporter: Lukáš Fryč Assignee: Lukáš Fryč When investigating RF-12219, I have found, the sessions aren't destroyed when client disconnects properly ({{$_atmosphere.unsubscribe()}} on {{window.unload}}). We should allow to configure maximum time before the Session gets destroyed automatically. {code:xml} <context-param> <param-name>org.richfaces.push.session.maxInactiveInterval</param-name>  <param-value>300000</param-value> </context-param> {code} Further investigations in scope of RF-12219 are needed. -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] (RF-12347) popupPanel shrinks while moving on zoomed page

by Dun Pierrafeu (JIRA)

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] (RF-12374) Example values for CSV and server-side conversion messages differs on MyFaces

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12374: ------------------------------- Summary: Example values for CSV and server-side conversion messages differs on MyFaces Key: RF-12374 URL: https://issues.jboss.org/browse/RF-12374 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-validators Affects Versions: 4.2.2.Final Reporter: Lukáš Fryč Priority: Minor CSV uses hard-coded values for conversion messages: https://github.com/richfaces/components/blob/develop/validator/ui/src/mai... However those are taken from JSF RI (Mojarra) and MyFaces provides slightly different values. Basically all conversion messages then provide different values when input validated by CSV and when validated by JSF. ---- To fix this issue, we would need to retrieve those example messages and render them to {{richfaces-csv.js}}. -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] (RF-12373) CSV: messages for long range validation inconsistent on client and server with MyFaces

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12373: ------------------------------- Summary: CSV: messages for long range validation inconsistent on client and server with MyFaces Key: RF-12373 URL: https://issues.jboss.org/browse/RF-12373 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-validators Affects Versions: 4.2.2.Final Reporter: Lukáš Fryč Priority: Minor The {{LongRangeValidatorTest}} test case is broken, 3 tests fails: {code} org.junit.ComparisonFailure: expected:<[testComponent: Validation Error: Value is less than allowable minimum of '2']> but was:<[: Validation Error: Specified attribute is not between the expected values of 2 and testComponent.]> at org.junit.Assert.assertEquals(Assert.java:123) at org.junit.Assert.assertEquals(Assert.java:145) at org.richfaces.javascript.client.validator.ValidatorTestBase.testValidator(ValidatorTestBase.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.jboss.test.qunit.Qunit$1.evaluate(Qunit.java:139) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) {code} -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] (RF-12368) rich:hotKey not working in 4.2.2

by Ulf Liller (JIRA)

Ulf Liller created RF-12368: ------------------------------- Summary: rich:hotKey not working in 4.2.2 Key: RF-12368 URL: https://issues.jboss.org/browse/RF-12368 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2.2.Final Environment: JSF 2.1, RichFaces 4.2.2 Reporter: Ulf Liller Attachments: FacesTest.zip I am trying to catch backspace key presses to prevent the browser from processing them and doing history.back() which screws up our site's navigation. The following works fine with JSF 1.2 and RichFaces 3.3.3: {code:xml} <rich:hotKey key="backspace" handler="return false;" disableInInput="true"/> {code} However we are trying to upgrade to RichFaces 4 and with that version it ceases to work. I will attach a sample (my)Eclipse project. I have tested it with JSF 1.2 (mojarra 1.2.15) and RichFaces 3.3.3 (which works) and JSF 2.1 (mojarra 2.1.11) and RichFaces 4.2.2 (which doesn't). As a workaround I found out that calling jQuery directly and disabling the hotkey there is fine in both versions. -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] (RF-12366) Uploading 2 files despite rich:fileUpload:maxFilesQuantity="1"

by Artur Mioduszewski (JIRA)

Artur Mioduszewski created RF-12366: --------------------------------------- Summary: Uploading 2 files despite rich:fileUpload:maxFilesQuantity="1" Key: RF-12366 URL: https://issues.jboss.org/browse/RF-12366 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.2.2.Final Environment: JDK1.6, JBoss 6.0.Final richfaces 4.2.2.Final seam 3.1 Chrome Reporter: Artur Mioduszewski Button 'Add' does not disable after starting file uploading. In case: maxFilesQuantity="1" in rich:fileUpload I am able to upload more than 1 file using below scenario: I start to upload large file lala.wmv. During uploading of lala.wmv file, button "Add" is not blocked, so I am able to select second file to upload. Finally 2 files are uploaded despite maxFilesQuantity="1". -- 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, 6 months

2
1
0 / 0

[JBoss JIRA] (RF-12352) rich:fileUpload does not work properly with Mojarra 2.1.7 when FacesContext.isPostback() is executed before FacesContext.getPartialViewContext()

by Tomasz Kurpios (JIRA)

Tomasz Kurpios created RF-12352: ----------------------------------- Summary: rich:fileUpload does not work properly with Mojarra 2.1.7 when FacesContext.isPostback() is executed before FacesContext.getPartialViewContext() Key: RF-12352 URL: https://issues.jboss.org/browse/RF-12352 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.0.0.Final Environment: Mojarra 2.1.7, Jetty or JBoss 5.1 Reporter: Tomasz Kurpios In Mojarra 2.1.7 the value of first invocation of FacesContextImpl.isPostback() is cached as a request attribute. It checks for the existence of javax.faces.ViewState parameter. If we are processing MultipartRequest and FacesContextImpl.isPostback() is executed before FacesContextImpl.getPartialViewContext(), FileUploadPartialViewContextFactory hasn't had yet chance to parse this MultipartRequest's parameters, so FacesContextImpl.isPostback() returns (and caches) false. Therefore no processing (decodes, validations, updates) happens and as a consequence properly registered FileUploadListener is not executed. The only reason why it normally works is because completely unrelated method, com.sun.faces.context.ExceptionHandlerFactoryImpl.getExceptionHandler(), *happens to* call FacesContext.getPartialViewContext() and this happens during creation of FacesContext instance. In my environment, I used my custom ExceptionHandlerFactory (registered in faces-config.xml) which did not call FacesContext.getPartialViewContext() and the problem appeared, because FacesContext.isPostback() was called first. This means that currently FileUploadPartialViewContextFactory is very tightly coupled to FacesContextImpl, which in my opinion should be fixed. -- 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, 6 months

2
1
0 / 0

[JBoss JIRA] (RF-11976) Showcase: BaseDescriptor is using com.sun.faces.ELUtils

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-11976: ------------------------------- Summary: Showcase: BaseDescriptor is using com.sun.faces.ELUtils Key: RF-11976 URL: https://issues.jboss.org/browse/RF-11976 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.2.0.CR1 Reporter: Lukáš Fryč Priority: Minor ELUtils are not on the classpath, when using MyFaces. {{com.sun.faces.el.ELUtils}} should be replaced with {{org.richfaces.el.util.ELUtils}}. -- 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, 6 months

4
7
0 / 0

[JBoss JIRA] (RF-12333) "oncomplete" (seems like along with "onbeforedomupdate", "data") doesn't work when "@all" keyword specified in "render" attribute

by Alexander Kiselyov (JIRA)

12 years, 6 months

2
1
0 / 0

[JBoss JIRA] (RF-12329) Richfaces rendering fails on Arabic Windows Environment

by Nitesh S (JIRA)

12 years, 6 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues July 2012