November 2008 - richfaces-issues - Jboss List Archives

[JBoss JIRA] Created: (RF-1024) CDK: Should support config/validator and config/converter for configuration xml

by Pete Muir (JIRA)

CDK: Should support config/validator and config/converter for configuration xml ------------------------------------------------------------------------------- Key: RF-1024 URL: http://jira.jboss.com/jira/browse/RF-1024 Project: RichFaces Issue Type: Feature Request Affects Versions: 3.1.0 Reporter: Pete Muir Assigned To: Pete Muir Fix For: 3.1.2, 3.2.0 This makes sense as support for validators and converters is now in the CDK -- 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, 1 month

5
7
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

16 years, 2 months

8
23
0 / 0

[JBoss JIRA] Created: (RF-2490) Header facet in the rich:dataTable ignore column "rendered" attribute

by Alexander Smirnov (JIRA)

Header facet in the rich:dataTable ignore column "rendered" attribute --------------------------------------------------------------------- Key: RF-2490 URL: http://jira.jboss.com/jira/browse/RF-2490 Project: RichFaces Issue Type: Bug Environment: RichFaces 3.2 snapshot from 3/10. Reporter: Alexander Smirnov Assigned To: Alexander Smirnov Fix For: 3.2.0 The headers of data tables are no longer following the render rule of its parent h:column tag. The headers are rendering no matter what the rule is. The actual content is following the render rule. I noticed that if I wrap the whole h:column into an a4j:region tag and place the render rule there instead, it all renders correctly. However, I think it should work the way it was before right ?? The f:facet tag should comply to the render rule in the h:column tag ? Here's a code snippet....... <rich:dataTable ...> <h:column id="checkBoxCol" rendered="#{itemList_editableUser or itemList_subProfileView or itemList_DownloadableUser}"> <f:facet name="header"> <h:selectBooleanCheckbox styleClass="checkbox" immediate="true" id="headerCheckBox" onclick="toggleElementCheckboxes(this, this.checked)"/> </f:facet> <h:selectBooleanCheckbox value="#{item.selected}" title="#{item.object.itemIdentifier.gtin}" styleClass="checkbox" id="rowCheckBox" disabled="#{(itemList_subProfileView and itemList_subProfRestr) or item.acctAccess == 'N'}"/> </h:column> ........ </rich:dataTable> -- 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, 2 months

8
13
0 / 0

[JBoss JIRA] Created: (RF-4849) Dialog framework

by Nick Belaevski (JIRA)

Dialog framework ---------------- Key: RF-4849 URL: https://jira.jboss.org/jira/browse/RF-4849 Project: RichFaces Issue Type: Feature Request Affects Versions: Wishes Reporter: Nick Belaevski Fix For: Wishes http://myfaces.apache.org/trinidad/devguide/dialogs.html -- 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

16 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (RF-4128) They all should be Trees:Panel Menu, Context Menu, Drop Down

by Francisco Jose Peredo Noguez (JIRA)

They all should be Trees:Panel Menu, Context Menu, Drop Down ------------------------------------------------------------ Key: RF-4128 URL: https://jira.jboss.org/jira/browse/RF-4128 Project: RichFaces Issue Type: Feature Request Reporter: Francisco Jose Peredo Noguez I would like to be able to use recursiveTreeNodesAdaptor to configure Panel Menu, Context Menu, Drop Down Menu, after all, they all are recursive trees. They all should be Trees:Panel Menu, Context Menu, Drop Down Menu. Shouldn't they? Why not? AFAIK there is no easy way to make this possible right now -- 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

16 years, 2 months

4
10
0 / 0

[JBoss JIRA] Created: (RF-2516) Drag-n-Drop Tree with Context Menu

by Ralf Loechte (JIRA)

Drag-n-Drop Tree with Context Menu ---------------------------------- Key: RF-2516 URL: http://jira.jboss.com/jira/browse/RF-2516 Project: RichFaces Issue Type: Bug Affects Versions: 3.1.4, 3.2.0 Reporter: Ralf Loechte I have a rich:tree with drag-n-drop support and an attached rich:contextMenu to the nestet rich:treeNode. if you click left on a node, the contectMenu will open. After click on the <rich:treeNode type="member" dragType="member" dragValue="#{item}" acceptedTypes="member"> <h:outputText value="#{item.name}" /> <rich:dndParam name="label" type="drag" value="#{item.name}" /> <rich:contextMenu event="oncontextmenu" attached="true" submitMode="ajax"> <rich:menuItem value="Ausschneiden" limitToList="true" reRender="treehierarchypanel" disabled="#{!olapAdminMainBean.editMode}" actionListener="#{hierarchyMainBean.processCutElement}"> </rich:menuItem> -- 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, 3 months

