December 2009 - richfaces-issues - Jboss List Archives

[JBoss JIRA] Created: (RF-8200) ComboBox: It is not possible to select current selection again after clearing the input field

by Andreas Schank (JIRA)

ComboBox: It is not possible to select current selection again after clearing the input field --------------------------------------------------------------------------------------------- Key: RF-8200 URL: https://jira.jboss.org/jira/browse/RF-8200 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 3.3.2.CR1 Reporter: Andreas Schank This can be reproduced on the live demo: http://livedemo.exadel.com/richfaces-demo/richfaces/comboBox.jsf After selecting a suggestion in the combobox you cannot reselect the combobox after changing the input field. E.g. select "suggestion 3", then clear some or all characters in the field and try to select "suggestion 3" again. Nothing will happen. You will first have to select another entry and then select "suggestion 3" again to make it work. This workaround will not be sufficient for cases where only one entry is present in the suggestion list and so it will be impossible to make the selection again. I would expect that after changing the input field the selection would be reset and "suggestion 3" be inserted again when selected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

4
4
0 / 0

[JBoss JIRA] Created: (RF-7977) RF demo - ftest - TooltipDataTableTestCase - class for table's header changed

by Lukas Fryc (JIRA)

RF demo - ftest - TooltipDataTableTestCase - class for table's header changed ----------------------------------------------------------------------------- Key: RF-7977 URL: https://jira.jboss.org/jira/browse/RF-7977 Project: RichFaces Issue Type: Bug Components: QA-environment, functional-tests Affects Versions: 3.3.2.GA Environment: RF 3.3.2.SR1 Reporter: Lukas Fryc Assignee: Lukas Fryc Priority: Minor Fix For: 3.3.3.CR1 There was @class='rich-table', but it was extended by white-space to @class='rich-table '. Change xpath in ftest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (RF-8189) Move repository.exadel.com from .m2/settings to profiles.jboss-qa.xml

by Lukas Fryc (JIRA)

Move repository.exadel.com from .m2/settings to profiles.jboss-qa.xml --------------------------------------------------------------------- Key: RF-8189 URL: https://jira.jboss.org/jira/browse/RF-8189 Project: RichFaces Issue Type: Task Security Level: Public (Everyone can see) Components: QA-environment Reporter: Lukas Fryc Assignee: Lukas Fryc Priority: Minor Exadel repository shoudn't be in global settings for hudson, but it will be placed in profiles.jboss-qa.xml in hudson. Modify the hudson .m2/settings.xml and profiles.jboss-qa.xml accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (RF-7976) RF demo - ftest - ExtendedDataTable - 'rich-table' class was removed

by Lukas Fryc (JIRA)

RF demo - ftest - ExtendedDataTable - 'rich-table' class was removed -------------------------------------------------------------------- Key: RF-7976 URL: https://jira.jboss.org/jira/browse/RF-7976 Project: RichFaces Issue Type: Bug Components: QA-environment, functional-tests Affects Versions: 3.3.2.GA Reporter: Lukas Fryc Assignee: Lukas Fryc Fix For: 3.3.3.CR1 Xpathes needs to be modified since 'rich-table' class was removed from extdt structure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (RF-7970) Richfaces-demo functional test - CalendarTestCase - The name of the month is not localized

by Lukas Fryc (JIRA)

Richfaces-demo functional test - CalendarTestCase - The name of the month is not localized ------------------------------------------------------------------------------------------ Key: RF-7970 URL: https://jira.jboss.org/jira/browse/RF-7970 Project: RichFaces Issue Type: Bug Components: functional-tests Affects Versions: 3.3.2.GA Environment: richfaces-demo-3.3.2-20090930.204720-132.war JBoss 5.1.0.GA Reporter: Lukas Fryc Assignee: Lukas Fryc Fix For: 3.3.2.SP1 The calendar uses bad check of Calendar's german localization - it works in September (for de and en same), but not in October (for de it's Oktober) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (RF-8107) Development: extended dataTable "no data" facet support

by Anton Belevich (JIRA)

Development: extended dataTable "no data" facet support ------------------------------------------------------- Key: RF-8107 URL: https://jira.jboss.org/jira/browse/RF-8107 Project: RichFaces Issue Type: Sub-task Reporter: Anton Belevich Assignee: Konstantin Mishin Fix For: 4.0.0.ALPHA2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (RF-4415) Application does not work in Weblogic 10gR3

by Cesar Perez (JIRA)

