November 2011 - richfaces-issues - Jboss List Archives

[JBoss JIRA] Created: (RF-8210) switchType=ajax on modalPanel

by Gonzalez Adrian (JIRA)

switchType=ajax on modalPanel ----------------------------- Key: RF-8210 URL: https://jira.jboss.org/jira/browse/RF-8210 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gonzalez Adrian Lately, I'm mostly (80% of times) rendering my rich:modalPanels in ajax mode [1] : - a4j:commandButton calls a backing bean method, and rerenders the a4j:outputPanel surrounding rich;modalPanel. oncomplete js handler call Richfaces.showPanel. - the rich:modalPanel is inside a a4j:outputPanel nd its rendered attribute points to a backing bean property. This is because each modalPanels weights more or less 5 ko (I've seen 4 different application and it was always at least 5 ko). This code is repetitive. Could it be possible to add a switchType (or mode) attribute on rich:calendar, the meaning of which would be : 1. if switchType=client, behaviour unchanged. 2. if switchType=ajax, Richfaces.showModal would make an ajax call, rerender the rich:modalPanel (so rich:modalPanel would always be contained in an invisible <span> or shting like this) and show 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

4
5
0 / 0

[JBoss JIRA] Created: (RF-11392) rich:collapsibleSubTable - can't scroll in Mojarra

by Jan Papousek (JIRA)

rich:collapsibleSubTable - can't scroll in Mojarra -------------------------------------------------- Key: RF-11392 URL: https://issues.jboss.org/browse/RF-11392 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tables Affects Versions: 4.1.0.Milestone2 Environment: RichFaces 4.1.0.20110910-M2 r.0d4276b62c8366e0eaa1b7cd1c350d373e65ed79 Metamer 4.1.0.20110910-M2 r.22701 Mojarra 2.1.2-FCS Apache Tomcat 7.0.16 OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30 RichFaces 4.1.0.20110910-M2 r.0d4276b62c8366e0eaa1b7cd1c350d373e65ed79 Metamer 4.1.0.20110910-M2 r.22701 Mojarra 2.1.2-FCS Apache Tomcat 7.0.16 OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 Reporter: Jan Papousek Open Metamer page in */faces/components/richCollapsibleSubTable/scroller.xhtml*: *The First Problem* - User can't move to the page 3 using the button *»*. - Number buttons work properly. *The Second Problem* - Move in the *Men* section to the second page - Move in the *Women* section to the second page. - The first page in the section *Men* is displayed (wrong). ---- Using MyFaces everything is OK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
4
0 / 0

[JBoss JIRA] Created: (RF-9324) a4j:queue event handlers doesn't work at all

by Lukas Fryc (JIRA)

a4j:queue event handlers doesn't work at all -------------------------------------------- Key: RF-9324 URL: https://jira.jboss.org/browse/RF-9324 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-a4j-core Affects Versions: 4.0.0.Milestone2 Environment: Java(TM) SE Runtime Environment 1.6.0_20-b02 Linux 2.6.31-22-generic Mojarra 2.0.2-FCS Firefox 3.6.3 Apache Tomcat 6.0.26 core-demo : M2 https://repository.jboss.org/nexus/content/groups/public/org/richfaces/ex... http://localhost:8080/core-demo/queue.jsf Reporter: Lukas Fryc I modified queue.html sample to look like this: <a4j:queue requestDelay="500" oncomplete="alert('1')" /> <h:form> <h:commandLink value="Common link"> <a4j:ajax /> </h:commandLink> </h:form> It seems queue is working, because it handlers multiple events and triggers only one request, but alert is not shown on completion. The same for other event handlers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

6
14
0 / 0

[JBoss JIRA] (RF-11560) Showcase on OpenShift Express: Push stops to work after first long-polling request

by Lukáš Fryč (Created) (JIRA)

Showcase on OpenShift Express: Push stops to work after first long-polling request ---------------------------------------------------------------------------------- Key: RF-11560 URL: https://issues.jboss.org/browse/RF-11560 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.1.0.Milestone3 Reporter: Lukáš Fryč Assignee: Lukáš Fryč Priority: Critical Fix For: 4.1.0.Milestone4 Both demos affected: TopicsContext and Push CDI. -- 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

14 years

8
10
0 / 0

[JBoss JIRA] Created: (RF-10782) Input components: add attribute "width"

by Gleb Galkin (JIRA)

Input components: add attribute "width" --------------------------------------- Key: RF-10782 URL: https://issues.jboss.org/browse/RF-10782 Project: RichFaces Issue Type: Task Security Level: Public (Everyone can see) Components: component, component-input Affects Versions: 4.0.0.Final Reporter: Gleb Galkin Fix For: 4.Future For input components we can define width using attribute style. For more description see the linked issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
1
0 / 0

[JBoss JIRA] Created: (RF-6026) PickList doesn't accept comma in string value of SelectItem

by Andrzej Haczewski (JIRA)