6
13
0 / 0

[JBoss JIRA] Created: (RF-3552) rich:simpleTogglePanel strange behavior with a4j:repeat and rich:dataTable

by Pulkk Pulkk (JIRA)

rich:simpleTogglePanel strange behavior with a4j:repeat and rich:dataTable -------------------------------------------------------------------------- Key: RF-3552 URL: http://jira.jboss.com/jira/browse/RF-3552 Project: RichFaces Issue Type: Bug Affects Versions: 3.2.0, 3.1.2 Environment: Apache-Tomcat 6.0.18, Faces 1.2 Reporter: Pulkk Pulkk When using rich:simpleTogglePanel inside a looping tag such as a4j:repeat or rich:dataTable, the open/close behavior gets strange. For example: <a4j:repeat> <rich:simpleTogglePanel> ... </rich:simpleTogglePanel> </a4j:repeat> When working with the panels, the following happens depending on the switchType value: - Server: when one is opened or closed, all the rest open and close respectively - Client/Ajax: when one is opened or closed, the rest remain (the correct behavior). However, when the enclosing component is reRendered, they all open or close respectively depending on the last operation. It seems that when rich:simpleTogglePanel is put into a looping tag, all the resulting panels are treated as one in open/close operations. To illustrate: <a4j:repeat> <rich:simpleTogglePanel> ... </rich:simpleTogglePanel> <rich:simpleTogglePanel> ... </rich:simpleTogglePanel> </a4j:repeat> In this case, when opening or closing an odd-numbered panel in the output, all the odd-numbered panel open or close respectively but the even ones remain intact. Same goes for even ones. -- 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, 3 months

4
13
0 / 0

[JBoss JIRA] Created: (RF-3453) rich:modalPanel does not work with event listeners added using a4j:support

by Paul Speijers (JIRA)

rich:modalPanel does not work with event listeners added using a4j:support -------------------------------------------------------------------------- Key: RF-3453 URL: http://jira.jboss.com/jira/browse/RF-3453 Project: RichFaces Issue Type: Bug Affects Versions: 3.1.5, 3.1.x Reporter: Paul Speijers Fix For: 3.1.6, 3.1.x I wanted to perform some finalization work when I hide a modalPanel and an obvious solution would be to register an action to the onhide event using an a4j:support. However, the action is never executed and it seems like the event listener is not registered with the onhide event. <rich:modalPanel id="#{modalPanelId}" height="600" top="20" left="112" width="900" resizeable="false" moveable="true" onshow="focusFirstModalPanelElement('#{modalPanelId}')"> <a4j:support event="onhide" action="#{modalPanelDelegator.closePanel}" oncomplete="alert('test2')"/> ..... </rich:modalPanel> -- 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, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (RF-3305) Calendar: doExpand doesn't work with custom events

by Nick Belaevski (JIRA)

Calendar: doExpand doesn't work with custom events -------------------------------------------------- Key: RF-3305 URL: http://jira.jboss.com/jira/browse/RF-3305 Project: RichFaces Issue Type: Bug Affects Versions: 3.2.1 Reporter: Nick Belaevski Assigned To: Pavel Yaschenko Priority: Minor Fix For: 3.2.2 <rich:modalPanel id="modalPanelID"... <f:facet name="header"> <h:outputText value="Heder goes here..." /> </f:facet> <f:facet name="controls"> <h:graphicImage value="/pics/error.gif" onclick="Richfaces.hideModalPanel('modalPanelID');return false;" /> </f:facet> ... <rich:componentControl event="onshow" for="calendarID" operation="doExpand"></rich:componentControl> ... </rich:modalPanel> ... <rich:calendar id="calendarID"></rich:calendar> Step 1. Navigate to page contained modalPanel & calendar components. Step 2. Call modalPanel. Step 3. Verify calendar activity. Actual behavior: Calendar doesn't expand. -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (RF-4104) inputNumberSpinner: only input should get focus by Tab key

by Ilya Shaikovsky (JIRA)

inputNumberSpinner: only input should get focus by Tab key ---------------------------------------------------------- Key: RF-4104 URL: https://jira.jboss.org/jira/browse/RF-4104 Project: RichFaces Issue Type: Feature Request Affects Versions: 3.2.1 Reporter: Ilya Shaikovsky Assignee: Nick Belaevski Priority: Optional when you tabbing between inputs only input in spinner should get focus.. buttons should not be activated by tab. -- 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

16 years, 4 months

4
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues November 2008