Application does not work in Weblogic 10gR3 ------------------------------------------- Key: RF-4415 URL: https://jira.jboss.org/jira/browse/RF-4415 Project: RichFaces Issue Type: Bug Affects Versions: 3.2.1, 3.2.2 Environment: Windows XP SP3, Oracle Weblogic 10g R3, JSF 1.2, Richfaces 3.2.1 and 3.2.2 and probably older version. Reporter: Cesar Perez If I use RichFaces 3.2.1 and even 3.2.2CR3 with JSP as my view handler I cannot open a JSP page, even if it doesn't contains any RF tags. This happens on Weblogic 10 and the latest 10g R3. In Tomcat the code works just fine without any issues. I created an example eclipse project that shows this issue under Weblogic 10g R3. It contains a configuration to use either JSP or Facelets for the view. If you open the .xhtml file the page will be displayed just fine but if you try to open the JSP an exception is thrown. In Weblogic I created a new domain with all the default options and I am deploying the application through Eclipse but I have also tried deploying a WAR/EAR getting the same exception when I try to access the JSP. Also you can remove all the facelets configuration and just leave JSP to handle the view, the exception will be thrown too. The only possible fix I have found is to use facelets instead of JSP but in the project I am working on that's just not possible. The example project is here: http://rs420l3.rapidshare.com/cgi-bin/upload.cgi?rsuploadid=3180178713302... The stacktrace is: java.lang.IllegalStateException: Servlet response already use stream, Writer not possible at org.ajax4jsf.webapp.FilterServletResponseWrapper.getWriter(FilterServletResponseWrapper.java:226) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:186) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:547) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:547) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:547) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:266) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:159) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:503) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:251) at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:159) at jsp_servlet.__index._jspService(__index.java:72) at weblogic.servlet.jsp.JspBase.service(JspBase.java:34) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:408) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:318) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

8
23
0 / 0

[JBoss JIRA] Created: (RF-6437) IE8 standards mode, rich:modalPanel cannot be closed

by Andrew May (JIRA)

IE8 standards mode, rich:modalPanel cannot be closed ---------------------------------------------------- Key: RF-6437 URL: https://jira.jboss.org/jira/browse/RF-6437 Project: RichFaces Issue Type: Bug Affects Versions: 3.3.0, 3.2.2 Environment: Windows XP, Internet Explorer 8 RC1 (tested using VirtualPC VM provided by Microsoft) Reporter: Andrew May A JavaScript error is thrown when trying to close a modal panel when using IE8RC1 in standards mode. With 3.3.0GA (as currently in use by the live demo), the error is at ui.pack.js.jsf at line 903 character 30: if(G.style.removeExpression){G.style.removeExpression("width"); In IE8 standards mode support for expressions has been removed: http://blogs.msdn.com/ie/archive/2008/10/16/ending-expressions.aspx. The check for G.style.removeExpression returns true, but the call to the method throws a "Not Implemented" error. This may be a bug in IE8, but it's unlikely to be fixed before it is released, and I've been unable to submit a bug at the https://connect.microsoft.com/IE/Feedback site. Therefore it may be necessary to work around it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

7
12
0 / 0

[JBoss JIRA] Created: (RF-8222) wrong information about scripts strategies and compression.

by Ilya Shaikovsky (JIRA)

wrong information about scripts strategies and compression. ----------------------------------------------------------- Key: RF-8222 URL: https://jira.jboss.org/jira/browse/RF-8222 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: doc Affects Versions: 3.3.2.SR1 Reporter: Ilya Shaikovsky Assignee: Nick Belaevski Priority: Critical Fix For: 3.3.3.CR1 Nick, not sure why this issue originally was risen https://jira.jboss.org/jira/browse/RF-2117 but if fix is even worse than previous state was :) Currently NOTE looks like: If you use ALLvalue of Scripts Load Strategy, the JavaScript files compression turns off! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (RF-8215) <f:actionParam> is invoked on INVOKE_APPLICATION phase rather than UPDATE_MODEL_VALUES phase when used inside a jsFunction

by George Gastaldi (JIRA)

<f:actionParam> is invoked on INVOKE_APPLICATION phase rather than UPDATE_MODEL_VALUES phase when used inside a jsFunction -------------------------------------------------------------------------------------------------------------------------- Key: RF-8215 URL: https://jira.jboss.org/jira/browse/RF-8215 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-a4j-core Affects Versions: 3.3.2.SR1 Reporter: George Gastaldi The documentation in http://livedemo.exadel.com/richfaces-demo/richfaces/actionparam.jsf?c=act... and http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html/a4j_actionp... states that the property assigned in the "assignTo" attribute is set in the UPDATE_MODEL_VALUES phase. By using a jsFunction with an actionParam, it is possible to see that the assignment is done on the INVOKE_APPLICATION phase, thus calling the actionListener defined in the jsFunction Example: <a4j:jsFunction name="myJsFunction" actionListener="#{myBean.myActionListener}" > <a4j:actionparam name="param1"assignTo="#{myBean.paramName}" /> </a4j:jsFunction> Calling: myJsFunction('Any Value') does the trick. The ActionListener will be called AFTER the assignment of the actionParam -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues December 2009