December 2011 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-11817) rich:inputNumberSlider has no id=>so it is not testable

by Adrien Adrien (Created) (JIRA)

rich:inputNumberSlider has no id=>so it is not testable ------------------------------------------------------- Key: RF-11817 URL: https://issues.jboss.org/browse/RF-11817 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.1.0.Final Environment: Richfaces 4.1 final Reporter: Adrien Adrien The input of inputNumberSlider has no id, so it is not testable with jsfunit <input class="rf-insl-inp " name="j_idR-330616924_7a761f22" size="3" type="text" value="500"> -- 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

13 years, 2 months

3
2
0 / 0

[JBoss JIRA] (RF-11815) Showcase no longer displays the RichFaces version on the page

by Brian Leathem (Created) (JIRA)

Showcase no longer displays the RichFaces version on the page ------------------------------------------------------------- Key: RF-11815 URL: https://issues.jboss.org/browse/RF-11815 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.1.0.Final Reporter: Brian Leathem Assignee: Brian Leathem Priority: Trivial Fix For: 4.1.1.Final The showcase used to have the line along the bottom: {quote} RichFaces Core Implementation by JBoss, a division of Red Hat, Inc., version v.4.0.1-SNAPSHOT SVN r.unknown {quote} This has been lost in the latest release. It (or something similar) should be re-instated. -- 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

13 years, 2 months

3
3
0 / 0

[JBoss JIRA] (RF-11779) showcase and rich:togglePanel sample: bad position of 'View Source' link

by Jan Papousek (Created) (JIRA)

showcase and rich:togglePanel sample: bad position of 'View Source' link ------------------------------------------------------------------------ Key: RF-11779 URL: https://issues.jboss.org/browse/RF-11779 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.1.0.CR2 Environment: JBoss AS 7.1.0.Beta1 Firefox 8.0 Reporter: Jan Papousek Attachments: showcase-rich_tooglePanel.png -- 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

13 years, 2 months

4
4
0 / 0

[JBoss JIRA] (RF-11847) Upgrade to the latest jQuery

by Brian Leathem (Created) (JIRA)

Upgrade to the latest jQuery ---------------------------- Key: RF-11847 URL: https://issues.jboss.org/browse/RF-11847 Project: RichFaces Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: third-party Reporter: Brian Leathem Priority: Critical Fix For: 4.1.1.Final Let's upgrade to the latest version of jQuery. This is a minor version upgrade (1.6.x -> 1.7.x), so we should do it early in the development process to allow for sufficient testing. -- 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

13 years, 2 months

3
2
0 / 0

[JBoss JIRA] (RF-11809) NullPointerException on clearSkinCaches

by Fab Mars (Created) (JIRA)

NullPointerException on clearSkinCaches --------------------------------------- Key: RF-11809 URL: https://issues.jboss.org/browse/RF-11809 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.1.0.CR2 Environment: Win7 x86, Glassfish 3.1.2 promoted, JSK 1.6.0u29 Reporter: Fab Mars I have a homemade "pretty URL" mechanism I've been using on JSF1.2 and RF 3.3 in the past. It uses a phase listener that operates during RESTORE_VIEW. At the end of its parsing, it computes the "real" viewId to display and does: PrettyUrlRequestWrapper wrapper = new PrettyUrlRequestWrapper(request); wrapper.setViewId(computedViewId); context.getExternalContext().setRequest(wrapper); When I don't use it and call directly .jsf pages, all works fine with RF 4.1.0CR2. When I use it, I get this error: GRAVE: null javax.servlet.ServletException at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at org.richfaces.skin.SkinFactoryImpl.clearSkinCaches(SkinFactoryImpl.java:94) at org.richfaces.skin.SkinFactoryPreRenderViewListener.processEvent(SkinFactoryPreRenderViewListener.java:35) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2168) at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2144) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:302) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:246) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:670) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) ... 26 more ATTENTION: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception java.lang.NullPointerException at org.richfaces.skin.SkinFactoryImpl.clearSkinCaches(SkinFactoryImpl.java:94) at org.richfaces.skin.SkinFactoryPreRenderViewListener.processEvent(SkinFactoryPreRenderViewListener.java:35) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2168) at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2144) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:302) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:246) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:670) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) Well, clearSkinCackes uses only FacesContext. static void clearSkinCaches(FacesContext context) { context.getAttributes().remove(BASE_SKIN_KEY); context.getAttributes().remove(SKIN_KEY); } If you check on the debugger, FC is indeed null then. That's unexpected and I'm not sure this is normal. -- 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

13 years, 2 months

6
8
0 / 0

[JBoss JIRA] Created: (RF-9118) rich:jQuery - when onerror changed by partial refresh, it's definition is ignored for first error request

by Lukas Fryc (JIRA)