PickList doesn't accept comma in string value of SelectItem ----------------------------------------------------------- Key: RF-6026 URL: https://jira.jboss.org/jira/browse/RF-6026 Project: RichFaces Issue Type: Bug Affects Versions: 3.3.0 Environment: WebLogic 10, JSF 1.2, RichFaces 3.3.0, Hibernate JPA, Facelets 1.1.14 Reporter: Andrzej Haczewski When you use a List<SelectItem> where SelectItems are created like this: new SelectItem("SOME STRING,CONTAINING COMMA", "A nice string to show in list") as a PickList <h:selectItems>, and use List<String> as PickList value, then PickList doesn't validate when you add that item to target list. The reason is that UISelectMany is trying to validate values "SOME STRINGS" and "CONTAINING COMMA" with available items. The exact point is the UISelectMany.matchValue() method, which returns false on validation of that PickList. Sample code: --- BackingBean.java class BackingBean { private List<SelectItem> picklistItems; private List<String> result; public BackingBean() { picklistItems = new ArrayList<SelectItem>(); picklistItems.add(new SelectItem("SAMPLE,EXAMPLE", "Sample example")); } // then comes getters and setters for picklistItems and result } --- PickList.xhtml <rich:pickList value="#{backingBean.result}"> <h:selectItems value="#{backingBean.picklistItems}"> </rich:pickList> -- 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

4
8
0 / 0

[JBoss JIRA] Created: (RF-7351) Regression: "messages: globalOnly does not work properly"

by Joseph Miller (JIRA)

Regression: "messages: globalOnly does not work properly" --------------------------------------------------------- Key: RF-7351 URL: https://jira.jboss.org/jira/browse/RF-7351 Project: RichFaces Issue Type: Bug Components: component, regression Affects Versions: 3.3.1 Environment: Windows / JBoss 4.2.2.GA / Seam 2.1.1.GA / RichFaces 3.3.1.GA Reporter: Joseph Miller Looks like a regression of RF-615... I've upgraded my Seam project to sue RF 3.3.1, in order to fix a number of other bugs, but now messages intended for a single UI component (via the for= ) are appearing in the global messages list at the top of my page. My page template has: <rich:messages globalOnly="true" id="page-messages"> ... </rich:messages> and the controls have: <rich:message for="my-control-id" id="my-control-id-message"> ... </rich:message> I can switch the rich:messages to h:messages, and it behaves as it should. Also reverting back to the RichFaces 3.2.2.SR1 jars makes the problem go away, but I get the other older bugs back :( -- 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

19
67
0 / 0

[JBoss JIRA] Created: (RF-11339) selection hangs in extendedDataTable when there are more than one table in the view

by Morten Ludvigsen (JIRA)

selection hangs in extendedDataTable when there are more than one table in the view ----------------------------------------------------------------------------------- Key: RF-11339 URL: https://issues.jboss.org/browse/RF-11339 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tables Affects Versions: 4.0.0.Final Environment: GlassFish 3.1, and Chrome 13 Reporter: Morten Ludvigsen I have a problem with selection in extendedDataTables when there are two tables in the view. Some of the selections are not removed when a new row is selected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
8
0 / 0

[JBoss JIRA] (RF-11592) RichFaces 4.1 Milestone changes for fileUpload component incompatible with Apache MyFaces Orchestra conversation scope

by Joshua Brookes (Created) (JIRA)

RichFaces 4.1 Milestone changes for fileUpload component incompatible with Apache MyFaces Orchestra conversation scope ---------------------------------------------------------------------------------------------------------------------- Key: RF-11592 URL: https://issues.jboss.org/browse/RF-11592 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.1.0.Milestone2, 4.1.0.Milestone1, 4.1.0.Milestone3 Environment: Mojarra 2.1.3, JBoss AS 5.0.1, Apache MyFaces Orchestra 1.4, Spring 3.0.4 Reporter: Joshua Brookes Attachments: fileUploadWeb.zip There is a compatibility issue with recent changes in RichFaces 4.1 Milestone 1 and Apache MyFaces Orchestra conversation scope feature. When adding the org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener listener in web.xml the fileUpload component stops working. This did not pose a problem with RichFaces 4.0.0.Final. Here is a stacktrace that shows the error: {code} Oct 25, 2011 11:45:01 AM org.richfaces.request.MultipartRequest25 parseIfNecessary SEVERE: Exception parsing multipart request: Request prolog cannot be read org.richfaces.exception.FileUploadException: Exception parsing multipart request: Request prolog cannot be read at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1280) at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.containsRequestParameterAttribute(JsfFrameworkAdapter.java:105) at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:169) at org.apache.myfaces.orchestra.conversation.ConversationManager.getCurrentRootConversationContext(ConversationManager.java:580) at org.apache.myfaces.orchestra.lib.jsf.ContextLockRequestHandler.init(ContextLockRequestHandler.java:87) at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory$1.<init>(OrchestraFacesContextFactory.java:122) at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:103) at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.java:93) at org.richfaces.context.FileUploadFacesContextFactory.getFacesContext(FileUploadFacesContextFactory.java:136) at com.sun.faces.context.InjectionFacesContextFactory.getFacesContext(InjectionFacesContextFactory.java:121) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:583) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:638) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:446) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:382) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:310) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:416) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:286) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Request prolog cannot be read at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) ... 32 more {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

14 years

5
12
0 / 0

[JBoss JIRA] Created: (RF-9345) Richfaces HTTP Header Cache-Control settings, need 'public'

by igor regis (JIRA)

Richfaces HTTP Header Cache-Control settings, need 'public' ----------------------------------------------------------- Key: RF-9345 URL: https://jira.jboss.org/browse/RF-9345 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: performance Affects Versions: 3.3.3.Final, 3.3.3.CR1, 3.3.3.BETA1, 3.3.2.SR1, 3.3.2.GA, 3.3.2.CR1, 3.3.1 Environment: This issue affect any web browser according to w3c specification Reporter: igor regis If an application is running over https the web browser will only cache on disk, the Richfaces resources, if and only if, the Cache-control header (present on http header) has the value "public" on it. Otherwise the web browser will perform in memory cache, so when user restarts the browser the application will need to request all the resources again. For applications running on corporative network, manipulating sensitive information, it's mandatory the use of a secure connection through https protocol, and form better performance is necessary for Richfaces to provide it's resources with this "public" mark on cache-control tag. According the w3c specs (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1) Richfaces resources may be classified as public content with non individual information. Here (https://community.jboss.org/thread/150732?tstart=0) there is a discussion about this issue, as well as the point on Richfaces source code that need to be changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

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