rich:jQuery - when onerror changed by partial refresh, it's definition is ignored for first error request --------------------------------------------------------------------------------------------------------- Key: RF-9118 URL: https://jira.jboss.org/browse/RF-9118 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-a4j-core Affects Versions: 4.0.0.Milestone1 Environment: Apache Tomcat 6.0.26 OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1~9.10.1) Metamer Application rev. 18834 ( https://svn.jboss.org/repos/richfaces/modules/tests/metamer/trunk/applica... ) Reporter: Lukas Fryc Steps to reproduce: 1. open http://localhost:8080/metamer/faces/components/a4jStatus/instantAttribute... 2. type in "alert('error1') into "onerror" input and hit Tab button (trigger change event) (the partial refresh will cause rerendering of the "commonGrid" component containing the "status") 3. hit "Send Ajax Requeswt Causing Error" button ERROR: no alert is triggered and status is stating "STOP" instead of "ERROR" 4. hit button again OK: alert is triggered stating "error1" and also status is stating "ERROR" This is at least unexpected behaviour and also doesn't match the principle what is used in case of other event listeners, especially "onsuccess". -- 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

13 years, 2 months

6
9
0 / 0

[JBoss JIRA] Created: (RF-11404) showcase - rich:messages - only one input is validated during validation, others after the previous one is correct

by Juraj Huska (JIRA)

showcase - rich:messages - only one input is validated during validation, others after the previous one is correct ------------------------------------------------------------------------------------------------------------------ Key: RF-11404 URL: https://issues.jboss.org/browse/RF-11404 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.1.0.Milestone2 Environment: application: richfaces-showcase-4.1.0.20110910-M2-jee6.war browsers: Chrome, FF container: JBoss 6.0.0.Final, JBoss 7.0.0.Final Reporter: Juraj Huska Only one input in the sample for rich:messages is validated when I click on the Ajax Validate button. When the value is corrected accordig to the error message than next input is validated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

7
15
0 / 0

[JBoss JIRA] Created: (RF-11405) showcase - rich:messages - validation does not work on Tomcats, warning is rendered

by Juraj Huska (JIRA)

showcase - rich:messages - validation does not work on Tomcats, warning is rendered ----------------------------------------------------------------------------------- Key: RF-11405 URL: https://issues.jboss.org/browse/RF-11405 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.1.0.Milestone2 Environment: application: richfaces-showcase-4.1.0.20110910-M2-jee6.war browsers: Chrome, FF containers: Tomcat 6.0.32, Tomcat 7.0.20 Reporter: Juraj Huska Validation in demo for rich:messages does not work. When I click on Ajax Validate no inputs are validated. Ajax request is thrown, but no validation messages are shown. In the place where validation messages should be, a warning is generated: The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within <h:form>. However when I inspect the code, it seems to be ok: {code:xml} <h:form> <rich:messages ajaxRendered="true" /> <h:panelGrid columns="2"> <h:outputText value="Name:" /> <h:inputText label="Name" id="name" required="true" value="#{userBean.name}"> <f:validateLength minimum="3" /> </h:inputText> <h:outputText value="Job:" /> <h:inputText label="Job" id="job" required="true" value="#{userBean.job}"> <f:validateLength minimum="3" maximum="50" /> </h:inputText> <h:outputText value="Address:" /> <h:inputText label="Address" id="address" required="true" value="#{userBean.address}"> <f:validateLength minimum="10" /> </h:inputText> <h:outputText value="Zip:" /> <h:inputText label="Zip" id="zip" required="true" value="#{userBean.zip}"> <f:validateLength minimum="4" maximum="9" /> </h:inputText> <f:facet name="footer"> <a4j:commandButton value="Ajax Validate" /> </f:facet> </h:panelGrid> </h:form> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

8
12
0 / 0

[JBoss JIRA] Created: (RF-11389) a4j:outputPanel + rich:popupPanel + ViewScope

by Jesper Vrelits (JIRA)

a4j:outputPanel + rich:popupPanel + ViewScope --------------------------------------------- Key: RF-11389 URL: https://issues.jboss.org/browse/RF-11389 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component Affects Versions: 4.0.0.Final Environment: Richfaces 4.0.0 Final + JSF Mojarra 2.1.x + Weblogic 10.3.4 Reporter: Jesper Vrelits When a rich:popupPanel is inside <a4j:outputPanel ajaxRendered="true"> and it is rerendered through ajax request and a4j:commandButton is called (from the popupPanel) it enters preRenderView method. As far as I know a ajax request is not supposed to do this. If the popupPanel is not rerendered because the is no triggering ajax request the a4j:commandButton works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

8
11
0 / 0

[JBoss JIRA] Created: (RF-11066) Component: rich:contextMenu for RichFaces 4.X

by Jay Balunas (JIRA)

Component: rich:contextMenu for RichFaces 4.X --------------------------------------------- Key: RF-11066 URL: https://issues.jboss.org/browse/RF-11066 Project: RichFaces Issue Type: Task Security Level: Public (Everyone can see) Components: component-menu Affects Versions: 4.0.0.Final Reporter: Jay Balunas Fix For: 4.Future Migration, implement a version of the context menu for RichFaces 4.X -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

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