From issues at jboss.org Tue Jul 1 03:51:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 1 Jul 2014 03:51:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13651) Integration tests failing in chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980857#comment-12980857 ] Matej Novotny commented on RF-13651: ------------------------------------ I marked the [ITFileUploadTest|https://github.com/richfaces/richfaces/blob/4.5.x/components/rich/src/test/integration/org/richfaces/component/fileUpload/ITFileUpload.java] as @Failing instead of @FailingOnPhantomJS, as it fails on multiple browsers due to Arquillian bug. > Integration tests failing in chrome > ----------------------------------- > > Key: RF-13651 > URL: https://issues.jboss.org/browse/RF-13651 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Brian Leathem > Assignee: Matej Novotny > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The framework tests pass in phantomjs but some fail in chrome. > Resolution of this issue involves running and stabilizing the tests in all supported browsers. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 07:08:25 2014 From: issues at jboss.org (Dariusz M (JIRA)) Date: Tue, 1 Jul 2014 07:08:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13710) popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) In-Reply-To: References: Message-ID: Dariusz M created RF-13710: ------------------------------ Summary: popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) Key: RF-13710 URL: https://issues.jboss.org/browse/RF-13710 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: base functionality Affects Versions: 4.3.7 Reporter: Dariusz M In 4.3.5 it was fine. In 4.3.7 popupPanel with autosized has now width and height set in style attribute for div id's "xxx_container" and "xxx_content_scroller" (width and height calculated for current content rendered during show). Therefore when any element in content changes its size, for example validation on "Store" button is done and message components are rendered (with some errors) then popupPanel stay still and doesn't resizes (scrollbars appears in div) because height in _content_scroller is set to fix value (good at the beginning). In 4.3.5 height and width in style for popupPanel divs wasn't set (in autosized mode) that's why when content was resized then whole popupPanel was resized automatically. It was nice, especially when using popupPanel as in dataTable editing example (data changes in single window with validation messages) or when popupPanel is used in a wizard mode (with some steps, each with little different size) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:04:27 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 1 Jul 2014 08:04:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980949#comment-12980949 ] Pavol Pitonak commented on RF-13706: ------------------------------------ [~marcelkolsteren], just FYI, Maven GAV changed in 4.5 so you can find 4.5.0-SNAPSHOT artefacts in http://repository.jboss.org/nexus/content/groups/public/org/richfaces/richfaces/4.5.0-SNAPSHOT > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Juraj H?ska > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > >
> > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:14:24 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Tue, 1 Jul 2014 16:14:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981190#comment-12981190 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- Thanks! I changed the RichFaces dependency to the 4.5 snapshot artifact supplied by Pavol, and deployed my sample application in WildFly 8.1.0.Final. The problem was still there (as expected). It would be great if you included the fix for this issue in the upcoming 4.3.8 release as well. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Juraj H?ska > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 03:43:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 2 Jul 2014 03:43:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13603) unsupported classversion 51.0 while deploying ear In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13603: ------------------------------- Assignee: (was: Matej Novotny) > unsupported classversion 51.0 while deploying ear > ------------------------------------------------- > > Key: RF-13603 > URL: https://issues.jboss.org/browse/RF-13603 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 5.0.0.Alpha3 > Environment: Windows 7, Weblogic 10.3.5, JDK 6 > Reporter: Nestor Armando Bohorquez > Labels: ResourceServlet, classversion > Fix For: 5-Tracking > > > An exception is thrown when applicattion is been deployed: > {code} > java.lang.UnsupportedClassVersionError: org/richfaces/servlet/ResourceServlet : unsupported classversion 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:630) > at java.lang.ClassLoader.defineClass(ClassLoader.java:614) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:343) > at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:302) > at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270) > at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64) > at java.lang.ClassLoader.loadClass(ClassLoader.java:305) > at java.lang.ClassLoader.loadClass(ClassLoader.java:246) > at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179) > at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43) > at weblogic.servlet.internal.WebAnnotationProcessorImpl.processServlets(WebAnnotationProcessorImpl.java:225) > at weblogic.servlet.internal.WebAnnotationProcessorImpl.processJ2eeAnnotations(WebAnnotationProcessorImpl.java:209) > at weblogic.servlet.internal.WebAnnotationProcessorImpl.processAnnotations(WebAnnotationProcessorImpl.java:105) > at weblogic.servlet.internal.WebAppServletContext.processAnnotations(WebAppServletContext.java:1368) > at weblogic.servlet.internal.WebAppServletContext.(WebAppServletContext.java:449) > at weblogic.servlet.internal.WebAppServletContext.(WebAppServletContext.java:493) > at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:418) > at weblogic.servlet.internal.WebAppModule.registerWebApp(WebAppModule.java:972) > at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:382) > at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176) > at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199) > at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52) > at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159) > at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:45) > at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:613) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52) > at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:184) > at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:58) > at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60) > at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:207) > at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98) > at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217) > at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747) > at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216) > at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250) > at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159) > at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171) > at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13) > at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:178) > {code} > I'm using this in the web.xml file. > {code} > > Resource Servlet > org.richfaces.servlet.ResourceServlet > 1 > > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 03:49:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 2 Jul 2014 03:49:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13215) RichFaces 4.5 integration tests fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981262#comment-12981262 ] Pavol Pitonak commented on RF-13215: ------------------------------------ [~manovotn], can we close this issue? > RichFaces 4.5 integration tests fail > ------------------------------------ > > Key: RF-13215 > URL: https://issues.jboss.org/browse/RF-13215 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha1 > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 4.5-Tracking > > > Please investigate the test failures, stabilize tests and report identified issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 03:57:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 2 Jul 2014 03:57:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12674) Write framework tests for Autocomplete tokenizing feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-12674: ------------------------------- Summary: Write framework tests for Autocomplete tokenizing feature (was: Write fundamental tests for Autocomplete tokenizing feature) > Write framework tests for Autocomplete tokenizing feature > --------------------------------------------------------- > > Key: RF-12674 > URL: https://issues.jboss.org/browse/RF-12674 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.3.0.M3 > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 5-Tracking > > > According to RF-12664 and meeting discussion, > the new tests should be introduced to cover Autocomplete tokenizing feature by fundamental tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 04:03:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 2 Jul 2014 04:03:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13215) RichFaces 4.5 integration tests fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13215. ------------------------------ Resolution: Duplicate Issue Closing issue - this was addressed and resolved in RF-13591. > RichFaces 4.5 integration tests fail > ------------------------------------ > > Key: RF-13215 > URL: https://issues.jboss.org/browse/RF-13215 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha1 > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 4.5-Tracking > > > Please investigate the test failures, stabilize tests and report identified issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:57:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 2 Jul 2014 09:57:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12950) Move Showcase ftests from QA repo to the examples/showcase module and mark some of them as smoke tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-12950: ------------------------------- Assignee: Martin Tomasek (was: Juraj H?ska) > Move Showcase ftests from QA repo to the examples/showcase module and mark some of them as smoke tests > ------------------------------------------------------------------------------------------------------ > > Key: RF-12950 > URL: https://issues.jboss.org/browse/RF-12950 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Luk?? Fry? > Assignee: Martin Tomasek > Fix For: 4.5.0.Beta1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Smoke tests should verify that basic showcase functionality works as expected. > Full showcase test suite can be moved into RF5 repository then. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:15:27 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 2 Jul 2014 10:15:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981448#comment-12981448 ] Matej Novotny commented on RF-13583: ------------------------------------ [~bleathem] I built the [RF-13583-charts branch|https://github.com/richfaces/richfaces/tree/RF-13583-charts] and the showcase in it, where I tried the public API. I suppose the API should be invoked via {{RichFaces.component('id')}}, because all other components work this way. However calling RichFaces.component('id') returns {{undefined}}. So we do not need to merge this commit (or branch) unless we fix it. > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Luk?? Macko > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:10:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 2 Jul 2014 11:10:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13708: ----------------------------- Affects Version/s: 4.3.7 4.3.6 > Photoalbum: refresh over index page throws error > ------------------------------------------------ > > Key: RF-13708 > URL: https://issues.jboss.org/browse/RF-13708 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.6, 4.3.7, 4.3.8 > Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well > browsers: all > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.5-Tracking > > > Refresh over index page of Photoalbum throws: > {code} > 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} > After this error application cease to work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:12:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 2 Jul 2014 11:12:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980617#comment-12980617 ] Juraj H?ska edited comment on RF-13708 at 7/2/14 11:10 AM: ----------------------------------------------------------- The issue was present in RichFaces 4.3.6.Final, 4.3.7 as well. was (Author: jhuska): The issue was present in RichFaces 4.3.6.Final as well. > Photoalbum: refresh over index page throws error > ------------------------------------------------ > > Key: RF-13708 > URL: https://issues.jboss.org/browse/RF-13708 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.6, 4.3.7, 4.3.8 > Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well > browsers: all > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.5-Tracking > > > Refresh over index page of Photoalbum throws: > {code} > 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} > After this error application cease to work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:40:24 2014 From: issues at jboss.org (Evgeny Mironenko (JIRA)) Date: Wed, 2 Jul 2014 11:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: Evgeny Mironenko created RF-13711: ------------------------------------- Summary: a4j:ajax status does not work as expected Key: RF-13711 URL: https://issues.jboss.org/browse/RF-13711 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-a4j-core Affects Versions: 4.3.7 Environment: IE8, Mozilla Firefox 30 Reporter: Evgeny Mironenko Status attribute for a4j:ajax does not work as expected. I tried to create simple project with next content: index.xhtml:
It's not worked for me. I not see log messages in console. As workground I use render attribute instead of status, but we use it for another goals, I am right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:42:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 11:42:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13583: ---------------------------------- Assignee: Brian Leathem (was: Luk?? Macko) > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:56:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 2 Jul 2014 11:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981507#comment-12981507 ] Juraj H?ska commented on RF-13708: ---------------------------------- It is caused by _binding_ the {{rich:tree}} component to a backing bean by its {{binding}} attribute. When I remove this binding, the error does not occur (however other functionality dependent on it does not work). Afaik binding is not recommended in RichFaces application. Am I right [~bleathem] ? If so, I consider this as a example application bug, not the framework one. Thus not critical. > Photoalbum: refresh over index page throws error > ------------------------------------------------ > > Key: RF-13708 > URL: https://issues.jboss.org/browse/RF-13708 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.6, 4.3.7, 4.3.8 > Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well > browsers: all > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.5-Tracking > > > Refresh over index page of Photoalbum throws: > {code} > 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} > After this error application cease to work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:06:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:06:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981513#comment-12981513 ] Brian Leathem commented on RF-13708: ------------------------------------ Thanks for the investigations [~jhuska]. [~michpetrov] can you comment on the use of the _binding_ attribute? If it is easy to do so, please remove it and schedule this issue accordingly. > Photoalbum: refresh over index page throws error > ------------------------------------------------ > > Key: RF-13708 > URL: https://issues.jboss.org/browse/RF-13708 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.6, 4.3.7, 4.3.8 > Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well > browsers: all > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.5-Tracking > > > Refresh over index page of Photoalbum throws: > {code} > 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} > After this error application cease to work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:06:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:06:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13710) popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13710: ------------------------------- Fix Version/s: 4.3.8 > popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) > --------------------------------------------------------------------------------------------- > > Key: RF-13710 > URL: https://issues.jboss.org/browse/RF-13710 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: base functionality > Affects Versions: 4.3.7 > Reporter: Dariusz M > Fix For: 4.3.8 > > > In 4.3.5 it was fine. > In 4.3.7 popupPanel with autosized has now width and height set in style attribute for div id's "xxx_container" and "xxx_content_scroller" (width and height calculated for current content rendered during show). Therefore when any element in content changes its size, for example validation on "Store" button is done and message components are rendered (with some errors) then popupPanel stay still and doesn't resizes (scrollbars appears in div) because height in _content_scroller is set to fix value (good at the beginning). > In 4.3.5 height and width in style for popupPanel divs wasn't set (in autosized mode) that's why when content was resized then whole popupPanel was resized automatically. It was nice, especially when using popupPanel as in dataTable editing example (data changes in single window with validation messages) or when popupPanel is used in a wizard mode (with some steps, each with little different size) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:08:48 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:08:48 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13710) popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981519#comment-12981519 ] Brian Leathem commented on RF-13710: ------------------------------------ With RF-13616, popupPanel will listen for resize events from it's children and resize accordingly. Perhaps you can use this as a workaround. > popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request) > --------------------------------------------------------------------------------------------- > > Key: RF-13710 > URL: https://issues.jboss.org/browse/RF-13710 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: base functionality > Affects Versions: 4.3.7 > Reporter: Dariusz M > Fix For: 4.3.8 > > > In 4.3.5 it was fine. > In 4.3.7 popupPanel with autosized has now width and height set in style attribute for div id's "xxx_container" and "xxx_content_scroller" (width and height calculated for current content rendered during show). Therefore when any element in content changes its size, for example validation on "Store" button is done and message components are rendered (with some errors) then popupPanel stay still and doesn't resizes (scrollbars appears in div) because height in _content_scroller is set to fix value (good at the beginning). > In 4.3.5 height and width in style for popupPanel divs wasn't set (in autosized mode) that's why when content was resized then whole popupPanel was resized automatically. It was nice, especially when using popupPanel as in dataTable editing example (data changes in single window with validation messages) or when popupPanel is used in a wizard mode (with some steps, each with little different size) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:14:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:14:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13711: ------------------------------- Description: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use therender attribute instead of {{a4j:status}}, but we use it for another goals, am I right? was: Status attribute for a4j:ajax does not work as expected. I tried to create simple project with next content: index.xhtml:
It's not worked for me. I not see log messages in console. As workground I use render attribute instead of status, but we use it for another goals, I am right? > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use therender attribute instead of {{a4j:status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:14:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:14:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13711: ------------------------------- Description: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use the render attribute instead of {{a4j:status}}, but we use it for another goals, am I right? was: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use therender attribute instead of {{a4j:status}}, but we use it for another goals, am I right? > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the render attribute instead of {{a4j:status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:16:32 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 12:16:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13711: ---------------------------------- Assignee: Pavol Pitonak QE: please verify > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Pavol Pitonak > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the render attribute instead of {{a4j:status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:46:25 2014 From: issues at jboss.org (Evgeny Mironenko (JIRA)) Date: Wed, 2 Jul 2014 12:46:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Mironenko updated RF-13711: ---------------------------------- Description: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? was: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use the render attribute instead of {{a4j:status}}, but we use it for another goals, am I right? > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Pavol Pitonak > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:46:26 2014 From: issues at jboss.org (Evgeny Mironenko (JIRA)) Date: Wed, 2 Jul 2014 12:46:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Mironenko updated RF-13711: ---------------------------------- Description: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? was: Status attribute for {{a4j:ajax}} does not work as expected. I tried to create simple project with content: {code:title=index.xhtml}
{code} It did not work for me. I do not see any log messages in the console. As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Pavol Pitonak > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:43:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:43:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13709) Remove the chart components from the RichFaces mobile showcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13709: ------------------------------- Summary: Remove the chart components from the RichFaces mobile showcase (was: Remove the chart components from the RichFaces showcase) > Remove the chart components from the RichFaces mobile showcase > -------------------------------------------------------------- > > Key: RF-13709 > URL: https://issues.jboss.org/browse/RF-13709 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: showcase > Reporter: Brian Leathem > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The chart components need additional work to function in a mobile environment. In the mean time we should remove them from the mobile showcase. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:45:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:45:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13709) Remove the chart components from the RichFaces mobile showcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13709. -------------------------------- Resolution: Done > Remove the chart components from the RichFaces mobile showcase > -------------------------------------------------------------- > > Key: RF-13709 > URL: https://issues.jboss.org/browse/RF-13709 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: showcase > Reporter: Brian Leathem > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The chart components need additional work to function in a mobile environment. In the mean time we should remove them from the mobile showcase. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:45:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:45:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981672#comment-12981672 ] Brian Leathem commented on RF-13660: ------------------------------------ [~jhuska] are you able to make progress on this issue? Feel free to ping me if you don't know how to proceed. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:47:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:47:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13651) Integration tests failing in chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981673#comment-12981673 ] Brian Leathem commented on RF-13651: ------------------------------------ [~manovotn] are we then able to resolve this issue? If Fileupload is the only issue, and it's marked as failing, then let's file a new issue to track that and resolve this one. (cc: [~ppitonak]) > Integration tests failing in chrome > ----------------------------------- > > Key: RF-13651 > URL: https://issues.jboss.org/browse/RF-13651 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Brian Leathem > Assignee: Matej Novotny > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The framework tests pass in phantomjs but some fail in chrome. > Resolution of this issue involves running and stabilizing the tests in all supported browsers. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:49:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:49:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981674#comment-12981674 ] Brian Leathem commented on RF-13583: ------------------------------------ [~jhuska], [~manovotn]: if all outstanding chart component issues are tracked elsewhere, can we resolve this issue? (cc: [~ppitonak]) > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 17:53:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 17:53:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13664) EDT firstChild call will return a text element when the source code is formatted to have one element per line In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13664. -------------------------------- Resolution: Done That usage of {{firstChild}} was reviewed and is acceptable. The {{firstChild}} call is necessary for {{nextSibling}} to work. Usage of {{firstChild}} here will not break with text children since the children are iterated over until a table element is found. > EDT firstChild call will return a text element when the source code is formatted to have one element per line > ------------------------------------------------------------------------------------------------------------- > > Key: RF-13664 > URL: https://issues.jboss.org/browse/RF-13664 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-tables > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Formatting the generated html and viewing the result in chrome leads to an error in the EDT call: > {{this.frozenHeaderPartElement.firstChild.rows}}. This is because when the element is followed by a newline, a text element is returned from the firstChild call. > Some solutions to this are discussed in the stackoverflow question: > http://stackoverflow.com/questions/2299807/element-firstchild-is-returning-textnode-instead-of-an-object-in-ff > I recommend we use jQuery here to resolve the first child in a cross-browser way. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:03:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:03:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13652) Forward port the 4.3.7 fixes into the 4.5.x branch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981680#comment-12981680 ] Brian Leathem commented on RF-13652: ------------------------------------ {{[5caad|https://github.com/richfaces4/components/commit/5caad81da32f96da7a10228405594b360d70aca5]}} was applied with {{[c11a0|https://github.com/richfaces/richfaces/commit/c11a078bb0ec78add810c1677d1ad425cf549c06#diff-29c423e89e80dc3461b4aba5bca0549cR13]}}. {{[6691e|https://github.com/richfaces4/components/commit/6691e98b63daf7d17241aa989c9a4763bb7e372a]}} was indeed missing. I've applied it with {{[04a15|https://github.com/richfaces/richfaces/commit/04a153f33526c6f45ef582e08701f432114e7f19]}}. > Forward port the 4.3.7 fixes into the 4.5.x branch > -------------------------------------------------- > > Key: RF-13652 > URL: https://issues.jboss.org/browse/RF-13652 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:03:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:03:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13652) Forward port the 4.3.7 fixes into the 4.5.x branch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13652. -------------------------------- Resolution: Done > Forward port the 4.3.7 fixes into the 4.5.x branch > -------------------------------------------------- > > Key: RF-13652 > URL: https://issues.jboss.org/browse/RF-13652 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13698: ---------------------------------- Assignee: Brian Leathem > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13699: ---------------------------------- Assignee: Brian Leathem > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13701) RF 4.5 Bar chart plotClick malfunctioning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13701: ---------------------------------- Assignee: Brian Leathem > RF 4.5 Bar chart plotClick malfunctioning > ----------------------------------------- > > Key: RF-13701 > URL: https://issues.jboss.org/browse/RF-13701 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > When interacting with bar chart where {{onplotclick}} and {{plotClickListener}} are set, it does not react when last bar in the series is clicked (eg .no request is sent for server side event and no JS executed for onplotclick). See steps to reproduce, in case they are not clear ask me for more details. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:24:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:24:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13698. -------------------------------- Resolution: Done > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:44:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13699. -------------------------------- Resolution: Done > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 18:48:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 2 Jul 2014 18:48:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981701#comment-12981701 ] Brian Leathem commented on RF-13699: ------------------------------------ I've corrected the client-side so the zoom selection works. However, if I understand correctly, the zooming itself must be implemented by a listener of some kind. [~lukindo] can you confirm this for us? > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 02:03:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 02:03:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13651) Integration tests failing in chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny resolved RF-13651. -------------------------------- Resolution: Done Yes, we can resolve this as the smoke tests are passing in chrome and ff correctly. > Integration tests failing in chrome > ----------------------------------- > > Key: RF-13651 > URL: https://issues.jboss.org/browse/RF-13651 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Brian Leathem > Assignee: Matej Novotny > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The framework tests pass in phantomjs but some fail in chrome. > Resolution of this issue involves running and stabilizing the tests in all supported browsers. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 04:30:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 04:30:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reopened RF-13698: -------------------------------- The commit resolving this issue causes another bug (regression). The title is rendered correctly but you cannot invoke server-side event. Eg. in Metamer example while clicking on a plot, there is no server side event. > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 04:36:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 04:36:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981801#comment-12981801 ] Matej Novotny commented on RF-13583: ------------------------------------ [~bleathem] charts public API still wasn't backported. I will resolve this issue and create a new one (linked to this) where we track the API. > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 04:38:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 04:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981801#comment-12981801 ] Matej Novotny edited comment on RF-13583 at 7/3/14 4:36 AM: ------------------------------------------------------------ [~bleathem] charts public API still wasn't backported. We reopened this issue to track this hence I think we should keep it open until we address this. was (Author: manovotn): [~bleathem] charts public API still wasn't backported. I will resolve this issue and create a new one (linked to this) where we track the API. > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 05:20:28 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 05:20:28 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981837#comment-12981837 ] Matej Novotny commented on RF-13699: ------------------------------------ Shouldn't we keep the issue opened until we make this fully working? While trying to zoom now, a rectangle is drawn, but no zooming happens. As for listener, if you mean any listener implemented by user (or handler), than there is nothing needed, all user needs is a line chart with zoom=true. > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 05:26:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 05:26:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981796#comment-12981796 ] Matej Novotny edited comment on RF-13698 at 7/3/14 5:24 AM: ------------------------------------------------------------ The commit resolving this issue causes another bug (regression). The title is rendered correctly but you cannot invoke server-side event. Eg. in [Metamer example|http://localhost:8080/metamer/faces/components/richChart/simpleLine.xhtml] while clicking on a plot, there is no server side event. was (Author: manovotn): The commit resolving this issue causes another bug (regression). The title is rendered correctly but you cannot invoke server-side event. Eg. in Metamer example while clicking on a plot, there is no server side event. > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 05:28:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 3 Jul 2014 05:28:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reopened RF-13699: -------------------------------- > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 06:54:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Thu, 3 Jul 2014 06:54:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: Byambaa MD created RF-13712: ------------------------------- Summary: FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 Key: RF-13712 URL: https://issues.jboss.org/browse/RF-13712 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: accessibility Affects Versions: 4.3.7 Environment: 4.3.7 FileUpload does not work on wildfly Reporter: Byambaa MD Priority: Critical Fix For: 4.3.8 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 06:54:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Thu, 3 Jul 2014 06:54:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981875#comment-12981875 ] Byambaa MD commented on RF-13712: --------------------------------- 18:48:27,690 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter starting up... 18:48:28,019 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter initialized. 18:48:28,932 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j version: 1.6.3 18:48:28,944 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j configuration: ro.isdc.wro.config.jmx.WroConfiguration at 58f72844[ cacheUpdatePeriod=0 modelUpdatePeriod=0 resourceWatcherUpdatePeriod=0 gzipEnabled=true debug=true ignoreMissingResources=true disableCache=false cacheGzippedContent=true jmxEnabled=false wroManagerClassName=ro.isdc.wro.extensions.manager.ExtensionsConfigurableWroManagerFactory encoding=UTF-8 mbeanName= header= connectionTimeout=2000 parallelPreprocessing=true ignoreEmptyGroup=true ignoreFailingProcessor=false ] 18:48:52,511 INFO [cmn] (default task-47) Successful SU Logged : 'admin' 18:49:19,209 SEVERE [org.richfaces.log.Context] (default task-19) null: java.lang.NullPointerException at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.PartialViewExecuteVisitCallback.visit(PartialViewExecuteVisitCallback.java:53) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.BaseExtendedVisitContext.invokeVisitCallback(BaseExtendedVisitContext.java:321) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1690) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.visitTree(UIForm.java:362) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.ExtendedPartialViewContextImpl.executeComponents(ExtendedPartialViewContextImpl.java:278) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartialExecutePhase(ExtendedPartialViewContextImpl.java:258) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:215) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:927) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: accessibility > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Priority: Critical > Fix For: 4.3.8 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 06:56:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Thu, 3 Jul 2014 06:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: fileupload error on wildfly.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: accessibility > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Priority: Critical > Fix For: 4.3.8 > > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 10:08:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 3 Jul 2014 10:08:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reassigned RF-13711: ---------------------------------- Assignee: Matej Novotny (was: Pavol Pitonak) > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 12:20:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 12:20:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13712: ------------------------------- Fix Version/s: (was: 4.3.8) > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: accessibility > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Priority: Critical > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 12:20:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 12:20:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13712: ------------------------------- Priority: Major (was: Critical) > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: accessibility > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 12:20:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 12:20:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13712: ------------------------------- Component/s: component-input (was: accessibility) > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 12:22:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 12:22:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13712. -------------------------------- Resolution: Rejected RichFaces 4.3 is not compatible with JSF 2.2 that runs on Wildfly. Please use RichFaces 4.5.0-SNAPSHOT with Widlfly. We expect to have a feature-complete 4.5.0.Alpha3 release in the coming weeks. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 19:08:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 19:08:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13698. -------------------------------- Resolution: Done Fixed the chart.js to look-up the chart-container parent when determining the clientId. > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 20:44:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 20:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982218#comment-12982218 ] Brian Leathem commented on RF-13583: ------------------------------------ I've cherry-picked and fixed [~lukindo]'s commit. I tested that the public API works with the "resetZoom" method I wrote for RF-13699. I'm resolving this issue. Any aspects of the public API that do not work should be reported via a new issue. (Thanks guys, I appreciate your diligence with this chart stuff. I'm picking up where it was left off with no knowledge of the state it was left in). > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 20:44:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 20:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13583. -------------------------------- Resolution: Done > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 20:44:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 20:44:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13699. -------------------------------- Resolution: Done I implemented zoom and resetZoom functions to implement the client-side zoom. > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 21:55:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Thu, 3 Jul 2014 21:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982228#comment-12982228 ] Byambaa MD commented on RF-13712: --------------------------------- Thanks for you clearification Brain. How/Where i can download richfaces 4.5.0 snapshot ? > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 23:45:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 3 Jul 2014 23:45:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982244#comment-12982244 ] Brian Leathem commented on RF-13712: ------------------------------------ See https://community.jboss.org/wiki/MavenGettingStarted-Users. Note: the maven coordinates have changes in 4.5, see for example: https://github.com/richfaces/richfaces/blob/4.5.x/examples/components-demo/pom.xml > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:33:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 00:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982251#comment-12982251 ] Byambaa MD commented on RF-13712: --------------------------------- Dear Brian Leathem, I downloaded richfaces-distribution-4.5.0-20140704.014131-67-richfaces and retest my code but does not work fileupload. please see detailed log ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 12:29:02,248 ERROR [io.undertow.request] (default task-91) UT005023: Exception handling request to /dev/SU.xhtml: java.lang.RuntimeException: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:182) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] Caused by: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:207) [omnifaces-1.8.1.jar:1.8.1-20140603] at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:176) [omnifaces-1.8.1.jar:1.8.1-20140603] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] ... 29 more > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:33:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 00:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: AS error log.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:35:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 00:35:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: chrome js error log.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:35:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 00:35:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982252#comment-12982252 ] Byambaa MD commented on RF-13712: --------------------------------- Dear Brian Leathem, I downloaded richfaces-distribution-4.5.0-20140704.014131-67-richfaces and retest my code but does not work fileupload. please see detailed logs from latest attached files and previous comment > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:58:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 00:58:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982251#comment-12982251 ] Brian Leathem edited comment on RF-13712 at 7/4/14 12:56 AM: ------------------------------------------------------------- Dear Brian Leathem, I downloaded richfaces-distribution-4.5.0-20140704.014131-67-richfaces and retest my code but does not work fileupload. please see detailed log ---- {code} 12:29:02,248 ERROR [io.undertow.request] (default task-91) UT005023: Exception handling request to /dev/SU.xhtml: java.lang.RuntimeException: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:182) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] Caused by: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:207) [omnifaces-1.8.1.jar:1.8.1-20140603] at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:176) [omnifaces-1.8.1.jar:1.8.1-20140603] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] ... 29 more {code} was (Author: sdk): Dear Brian Leathem, I downloaded richfaces-distribution-4.5.0-20140704.014131-67-richfaces and retest my code but does not work fileupload. please see detailed log ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 12:29:02,248 ERROR [io.undertow.request] (default task-91) UT005023: Exception handling request to /dev/SU.xhtml: java.lang.RuntimeException: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:182) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] Caused by: java.lang.IllegalArgumentException: Either HTTP 500 or java.lang.Throwable error page is required in web.xml or web-fragment.xml. Neither was found. at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handleAjaxException(FullAjaxExceptionHandler.java:207) [omnifaces-1.8.1.jar:1.8.1-20140603] at org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:176) [omnifaces-1.8.1.jar:1.8.1-20140603] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] ... 29 more > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:58:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 00:58:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981875#comment-12981875 ] Brian Leathem edited comment on RF-13712 at 7/4/14 12:56 AM: ------------------------------------------------------------- {code} 18:48:27,690 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter starting up... 18:48:28,019 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter initialized. 18:48:28,932 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j version: 1.6.3 18:48:28,944 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j configuration: ro.isdc.wro.config.jmx.WroConfiguration at 58f72844[ cacheUpdatePeriod=0 modelUpdatePeriod=0 resourceWatcherUpdatePeriod=0 gzipEnabled=true debug=true ignoreMissingResources=true disableCache=false cacheGzippedContent=true jmxEnabled=false wroManagerClassName=ro.isdc.wro.extensions.manager.ExtensionsConfigurableWroManagerFactory encoding=UTF-8 mbeanName= header= connectionTimeout=2000 parallelPreprocessing=true ignoreEmptyGroup=true ignoreFailingProcessor=false ] 18:48:52,511 INFO [cmn] (default task-47) Successful SU Logged : 'admin' 18:49:19,209 SEVERE [org.richfaces.log.Context] (default task-19) null: java.lang.NullPointerException at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.PartialViewExecuteVisitCallback.visit(PartialViewExecuteVisitCallback.java:53) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.BaseExtendedVisitContext.invokeVisitCallback(BaseExtendedVisitContext.java:321) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1690) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.visitTree(UIForm.java:362) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.ExtendedPartialViewContextImpl.executeComponents(ExtendedPartialViewContextImpl.java:278) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartialExecutePhase(ExtendedPartialViewContextImpl.java:258) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:215) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:927) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] {code} was (Author: sdk): 18:48:27,690 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter starting up... 18:48:28,019 INFO [com.ocpsoft.pretty.PrettyFilter] (default task-1) PrettyFilter initialized. 18:48:28,932 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j version: 1.6.3 18:48:28,944 INFO [ro.isdc.wro.http.WroFilter] (default task-3) wro4j configuration: ro.isdc.wro.config.jmx.WroConfiguration at 58f72844[ cacheUpdatePeriod=0 modelUpdatePeriod=0 resourceWatcherUpdatePeriod=0 gzipEnabled=true debug=true ignoreMissingResources=true disableCache=false cacheGzippedContent=true jmxEnabled=false wroManagerClassName=ro.isdc.wro.extensions.manager.ExtensionsConfigurableWroManagerFactory encoding=UTF-8 mbeanName= header= connectionTimeout=2000 parallelPreprocessing=true ignoreEmptyGroup=true ignoreFailingProcessor=false ] 18:48:52,511 INFO [cmn] (default task-47) Successful SU Logged : 'admin' 18:49:19,209 SEVERE [org.richfaces.log.Context] (default task-19) null: java.lang.NullPointerException at org.richfaces.renderkit.AjaxCommandRendererBase.isSubmitted(AjaxCommandRendererBase.java:83) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.AjaxCommandRendererBase.doDecode(AjaxCommandRendererBase.java:59) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.renderkit.RendererBase.decode(RendererBase.java:80) [richfaces-components-ui-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.PartialViewExecuteVisitCallback.visit(PartialViewExecuteVisitCallback.java:53) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.BaseExtendedVisitContext.invokeVisitCallback(BaseExtendedVisitContext.java:321) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1690) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIForm.visitTree(UIForm.java:362) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at javax.faces.component.UIComponent.visitTree(UIComponent.java:1701) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at org.richfaces.context.ExtendedPartialViewContextImpl.executeComponents(ExtendedPartialViewContextImpl.java:278) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartialExecutePhase(ExtendedPartialViewContextImpl.java:258) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:215) [richfaces-core-impl-4.3.7.Final.jar:4.3.7.Final] at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:927) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-4.jar:] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.6-jbossorg-4.jar:] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:137) [prettyfaces-jsf2-3.3.3.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:01:14 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 01:01:14 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982257#comment-12982257 ] Brian Leathem commented on RF-13712: ------------------------------------ There are no RichFaces classes referenced in your 2nd stacktrace. Seems like the problem is with your application. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:06:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:06:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: Web application libraries and main page structure.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, chrome js error log.png, fileupload error on wildfly.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:10:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:10:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: Render code.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:10:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:10:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: can't Render.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:18:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:18:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Byambaa MD updated RF-13712: ---------------------------- Attachment: file upload done !.png > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:20:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:20:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982259#comment-12982259 ] Byambaa MD commented on RF-13712: --------------------------------- Thanks for your response Brian, 1. RF 4.5 can't render area/region by id. needs require refresh and then render working correctly once time. again refresh .... ! please see latest attached files. 2. after refresh button file upload seeing done on web browser and no error logs on console but file not found on server uploaded directory ? please see latest attached screenshots PS : i don'd click refresh button and upload file, these (previous comment) error logging. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:20:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:20:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982260#comment-12982260 ] Byambaa MD commented on RF-13712: --------------------------------- MY FILEUPLOAD MBEAN CODE --------------------------------------------------------------------------------------------- package mdb.dev.ZMN.core.mbean.UF; import java.io.File; import java.io.Serializable; import java.util.ArrayList; import java.util.Collection; import javax.faces.application.FacesMessage; import javax.faces.bean.ManagedBean; import javax.faces.bean.SessionScoped; import javax.faces.context.FacesContext; import javax.imageio.stream.FileImageOutputStream; import mdb.cmn.base.configure.utilities.CMNBaseConfigureUtilities; import mdb.cmn.base.mbean.CMNBaseMBean; import mdb.cmn.utilities.log.CMNLogUtilities; import mdb.cmn.utilities.system.CMNSystemUtilities; import mdb.dev.ZMN.core.constants.ZMNCoreConstants; import mdb.dev.ZMN.core.mbean.UF.DTO.ZMNCoreUFDTO; import mdb.dev.ZMN.core.mbean.utilities.ZMNCoreMBeanUtilities; import mdb.dev.ZMN.core.utilities.configure.ZMNCoreConfigureUtilities; import org.apache.commons.io.FileUtils; import org.apache.commons.lang3.StringUtils; import org.primefaces.event.CaptureEvent; import org.richfaces.event.FileUploadEvent; /** * * @author Byambasuren.MD * **/ @SuppressWarnings("serial") @SessionScoped @ManagedBean(name = "CoreUFMBean") public class ZMNCoreUFMBean extends CMNBaseMBean implements Serializable, ZMNCoreConstants { private boolean immediateUpload = false, allowFlash = false, autoClose = false, generateName = true, useData = false, autoFinish = false, baseTemporary = false; private Integer maxFilesQuantity; private String acceptedTypes, destination; private String render, desName, namePrefix; private Collection files; private boolean visible; public ZMNCoreUFMBean() { super(); } /** MBean Utilities **/ public void doSetXUIMaintenance() { } public void doRTEMaintenance(String desName) { } public void doUploadMaintenance(String desName) { } public CMNBaseConfigureUtilities getConfigure() { return ZMNCoreConfigureUtilities.getInstance(); } /** Utilities **/ public void onCapture(CaptureEvent captureEvent) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(null, null, null, captureEvent.getData().length, (this.isUseData() ? captureEvent.getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null, "png"); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileImageOutputStream imageOutput; imageOutput = new FileImageOutputStream(new File(this.getBaseDestination() + this.getDestination() + uFile.getName())); imageOutput.write(captureEvent.getData(), 0, captureEvent.getData().length); imageOutput.close(); this.getFiles().add(uFile); } catch (Exception ex) { CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void listener(FileUploadEvent event) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(event.getUploadedFile().getName(), event.getUploadedFile().getName(), event.getUploadedFile().getContentType(), event.getUploadedFile().getSize(), (this.isUseData() ? event.getUploadedFile().getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileUtils.writeByteArrayToFile(new File(this.getBaseDestination() + this.getDestination() + uFile.getName()), event.getUploadedFile().getData()); this.getFiles().add(uFile); this.setMaxFilesQuantity(this.getMaxFilesQuantity() - 1); } catch (Exception ex) { ex.printStackTrace(); CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void doShow() { this.setVisible(true); } public void doClear() { this.setVisible(false); this.setImmediateUpload(false); this.setAllowFlash(false); this.setAutoFinish(false); this.setAutoClose(false); this.setGenerateName(true); this.setUseData(false); this.setAcceptedTypes(null); this.setMaxFilesQuantity(null); this.setDestination(null); this.setNamePrefix(null); this.setFiles(null); } public void doUpload() { if (this.getHasFiles()) { ZMNCoreMBeanUtilities.getCoreSUMBean().doUploadMaintenance(this.getDesName()); this.doClear(); } else { FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, ZMNCoreMBeanUtilities.getBundleMessage("cmn", "lbl.operation.warning"), ZMNCoreMBeanUtilities.getBundleMessage("cmn", "msg.operation.canceled"))); } } /** Managed Getters **/ public String getBaseDestination() { return this.isBaseTemporary() ? ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.TEMPORARY).getValue() : ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.RESOURCES).getValue(); } /** Getters **/ public ZMNCoreUFDTO getFile(int index) { return this.getHasFiles() ? ((ArrayList) this.getFiles()).get(index) : null; } public boolean getHasFiles() { return this.getFiles().size() > 0; } public boolean getHasRender() { return StringUtils.isNotBlank(this.getRender()); } public boolean getHasNamePrefix() { return StringUtils.isNotBlank(this.getNamePrefix()); } /** Getters Setters **/ public boolean isImmediateUpload() { return immediateUpload; } public void setImmediateUpload(boolean immediateUpload) { this.immediateUpload = immediateUpload; } public boolean isAllowFlash() { return allowFlash; } public void setAllowFlash(boolean allowFlash) { this.allowFlash = allowFlash; } public boolean isGenerateName() { return generateName; } public void setGenerateName(boolean generateName) { this.generateName = generateName; } public boolean isUseData() { return useData; } public void setUseData(boolean useData) { this.useData = useData; } public Integer getMaxFilesQuantity() { return maxFilesQuantity != null ? maxFilesQuantity : (maxFilesQuantity = 1); } public void setMaxFilesQuantity(Integer maxFilesQuantity) { this.maxFilesQuantity = maxFilesQuantity; } public String getNamePrefix() { return namePrefix; } public void setNamePrefix(String namePrefix) { this.namePrefix = namePrefix; } public String getAcceptedTypes() { return acceptedTypes != null ? acceptedTypes : (acceptedTypes = "jpg, gif, png"); } public void setAcceptedTypes(String acceptedTypes) { this.acceptedTypes = acceptedTypes; } public String getDestination() { return destination != null ? (destination + "/") : (destination = ""); } public void setDestination(String destination) { this.destination = destination; } public Collection getFiles() { return files != null ? files : (files = new ArrayList()); } public void setFiles(Collection files) { this.files = files; } public boolean isBaseTemporary() { return baseTemporary; } public void setBaseTemporary(boolean baseTemporary) { this.baseTemporary = baseTemporary; } public boolean isVisible() { return visible; } public void setVisible(boolean visible) { this.visible = visible; } public boolean isAutoClose() { return autoClose; } public void setAutoClose(boolean autoClose) { this.autoClose = autoClose; } public String getRender() { return render; } public void setRender(String render) { this.render = render; } public boolean isAutoFinish() { return autoFinish; } public void setAutoFinish(boolean autoFinish) { this.autoFinish = autoFinish; } public String getDesName() { return desName; } public void setDesName(String desName) { this.desName = desName; } } > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 01:22:24 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Fri, 4 Jul 2014 01:22:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982261#comment-12982261 ] Byambaa MD commented on RF-13712: --------------------------------- MY FILE UPLOAD XHTML PAGE CODE --------------------------------------------------------------
> FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 02:53:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 Jul 2014 02:53:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13698) RF 4.5 Chart title does not render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13698. ------------------------------ Verified, title is rendered and server-side events are called. Closing issue. > RF 4.5 Chart title does not render > ---------------------------------- > > Key: RF-13698 > URL: https://issues.jboss.org/browse/RF-13698 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > FF/Chrome > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The title of the chart is not rendered above the chart. This affects all kinds of charts, eg. line, pie and bar. > I created Metamer samples of charts for 4.5.x where this can be tested (not automatically until public JS API for charts will be available). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 03:11:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 Jul 2014 03:11:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13699) RF 4.5 Chart attribute 'zoom' does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13699. ------------------------------ Verified, zooming now works correctly and can be reset via JS. Closing issue. > RF 4.5 Chart attribute 'zoom' does not work > ------------------------------------------- > > Key: RF-13699 > URL: https://issues.jboss.org/browse/RF-13699 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The attribute 'zoom' does not work, setting it to true has no effect and user cannot zoom the chart. This attribute is only available for line chart. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 03:15:27 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 Jul 2014 03:15:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13583) Backport the chart components to RichFaces 4.5 components module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13583. ------------------------------ Good job [~bleathem], thanks for quick fixes. Verified, changes are backported, JS API is present and working (I will write integration tests for it anytime soon). Closing issue. > Backport the chart components to RichFaces 4.5 components module > ---------------------------------------------------------------- > > Key: RF-13583 > URL: https://issues.jboss.org/browse/RF-13583 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Backport the chart components to RichFaces 4.5 components module -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 03:31:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 Jul 2014 03:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5 In-Reply-To: References: Message-ID: Matej Novotny created RF-13713: ---------------------------------- Summary: Create Smoke test(s) for chart in RF 4.5 Key: RF-13713 URL: https://issues.jboss.org/browse/RF-13713 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: component-output Affects Versions: 4.5.0.Alpha2 Reporter: Matej Novotny Assignee: Matej Novotny Priority: Minor Fix For: 4.5.0.Alpha2 As charts were added recently we have no tests covering this component. We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. These tests might run only with some browsers - investigate. Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 05:35:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Fri, 4 Jul 2014 05:35:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: Martin H?ller created RF-13714: ---------------------------------- Summary: DropDownMenu not working inside tab-header Key: RF-13714 URL: https://issues.jboss.org/browse/RF-13714 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-menu Affects Versions: 4.3.7 Environment: Wildfly 8.1.0.GA => JSF 2.2 Tested with recent Firefox and Chromium versions. Reporter: Martin H?ller The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: {code:xml} {code} If I use the same menu-code in the but outside the header-facet, it works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 05:51:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Fri, 4 Jul 2014 05:51:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin H?ller updated RF-13714: ------------------------------- Description: The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: {code:xml} {code} If I use the same menu-code in the but outside the header-facet, it works. This did work with Richfaces 3.3! was: The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: {code:xml} {code} If I use the same menu-code in the but outside the header-facet, it works. Forum Reference: https://community.jboss.org/message/880495 > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 08:47:25 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 4 Jul 2014 08:47:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982374#comment-12982374 ] Juraj H?ska commented on RF-13706: ---------------------------------- We have verified the PR. It looks good. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Juraj H?ska > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 08:47:25 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 4 Jul 2014 08:47:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13706: ----------------------------- Assignee: (was: Juraj H?ska) > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 08:47:26 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 4 Jul 2014 08:47:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13706: ----------------------------- Assignee: Brian Leathem > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Brian Leathem > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 09:07:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 4 Jul 2014 09:07:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny resolved RF-13713. -------------------------------- Resolution: Done Tests are created and pushed into repository, PhantomJS and Chrome works fine. In Firefox WebDriver cannot click a point in canvas and hence cannot fire an event - so those tests are skipped for FF. We might want to introduce @FailingOnFirefox annotation for this purposes. > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha2 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha2 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:29:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:29:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982260#comment-12982260 ] Brian Leathem edited comment on RF-13712 at 7/4/14 11:27 AM: ------------------------------------------------------------- MY FILEUPLOAD MBEAN CODE ---- {code} package mdb.dev.ZMN.core.mbean.UF; import java.io.File; import java.io.Serializable; import java.util.ArrayList; import java.util.Collection; import javax.faces.application.FacesMessage; import javax.faces.bean.ManagedBean; import javax.faces.bean.SessionScoped; import javax.faces.context.FacesContext; import javax.imageio.stream.FileImageOutputStream; import mdb.cmn.base.configure.utilities.CMNBaseConfigureUtilities; import mdb.cmn.base.mbean.CMNBaseMBean; import mdb.cmn.utilities.log.CMNLogUtilities; import mdb.cmn.utilities.system.CMNSystemUtilities; import mdb.dev.ZMN.core.constants.ZMNCoreConstants; import mdb.dev.ZMN.core.mbean.UF.DTO.ZMNCoreUFDTO; import mdb.dev.ZMN.core.mbean.utilities.ZMNCoreMBeanUtilities; import mdb.dev.ZMN.core.utilities.configure.ZMNCoreConfigureUtilities; import org.apache.commons.io.FileUtils; import org.apache.commons.lang3.StringUtils; import org.primefaces.event.CaptureEvent; import org.richfaces.event.FileUploadEvent; /** * * @author Byambasuren.MD * **/ @SuppressWarnings("serial") @SessionScoped @ManagedBean(name = "CoreUFMBean") public class ZMNCoreUFMBean extends CMNBaseMBean implements Serializable, ZMNCoreConstants { private boolean immediateUpload = false, allowFlash = false, autoClose = false, generateName = true, useData = false, autoFinish = false, baseTemporary = false; private Integer maxFilesQuantity; private String acceptedTypes, destination; private String render, desName, namePrefix; private Collection files; private boolean visible; public ZMNCoreUFMBean() { super(); } /** MBean Utilities **/ public void doSetXUIMaintenance() { } public void doRTEMaintenance(String desName) { } public void doUploadMaintenance(String desName) { } public CMNBaseConfigureUtilities getConfigure() { return ZMNCoreConfigureUtilities.getInstance(); } /** Utilities **/ public void onCapture(CaptureEvent captureEvent) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(null, null, null, captureEvent.getData().length, (this.isUseData() ? captureEvent.getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null, "png"); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileImageOutputStream imageOutput; imageOutput = new FileImageOutputStream(new File(this.getBaseDestination() + this.getDestination() + uFile.getName())); imageOutput.write(captureEvent.getData(), 0, captureEvent.getData().length); imageOutput.close(); this.getFiles().add(uFile); } catch (Exception ex) { CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void listener(FileUploadEvent event) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(event.getUploadedFile().getName(), event.getUploadedFile().getName(), event.getUploadedFile().getContentType(), event.getUploadedFile().getSize(), (this.isUseData() ? event.getUploadedFile().getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileUtils.writeByteArrayToFile(new File(this.getBaseDestination() + this.getDestination() + uFile.getName()), event.getUploadedFile().getData()); this.getFiles().add(uFile); this.setMaxFilesQuantity(this.getMaxFilesQuantity() - 1); } catch (Exception ex) { ex.printStackTrace(); CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void doShow() { this.setVisible(true); } public void doClear() { this.setVisible(false); this.setImmediateUpload(false); this.setAllowFlash(false); this.setAutoFinish(false); this.setAutoClose(false); this.setGenerateName(true); this.setUseData(false); this.setAcceptedTypes(null); this.setMaxFilesQuantity(null); this.setDestination(null); this.setNamePrefix(null); this.setFiles(null); } public void doUpload() { if (this.getHasFiles()) { ZMNCoreMBeanUtilities.getCoreSUMBean().doUploadMaintenance(this.getDesName()); this.doClear(); } else { FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, ZMNCoreMBeanUtilities.getBundleMessage("cmn", "lbl.operation.warning"), ZMNCoreMBeanUtilities.getBundleMessage("cmn", "msg.operation.canceled"))); } } /** Managed Getters **/ public String getBaseDestination() { return this.isBaseTemporary() ? ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.TEMPORARY).getValue() : ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.RESOURCES).getValue(); } /** Getters **/ public ZMNCoreUFDTO getFile(int index) { return this.getHasFiles() ? ((ArrayList) this.getFiles()).get(index) : null; } public boolean getHasFiles() { return this.getFiles().size() > 0; } public boolean getHasRender() { return StringUtils.isNotBlank(this.getRender()); } public boolean getHasNamePrefix() { return StringUtils.isNotBlank(this.getNamePrefix()); } /** Getters Setters **/ public boolean isImmediateUpload() { return immediateUpload; } public void setImmediateUpload(boolean immediateUpload) { this.immediateUpload = immediateUpload; } public boolean isAllowFlash() { return allowFlash; } public void setAllowFlash(boolean allowFlash) { this.allowFlash = allowFlash; } public boolean isGenerateName() { return generateName; } public void setGenerateName(boolean generateName) { this.generateName = generateName; } public boolean isUseData() { return useData; } public void setUseData(boolean useData) { this.useData = useData; } public Integer getMaxFilesQuantity() { return maxFilesQuantity != null ? maxFilesQuantity : (maxFilesQuantity = 1); } public void setMaxFilesQuantity(Integer maxFilesQuantity) { this.maxFilesQuantity = maxFilesQuantity; } public String getNamePrefix() { return namePrefix; } public void setNamePrefix(String namePrefix) { this.namePrefix = namePrefix; } public String getAcceptedTypes() { return acceptedTypes != null ? acceptedTypes : (acceptedTypes = "jpg, gif, png"); } public void setAcceptedTypes(String acceptedTypes) { this.acceptedTypes = acceptedTypes; } public String getDestination() { return destination != null ? (destination + "/") : (destination = ""); } public void setDestination(String destination) { this.destination = destination; } public Collection getFiles() { return files != null ? files : (files = new ArrayList()); } public void setFiles(Collection files) { this.files = files; } public boolean isBaseTemporary() { return baseTemporary; } public void setBaseTemporary(boolean baseTemporary) { this.baseTemporary = baseTemporary; } public boolean isVisible() { return visible; } public void setVisible(boolean visible) { this.visible = visible; } public boolean isAutoClose() { return autoClose; } public void setAutoClose(boolean autoClose) { this.autoClose = autoClose; } public String getRender() { return render; } public void setRender(String render) { this.render = render; } public boolean isAutoFinish() { return autoFinish; } public void setAutoFinish(boolean autoFinish) { this.autoFinish = autoFinish; } public String getDesName() { return desName; } public void setDesName(String desName) { this.desName = desName; } } {code} was (Author: sdk): MY FILEUPLOAD MBEAN CODE --------------------------------------------------------------------------------------------- package mdb.dev.ZMN.core.mbean.UF; import java.io.File; import java.io.Serializable; import java.util.ArrayList; import java.util.Collection; import javax.faces.application.FacesMessage; import javax.faces.bean.ManagedBean; import javax.faces.bean.SessionScoped; import javax.faces.context.FacesContext; import javax.imageio.stream.FileImageOutputStream; import mdb.cmn.base.configure.utilities.CMNBaseConfigureUtilities; import mdb.cmn.base.mbean.CMNBaseMBean; import mdb.cmn.utilities.log.CMNLogUtilities; import mdb.cmn.utilities.system.CMNSystemUtilities; import mdb.dev.ZMN.core.constants.ZMNCoreConstants; import mdb.dev.ZMN.core.mbean.UF.DTO.ZMNCoreUFDTO; import mdb.dev.ZMN.core.mbean.utilities.ZMNCoreMBeanUtilities; import mdb.dev.ZMN.core.utilities.configure.ZMNCoreConfigureUtilities; import org.apache.commons.io.FileUtils; import org.apache.commons.lang3.StringUtils; import org.primefaces.event.CaptureEvent; import org.richfaces.event.FileUploadEvent; /** * * @author Byambasuren.MD * **/ @SuppressWarnings("serial") @SessionScoped @ManagedBean(name = "CoreUFMBean") public class ZMNCoreUFMBean extends CMNBaseMBean implements Serializable, ZMNCoreConstants { private boolean immediateUpload = false, allowFlash = false, autoClose = false, generateName = true, useData = false, autoFinish = false, baseTemporary = false; private Integer maxFilesQuantity; private String acceptedTypes, destination; private String render, desName, namePrefix; private Collection files; private boolean visible; public ZMNCoreUFMBean() { super(); } /** MBean Utilities **/ public void doSetXUIMaintenance() { } public void doRTEMaintenance(String desName) { } public void doUploadMaintenance(String desName) { } public CMNBaseConfigureUtilities getConfigure() { return ZMNCoreConfigureUtilities.getInstance(); } /** Utilities **/ public void onCapture(CaptureEvent captureEvent) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(null, null, null, captureEvent.getData().length, (this.isUseData() ? captureEvent.getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null, "png"); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileImageOutputStream imageOutput; imageOutput = new FileImageOutputStream(new File(this.getBaseDestination() + this.getDestination() + uFile.getName())); imageOutput.write(captureEvent.getData(), 0, captureEvent.getData().length); imageOutput.close(); this.getFiles().add(uFile); } catch (Exception ex) { CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void listener(FileUploadEvent event) { try { ZMNCoreUFDTO uFile = new ZMNCoreUFDTO(event.getUploadedFile().getName(), event.getUploadedFile().getName(), event.getUploadedFile().getContentType(), event.getUploadedFile().getSize(), (this.isUseData() ? event.getUploadedFile().getData() : null)); if (this.isGenerateName()) { uFile.doGenerateName(this.getHasNamePrefix() ? (this.getNamePrefix()) : null); } else if (this.getHasNamePrefix()) { uFile.setName(this.getNamePrefix() + "_" + uFile.getName()); } if (!new File(this.getBaseDestination() + this.getDestination()).exists()) CMNSystemUtilities.createDir(this.getBaseDestination() + this.getDestination()); FileUtils.writeByteArrayToFile(new File(this.getBaseDestination() + this.getDestination() + uFile.getName()), event.getUploadedFile().getData()); this.getFiles().add(uFile); this.setMaxFilesQuantity(this.getMaxFilesQuantity() - 1); } catch (Exception ex) { ex.printStackTrace(); CMNLogUtilities.fatal("core", "UnSuccessful Upload File", ex); } } public void doShow() { this.setVisible(true); } public void doClear() { this.setVisible(false); this.setImmediateUpload(false); this.setAllowFlash(false); this.setAutoFinish(false); this.setAutoClose(false); this.setGenerateName(true); this.setUseData(false); this.setAcceptedTypes(null); this.setMaxFilesQuantity(null); this.setDestination(null); this.setNamePrefix(null); this.setFiles(null); } public void doUpload() { if (this.getHasFiles()) { ZMNCoreMBeanUtilities.getCoreSUMBean().doUploadMaintenance(this.getDesName()); this.doClear(); } else { FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, ZMNCoreMBeanUtilities.getBundleMessage("cmn", "lbl.operation.warning"), ZMNCoreMBeanUtilities.getBundleMessage("cmn", "msg.operation.canceled"))); } } /** Managed Getters **/ public String getBaseDestination() { return this.isBaseTemporary() ? ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.TEMPORARY).getValue() : ZMNCoreConfigureUtilities.getInstance().getCMNSetting(CMN.SETTING.PATH.RESOURCES).getValue(); } /** Getters **/ public ZMNCoreUFDTO getFile(int index) { return this.getHasFiles() ? ((ArrayList) this.getFiles()).get(index) : null; } public boolean getHasFiles() { return this.getFiles().size() > 0; } public boolean getHasRender() { return StringUtils.isNotBlank(this.getRender()); } public boolean getHasNamePrefix() { return StringUtils.isNotBlank(this.getNamePrefix()); } /** Getters Setters **/ public boolean isImmediateUpload() { return immediateUpload; } public void setImmediateUpload(boolean immediateUpload) { this.immediateUpload = immediateUpload; } public boolean isAllowFlash() { return allowFlash; } public void setAllowFlash(boolean allowFlash) { this.allowFlash = allowFlash; } public boolean isGenerateName() { return generateName; } public void setGenerateName(boolean generateName) { this.generateName = generateName; } public boolean isUseData() { return useData; } public void setUseData(boolean useData) { this.useData = useData; } public Integer getMaxFilesQuantity() { return maxFilesQuantity != null ? maxFilesQuantity : (maxFilesQuantity = 1); } public void setMaxFilesQuantity(Integer maxFilesQuantity) { this.maxFilesQuantity = maxFilesQuantity; } public String getNamePrefix() { return namePrefix; } public void setNamePrefix(String namePrefix) { this.namePrefix = namePrefix; } public String getAcceptedTypes() { return acceptedTypes != null ? acceptedTypes : (acceptedTypes = "jpg, gif, png"); } public void setAcceptedTypes(String acceptedTypes) { this.acceptedTypes = acceptedTypes; } public String getDestination() { return destination != null ? (destination + "/") : (destination = ""); } public void setDestination(String destination) { this.destination = destination; } public Collection getFiles() { return files != null ? files : (files = new ArrayList()); } public void setFiles(Collection files) { this.files = files; } public boolean isBaseTemporary() { return baseTemporary; } public void setBaseTemporary(boolean baseTemporary) { this.baseTemporary = baseTemporary; } public boolean isVisible() { return visible; } public void setVisible(boolean visible) { this.visible = visible; } public boolean isAutoClose() { return autoClose; } public void setAutoClose(boolean autoClose) { this.autoClose = autoClose; } public String getRender() { return render; } public void setRender(String render) { this.render = render; } public boolean isAutoFinish() { return autoFinish; } public void setAutoFinish(boolean autoFinish) { this.autoFinish = autoFinish; } public String getDesName() { return desName; } public void setDesName(String desName) { this.desName = desName; } } > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:29:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:29:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982261#comment-12982261 ] Brian Leathem edited comment on RF-13712 at 7/4/14 11:28 AM: ------------------------------------------------------------- MY FILE UPLOAD XHTML PAGE CODE ---- {code}
{code} was (Author: sdk): MY FILE UPLOAD XHTML PAGE CODE --------------------------------------------------------------
> FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:31:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982418#comment-12982418 ] Brian Leathem commented on RF-13712: ------------------------------------ >From your stacktraces and facelet files, it seems as though you are using a mix of RichFaces, PrimeFaces, and OmniFaces. Please check whether you can reproduce this issue with RichFaes alone. This will tell us whether we have a problem with our Fileupload component, or whether there is an interop problem with the other libraries. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:31:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13712: ------------------------------- Labels: waiting_on_user (was: ) > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:31:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:31:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reopened RF-13712: -------------------------------- > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:33:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13713: ------------------------------- Affects Version/s: 4.5.0.Alpha3 (was: 4.5.0.Alpha2) > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha2 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:33:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13713: ------------------------------- Fix Version/s: 4.5.0.Alpha3 (was: 4.5.0.Alpha2) > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha3 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:33:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13714: ---------------------------------- Assignee: Pavol Pitonak QE please verify > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Assignee: Pavol Pitonak > Labels: dropDownMenu, tabPanel > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:35:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:35:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13706: ------------------------------- Fix Version/s: 4.5.0.Alpha3 > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:35:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:35:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13706: ------------------------------- Fix Version/s: 4.3.8 > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Brian Leathem > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:59:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:59:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13701) RF 4.5 Bar chart plotClick malfunctioning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13701. -------------------------------- Resolution: Done Replaced the xaxis.ticks lookup to use the dataIndex instead of the seriesIndex > RF 4.5 Bar chart plotClick malfunctioning > ----------------------------------------- > > Key: RF-13701 > URL: https://issues.jboss.org/browse/RF-13701 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > When interacting with bar chart where {{onplotclick}} and {{plotClickListener}} are set, it does not react when last bar in the series is clicked (eg .no request is sent for server side event and no JS executed for onplotclick). See steps to reproduce, in case they are not clear ask me for more details. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:59:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 11:59:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13675) Showcase: chart component improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13675: ------------------------------- Description: The chart sample on the showcase needs some descriptive text. > Showcase: chart component improvements > -------------------------------------- > > Key: RF-13675 > URL: https://issues.jboss.org/browse/RF-13675 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Luk?? Macko > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The chart sample on the showcase needs some descriptive text. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 12:15:28 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 12:15:28 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13675) Showcase: chart component improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13675. -------------------------------- Resolution: Done > Showcase: chart component improvements > -------------------------------------- > > Key: RF-13675 > URL: https://issues.jboss.org/browse/RF-13675 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Luk?? Macko > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The chart sample on the showcase needs some descriptive text. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 12:41:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 12:41:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13585) Re-factor the components demo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982435#comment-12982435 ] Brian Leathem commented on RF-13585: ------------------------------------ I've removed the dependency management from the components-demo POM altogether as I believe it is redundant. A {{mvn clean verify}} build of the components-demo is successful after removing the dependency management. > Re-factor the components demo > ----------------------------- > > Key: RF-13585 > URL: https://issues.jboss.org/browse/RF-13585 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Re-factor the components demo to work with RichFaces 4.5 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 12:53:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 12:53:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13585) Re-factor the components demo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13585. -------------------------------- Resolution: Done I've fixed the reported issues. Yes, the components-demo samples _should_ all work. *However* it is not a priority at this time to run through them all and verify/resolve them. > Re-factor the components demo > ----------------------------- > > Key: RF-13585 > URL: https://issues.jboss.org/browse/RF-13585 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Re-factor the components demo to work with RichFaces 4.5 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 12:55:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 12:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13687: ---------------------------------- Assignee: Brian Leathem > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 13:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 13:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13682: ---------------------------------- Assignee: Brian Leathem > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 14:31:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 14:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13673. -------------------------------- Resolution: Done > Backport the plain skin fix from RF 5 > ------------------------------------- > > Key: RF-13673 > URL: https://issues.jboss.org/browse/RF-13673 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: skinning > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Backport RF-11103. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 14:51:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 14:51:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13107) ajaxRenderer component are rendered even though they are in non-active switchable panel, causing JSF to fail to update DOM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13107: ------------------------------- Summary: ajaxRenderer component are rendered even though they are in non-active switchable panel, causing JSF to fail to update DOM (was: ajaxRenderer component are renderer even though they are in non-active switchable panel, causing JSF to fail to update DOM) > ajaxRenderer component are rendered even though they are in non-active switchable panel, causing JSF to fail to update DOM > -------------------------------------------------------------------------------------------------------------------------- > > Key: RF-13107 > URL: https://issues.jboss.org/browse/RF-13107 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.3.2 > Reporter: Jon?? Trantina > Assignee: Luk?? Fry? > Fix For: 4.3.4 > > Attachments: bug_reproducer.zip, reproducer_ajax.zip, rf13107ajax.png > > Original Estimate: 1 hour, 30 minutes > Remaining Estimate: 1 hour, 30 minutes > > We have a form with a tabPanel component with two tabs A and B. In A there is an input and its rich:message in B the same plus a button that submits and re-renders B. When B is opened (thus A is not rendered) and the form is submitted and validation fails, then no message is shown. > Note that: > 1) switchType must be set to server to ensure the A's rich:message is really not on the page. > 2) button in B must re-render only content of B > This is only a specific scenario, the issue might occur also in other situations (e.g. global messages tag outside of tabPanel is not rendered). > Please find the enclosed reproducer. > Snipper: > {code:xml} > > > > > > > > > > > > > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 16:39:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 16:39:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982454#comment-12982454 ] Brian Leathem commented on RF-13687: ------------------------------------ Looking at the generated HTML: {code} ... 5 clicks 0 clicks 0 clicks ... {code} One can see that the label attribute is rendered 3 times: once for each of the _active_, _inactive_, and _disabled_ tab headers. Only one of the rendered DOM nodes is getting updated with the new value. This is likely due to the repetition of the {{id}} attribute amongst the three rendered DOM nodes. This is incorrect HTML, and as such the behaviour is unspecified. Proper resolution of this issue will involve properly dealing with the active/inactive/disabled tab headers and rendering each tab header only a single time. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 22:41:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 4 Jul 2014 22:41:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13687. -------------------------------- Labels: needs-qe (was: ) Resolution: Done Rewrote the client-side tab selection to require only a single rendering of the tab headers. This required explicitly triggering the tab at header meta component be rendered when the active tab is changed. @QE: this is a significant change for the tab/tabPanel components. Please be appropriately rigorous in your QA. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 04:52:25 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Mon, 7 Jul 2014 04:52:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982540#comment-12982540 ] Michal Petrov commented on RF-13708: ------------------------------------ The binding was created for RF-13492, I need access to the trees to reset their selection. I'll check if there is a way around it. > Photoalbum: refresh over index page throws error > ------------------------------------------------ > > Key: RF-13708 > URL: https://issues.jboss.org/browse/RF-13708 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.6, 4.3.7, 4.3.8 > Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well > browsers: all > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.5-Tracking > > > Refresh over index page of Photoalbum throws: > {code} > 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} > After this error application cease to work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 05:44:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Mon, 7 Jul 2014 05:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13714: ------------------------------- Attachment: tabPanel.png > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Assignee: Pavol Pitonak > Labels: dropDownMenu, tabPanel > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 05:44:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Mon, 7 Jul 2014 05:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13714: ------------------------------- Assignee: (was: Pavol Pitonak) > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 05:46:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Mon, 7 Jul 2014 05:46:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982555#comment-12982555 ] Pavol Pitonak commented on RF-13714: ------------------------------------ I could reproduce with 4.3.8-SNAPSHOT (see attached screenshot). Do we want to support this use-case? > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 06:34:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Mon, 7 Jul 2014 06:34:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982580#comment-12982580 ] Martin H?ller commented on RF-13714: ------------------------------------ Why would you not want to support it? It could be used like a context menu for every tab which is very useful! What are the reasons against it? > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 07:18:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 7 Jul 2014 07:18:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned RF-13687: -------------------------------- Assignee: Juraj H?ska (was: Brian Leathem) > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 07:40:25 2014 From: issues at jboss.org (Patrik Dudits (JIRA)) Date: Mon, 7 Jul 2014 07:40:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982594#comment-12982594 ] Patrik Dudits commented on RF-12108: ------------------------------------ We've hit this issue in combination with {{collapsiblePanel}}, but even without explicit {{ajaxRendered="true"}}. However, setting {{ajaxRendered="false"}} on message component was a viable workaround. My understanding of the cause is, that a partial update for the `message` component is sent out, but but the component has been *removed* from the DOM by parent container - be it tabs, collapsible panel, or whatever that removes DOM nodes. Therefore I think that `message` needs to better reckognize if it is present at client side, even if it may appear that it is rendered in the view tree. > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 07:42:30 2014 From: issues at jboss.org (Patrik Dudits (JIRA)) Date: Mon, 7 Jul 2014 07:42:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982594#comment-12982594 ] Patrik Dudits edited comment on RF-12108 at 7/7/14 7:40 AM: ------------------------------------------------------------ We've hit this issue in combination with {{collapsiblePanel}}, but even without explicit {{ajaxRendered="true"}}. However, setting {{ajaxRendered="false"}} on message component was a viable workaround. My understanding of the cause is, that a partial update for the {{message}} component is sent out, but but the component has been *removed* from the DOM by parent container - be it tabs, collapsible panel, or whatever that removes DOM nodes. Therefore I think that {{message}} needs to better reckognize if it is present at client side, even if it may appear that it is rendered in the view tree. was (Author: pdudits): We've hit this issue in combination with {{collapsiblePanel}}, but even without explicit {{ajaxRendered="true"}}. However, setting {{ajaxRendered="false"}} on message component was a viable workaround. My understanding of the cause is, that a partial update for the `message` component is sent out, but but the component has been *removed* from the DOM by parent container - be it tabs, collapsible panel, or whatever that removes DOM nodes. Therefore I think that `message` needs to better reckognize if it is present at client side, even if it may appear that it is rendered in the view tree. > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 07:42:33 2014 From: issues at jboss.org (Patrick Schmidt (JIRA)) Date: Mon, 7 Jul 2014 07:42:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982598#comment-12982598 ] Patrick Schmidt commented on RF-12108: -------------------------------------- METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 07:44:25 2014 From: issues at jboss.org (Patrick Schmidt (JIRA)) Date: Mon, 7 Jul 2014 07:44:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982599#comment-12982599 ] Patrick Schmidt commented on RF-12108: -------------------------------------- METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 08:56:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Mon, 7 Jul 2014 08:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982626#comment-12982626 ] Martin H?ller commented on RF-13714: ------------------------------------ BTW, what exactly does your screenshot show? The lower part shows the menu-item, so it looks like it is working for you? Where did you place the menu and which action does open it? This was NOT working for me. Did I get you wrong? > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:32:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 12:32:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982720#comment-12982720 ] Brian Leathem commented on RF-11782: ------------------------------------ [~ppitonak] I believe this issue should now be out-of-date. Can you confirm? > [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" > ---------------------------------------------------------------------------- > > Key: RF-11782 > URL: https://issues.jboss.org/browse/RF-11782 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.CR1 > Environment: mojarra-2.1.4, RF-CR1 > Reporter: Rene O > Assignee: Brian Leathem > Labels: lazy-loaded > Fix For: 5-Tracking > > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached: > http://localhost:8080/jsf2testcase/tabswitchtest.jsf > Steps to reproduce the issue: > 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB > 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table > {code:title=xhtml} > ... > > > > Here is tab #1 > > > > > > List A > > > > > > > > > > List B > > > > > > > > ... > {code} > {code:title=java} > ... > public List getTestListA() { > System.out.println("getTestListA"); > return testListA; > } > ... > public List getTestListB() { > System.out.println("getTestListB"); > return testListB; > } > ... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:36:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 12:36:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982722#comment-12982722 ] Brian Leathem commented on RF-13714: ------------------------------------ This is similar to RF-11814. So long as the tabPanel is using {{switchType=client}} I would consider it a supported use case. > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Fix For: 4.5-Tracking > > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:36:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 12:36:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13714: ------------------------------- Fix Version/s: 4.5-Tracking > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Fix For: 4.5-Tracking > > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:04:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 13:04:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Comment: was deleted (was: METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). ) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:04:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 13:04:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Comment: was deleted (was: METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). ) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:08:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 13:08:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982738#comment-12982738 ] Brian Leathem commented on RF-12108: ------------------------------------ This may be resolved by the pull request for RF-13706. > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:06:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 14:06:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13706: ------------------------------- Assignee: Marcel Kolsteren (was: Brian Leathem) > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:08:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 14:08:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Fix Version/s: 4.5-Tracking (was: 5-Tracking) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:08:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 14:08:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-12108: ---------------------------------- Assignee: Pavol Pitonak QE, please re-verify this in RichFaces 4.5 now that RF-13706 has been resolved. > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Pavol Pitonak > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:08:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 14:08:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13706: ------------------------------- Original Estimate: 1 hour Remaining Estimate: 1 hour Sprint: 4.5.0.Alpha3 - Sprint 5 > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:20:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 14:20:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982762#comment-12982762 ] Brian Leathem commented on RF-13682: ------------------------------------ [~tony.cramer] / [~jhuska] given that this is only a problem when {{h:commandButton}} is used, are you able to reproduce this behaviour with a standalone JSF application (without RichFaces present on the class path?) > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:30:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:30:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982812#comment-12982812 ] Brian Leathem commented on RF-13706: ------------------------------------ [~marcelkolsteren] I forgot to ask, can you sign the JBoss CLA? https://cla.jboss.org/index.seam Thanks! > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:32:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:32:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982813#comment-12982813 ] Brian Leathem commented on RF-11093: ------------------------------------ Thanks Yannick, I reviewed the pull request, it looks good. Can you please sign the JBoss CLA? https://cla.jboss.org/index.seam > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Fix For: 5-Future > > Attachments: UIDataAdaptor.java.patch > > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:36:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:36:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11093: ------------------------------- Fix Version/s: 4.5.0.Alpha3 (was: 5-Future) > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:38:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11093: ------------------------------- Original Estimate: 1 hour Remaining Estimate: 1 hour Sprint: 4.5.0.Alpha3 - Sprint 5 > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:40:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11093: ------------------------------- Assignee: Yannick Valot > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:42:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:42:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982815#comment-12982815 ] Brian Leathem commented on RF-13691: ------------------------------------ I have tested that this issue is obsolete with the PR in RF-11093. I will merge that PR shortly at which point I will mark this issue as resolved. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:42:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:42:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982816#comment-12982816 ] Brian Leathem commented on RF-13690: ------------------------------------ I have tested that this issue is obsolete with the PR in RF-11093. I will merge that PR shortly at which point I will mark this issue as resolved. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:44:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13690: ---------------------------------- Assignee: Brian Leathem > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:44:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13691: ---------------------------------- Assignee: Brian Leathem > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 17:44:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 17:44:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13692) Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13692: ---------------------------------- Assignee: Michal Petrov > Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception > ------------------------------------------------------------------------------ > > Key: RF-13692 > URL: https://issues.jboss.org/browse/RF-13692 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is an error during deployment of Photoalbum example on WildFly 8.1.0.Final or 8.0.0.Final > {code} > 09:28:51,675 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization > at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:159) > at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:91) > at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215) > at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208) > 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:606) > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232) > at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169) > at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {code} > and > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."richfaces-photoalbum.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 23 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 22 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.VIEW."org.richfaces.photoalbum.model.actions.IAlbumAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.VIEW."org.richfaces.photoalbum.model.actions.IEventAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.VIEW."org.richfaces.photoalbum.model.actions.IImageAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.VIEW."org.richfaces.photoalbum.search.ISearchAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.VIEW."org.richfaces.photoalbum.model.actions.IShelfAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.VIEW."org.richfaces.photoalbum.model.actions.IUserAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START, JBAS014799: ... and 16 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START, JBAS014799: ... and 4 more ] > service jboss.persistenceunit."richfaces-photoalbum.war#photoAlbum" (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService, JBAS014799: ... and 13 more ] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > {code} > Note that it *works* on EAP 6.2.3.GA and EAP 6.3.0.ER8 > Both WildFly containers use Weld 2.1.x, so it is not a problem with Weld 2.2.x integration. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 20:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 20:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982830#comment-12982830 ] Brian Leathem commented on RF-13682: ------------------------------------ On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html. Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jbossorg-1/jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java#L82]_: {code} public boolean isPostback(FacesContext context) { return context.getExternalContext().getRequestParameterMap(). containsKey(ResponseStateManager.VIEW_STATE_PARAM); } {code} The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093. [~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093? > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 20:05:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 7 Jul 2014 20:05:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13682: ------------------------------- Comment: was deleted (was: [~tony.cramer] / [~jhuska] given that this is only a problem when {{h:commandButton}} is used, are you able to reproduce this behaviour with a standalone JSF application (without RichFaces present on the class path?)) > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 03:03:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Tue, 8 Jul 2014 03:03:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982877#comment-12982877 ] Martin H?ller commented on RF-13714: ------------------------------------ Hm, maybe I should explain my use-case in more detail, because I don't really see why this should be limited to client-switchType. What I want is a , where every tab has a header-text and an additional menu-icon (just like Firefox' tabs but with a menu-icon instead of the close-icon). Clicking the header-text switches the tab, regardless of the switchType. Clicking the menu-icon opens the menu with its menuItems. No tab-switching should take place when the menu is opened or a a menuItem is clicked. This was possible with RF3. > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Fix For: 4.5-Tracking > > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 03:11:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 8 Jul 2014 03:11:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reopened RF-13706: -------------------------------- [~bleathem], the last commit breaks unit tests in core module: {code} Failed tests: QUnitTest.testEvent:123->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testQueueSubmitFirst:153->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testBaseComponent:158->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testQueueGetSize:138->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testQueueClear:148->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testQueueEmpty:143->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testPosition:128->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) QUnitTest.testQueueRequest:133->runTest:62->runTest:101 Failures: 33. richfaces-queue-request 1. failedExpected: 500Result: 1500Diff: 500 1500 3. newTime2 is undefined User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) Tests run: 237, Failures: 8, Errors: 0, Skipped: 2 {code} > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 03:39:24 2014 From: issues at jboss.org (=?UTF-8?Q?Martin_H=C3=B6ller_=28JIRA=29?=) Date: Tue, 8 Jul 2014 03:39:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: Martin H?ller created RF-13715: ---------------------------------- Summary: not working inside header facet Key: RF-13715 URL: https://issues.jboss.org/browse/RF-13715 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-output Affects Versions: 4.3.7 Environment: Firefox 26, Chromium 31, Opera 12.16 Reporter: Martin H?ller A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: {code:xml} myTab some tooltip tab content {code} The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 04:26:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 8 Jul 2014 04:26:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982899#comment-12982899 ] Pavol Pitonak commented on RF-11782: ------------------------------------ No, it still doesn't work in 4.5.0-SNAPSHOT. > [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" > ---------------------------------------------------------------------------- > > Key: RF-11782 > URL: https://issues.jboss.org/browse/RF-11782 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.CR1 > Environment: mojarra-2.1.4, RF-CR1 > Reporter: Rene O > Assignee: Brian Leathem > Labels: lazy-loaded > Fix For: 5-Tracking > > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached: > http://localhost:8080/jsf2testcase/tabswitchtest.jsf > Steps to reproduce the issue: > 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB > 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table > {code:title=xhtml} > ... > > > > Here is tab #1 > > > > > > List A > > > > > > > > > > List B > > > > > > > > ... > {code} > {code:title=java} > ... > public List getTestListA() { > System.out.println("getTestListA"); > return testListA; > } > ... > public List getTestListB() { > System.out.println("getTestListB"); > return testListB; > } > ... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 07:24:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 8 Jul 2014 07:24:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12674) Write framework tests for Autocomplete tokenizing feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reassigned RF-12674: ---------------------------------- Assignee: Martin Tomasek (was: Juraj H?ska) > Write framework tests for Autocomplete tokenizing feature > --------------------------------------------------------- > > Key: RF-12674 > URL: https://issues.jboss.org/browse/RF-12674 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.3.0.M3 > Reporter: Luk?? Fry? > Assignee: Martin Tomasek > Fix For: 5-Tracking > > > According to RF-12664 and meeting discussion, > the new tests should be introduced to cover Autocomplete tokenizing feature by fundamental tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:03:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 11:03:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983183#comment-12983183 ] Brian Leathem commented on RF-11093: ------------------------------------ I adapted the PR to the correct repo with this commit: https://github.com/richfaces/richfaces/commit/a5ee6651647f2f07ca89aca6946d3f7b79d967ea Thanks for following up on this patch [~yvalot]! > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:09:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 11:09:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13690. -------------------------------- Resolution: Done > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:09:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 11:09:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13691. -------------------------------- Resolution: Done > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:17:25 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Tue, 8 Jul 2014 11:17:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13678) Render @all does not work for nested a4j:region in collapsibleSubTable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13678. -------------------------------- Resolution: Duplicate Issue Resolving as duplicate, pull request from RF-11093 did fix the issue. > Render @all does not work for nested a4j:region in collapsibleSubTable > ---------------------------------------------------------------------- > > Key: RF-13678 > URL: https://issues.jboss.org/browse/RF-13678 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Suppose nested {{regions}} in a {{collapsibleSubTable}}. > Those regions are not updated when a {{commandButton}} with {{render}} attribute set to {{@all}} is submitted. > IMHO it is somehow connected with RF-13677, however, this issue occurs only with combination of {{regions}} and {{collapsibleSubTable}}, other iteration components works in this matter. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 15:38:25 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Tue, 8 Jul 2014 15:38:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983286#comment-12983286 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once. I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related test tend to have a bigger chance of being unstable themselves. So my question is: is the failure of this unit test reproducible? > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 15:38:25 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Tue, 8 Jul 2014 15:38:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983286#comment-12983286 ] Marcel Kolsteren edited comment on RF-13706 at 7/8/14 3:37 PM: --------------------------------------------------------------- I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once. I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related tests tend to have a bigger chance of being unstable themselves. So my question is: is the failure of this unit test reproducible? was (Author: marcelkolsteren): I remember vaguely that by the time I was developing the fix, I saw this unit test failing, but it failed only once. I just cloned the latest version of the core module, with my fix inside, and I ran "mvn install" 5 times, without any unit test failing. When looking at the test (QUnitTest#testQueueRequest), I see that it is checking the timing of Ajax requests. Timing related test tend to have a bigger chance of being unstable themselves. So my question is: is the failure of this unit test reproducible? > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 16:06:24 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Tue, 8 Jul 2014 16:06:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983291#comment-12983291 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- I just signed a JBoss CLA for contributing to RichFaces. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 20:38:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 20:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982830#comment-12982830 ] Brian Leathem edited comment on RF-13682 at 7/8/14 8:37 PM: ------------------------------------------------------------ Disregard the comment below, I was confused. I have since found a resolution to the issue. I will delete this comment since it adds nothing of value to the conversation. ---- On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html. Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jbossorg-1/jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java#L82]_: {code} public boolean isPostback(FacesContext context) { return context.getExternalContext().getRequestParameterMap(). containsKey(ResponseStateManager.VIEW_STATE_PARAM); } {code} The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093. [~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093? was (Author: bleathem): On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html. Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jbossorg-1/jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java#L82]_: {code} public boolean isPostback(FacesContext context) { return context.getExternalContext().getRequestParameterMap(). containsKey(ResponseStateManager.VIEW_STATE_PARAM); } {code} The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093. [~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093? > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 20:38:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 20:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13682: ------------------------------- Comment: was deleted (was: Disregard the comment below, I was confused. I have since found a resolution to the issue. I will delete this comment since it adds nothing of value to the conversation. ---- On further investigation, it seems that the _RestoreViewPhase#execute_ method believes the submission is a _postback_. The view is then not created anew, despite the subsequemt response consisting of the full page html. Whether or not the submission is a _postback_ is determined by the _[ResponseStateManagerImpl|https://github.com/jboss/mojarra/blob/2.2.7-jbossorg-1/jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java#L82]_: {code} public boolean isPostback(FacesContext context) { return context.getExternalContext().getRequestParameterMap(). containsKey(ResponseStateManager.VIEW_STATE_PARAM); } {code} The _requestParameterMap_ contains the {{VIEW_STATE_PARAM}} value _stateless_. It seems this was added in RF-13093. [~lfryc] can you comment on the addition of this request parameter? Since it's causing difficulties elsewhere, can you suggest an alternate resolution for RF-13093?) > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 20:40:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 20:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13682. -------------------------------- Labels: needs-qe (was: ) Resolution: Done Changed the GlobalResourcesViewHandler to add the skinning resources during the restoreView, instead of only during the createView. > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 21:31:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 21:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983326#comment-12983326 ] Brian Leathem commented on RF-13706: ------------------------------------ Thanks [~marcelkolsteren] for signing the CLA. The unit tests fail pretty consistently on my machine. The tests are indeed timing related. It occurs to me that by removing entries from the top of the queue we are messing with the _requestDelay_ that a user might set. I am able to avoid this problem (and get the unit tests to pass) if I change the attached patch to: {code} var removeStaleEntriesFromQueue = function () { var entry; var foundValidEntry = false; while (items.length > 0 && !foundValidEntry) { entry = items[0]; if (entry.getReadyToSubmit() === true) { var element = richfaces.getDomElement(entry.source); if (element == null || $(element).closest("form").length == 0) { items.shift(); richfaces.log.debug("richfaces.queue: removing stale entry from the queue (source element: " + element + ")"); } else { foundValidEntry = true; } } else { foundValidEntry = true; } } } {code} Note: the check to see if the entry is readyToSubmit prior to removing the entry. [~ppitonak]: this is precisely why I asked QE to verify this PR was stable prior to merging the PR. Unit tests should be part of our QA verification process. (Ideally we would have a CI tool that verified PRs, like travis-ci) > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 21:33:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 8 Jul 2014 21:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13706. -------------------------------- Resolution: Done > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 03:14:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 03:14:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13701) RF 4.5 Bar chart plotClick malfunctioning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13701. ------------------------------ Verified, clicking any plot now fires an event. Closing issue. > RF 4.5 Bar chart plotClick malfunctioning > ----------------------------------------- > > Key: RF-13701 > URL: https://issues.jboss.org/browse/RF-13701 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Environment: Wildfly 8.0 > Latest Chrome/FF > Reporter: Matej Novotny > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > When interacting with bar chart where {{onplotclick}} and {{plotClickListener}} are set, it does not react when last bar in the series is clicked (eg .no request is sent for server side event and no JS executed for onplotclick). See steps to reproduce, in case they are not clear ask me for more details. > I created Metamer samples of charts for 4.5.x where this can be tested (only manually for the time being). > This works in RF 5, so this has to be connected to backporting charts component (RF-13583) to 4.5.x. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 03:43:24 2014 From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=) Date: Wed, 9 Jul 2014 03:43:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13585) Re-factor the components demo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ji?? ?tefek closed RF-13585. ---------------------------- Verified, closing. > Re-factor the components demo > ----------------------------- > > Key: RF-13585 > URL: https://issues.jboss.org/browse/RF-13585 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Re-factor the components demo to work with RichFaces 4.5 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 03:59:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 9 Jul 2014 03:59:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983354#comment-12983354 ] Pavol Pitonak commented on RF-13706: ------------------------------------ [~bleathem], we did run all tests we have but we only verified it withc RichFaces 4.3 because PR was created against 4.3 core repository. All tests passed for RichFaces 4.3. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 04:29:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 04:29:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: Matej Novotny created RF-13716: ---------------------------------- Summary: Charts 4.5 Showcase/Metamer a4j:ajax re-render Key: RF-13716 URL: https://issues.jboss.org/browse/RF-13716 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-output, showcase Affects Versions: 4.5.0.Alpha3 Environment: Latest FF/Chrome Wildfly 8.1 Reporter: Matej Novotny The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: {code} // axis settings... {code} With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 04:29:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 04:29:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13716: ------------------------------- Fix Version/s: 4.5.0.Alpha3 > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Fix For: 4.5.0.Alpha3 > > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 04:31:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 04:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983362#comment-12983362 ] Matej Novotny commented on RF-13716: ------------------------------------ [~bleathem] could this be a4j:ajax issue? I am not sure how to verify this but I am sure there was no commit regarding charts which should break this. > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Fix For: 4.5.0.Alpha3 > > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 04:33:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 04:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: Juraj H?ska created RF-13717: -------------------------------- Summary: Some integration tests within components/rich are using wrongly FrameworkDeployment class Key: RF-13717 URL: https://issues.jboss.org/browse/RF-13717 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: tests - functional Affects Versions: 4.5.0.Alpha3 Reporter: Juraj H?ska Priority: Trivial Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 04:44:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 04:44:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned RF-13717: -------------------------------- Assignee: Juraj H?ska > Some integration tests within components/rich are using wrongly FrameworkDeployment class > ----------------------------------------------------------------------------------------- > > Key: RF-13717 > URL: https://issues.jboss.org/browse/RF-13717 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > > Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. > They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:10:24 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 05:10:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13692) Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983376#comment-12983376 ] Michal Petrov commented on RF-13692: ------------------------------------ I've tried running the photoalbum on WildFly 8.0 with the system property, I've fixed the method signature and updated solder to 3.2.1.Final, but now I'm getting this exception: {code} Exception 0 : org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.jboss.solder.servlet.http.RedirectBuilderImpl.request at org.jboss.solder.servlet.http.RedirectBuilderImpl.request(RedirectBuilderImpl.java:0) Possible dependencies: - WELD|AbstractSyntheticBean|richfaces-photoalbum.war/WEB-INF/lib/solder-impl-3.2.1.Final.jar|HttpServletRequest, - Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()] at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:376) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) {code} > Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception > ------------------------------------------------------------------------------ > > Key: RF-13692 > URL: https://issues.jboss.org/browse/RF-13692 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is an error during deployment of Photoalbum example on WildFly 8.1.0.Final or 8.0.0.Final > {code} > 09:28:51,675 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization > at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:159) > at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:91) > at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215) > at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208) > 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:606) > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232) > at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169) > at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {code} > and > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."richfaces-photoalbum.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 23 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 22 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.VIEW."org.richfaces.photoalbum.model.actions.IAlbumAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.VIEW."org.richfaces.photoalbum.model.actions.IEventAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.VIEW."org.richfaces.photoalbum.model.actions.IImageAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.VIEW."org.richfaces.photoalbum.search.ISearchAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.VIEW."org.richfaces.photoalbum.model.actions.IShelfAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.VIEW."org.richfaces.photoalbum.model.actions.IUserAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START, JBAS014799: ... and 16 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START, JBAS014799: ... and 4 more ] > service jboss.persistenceunit."richfaces-photoalbum.war#photoAlbum" (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService, JBAS014799: ... and 13 more ] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > {code} > Note that it *works* on EAP 6.2.3.GA and EAP 6.3.0.ER8 > Both WildFly containers use Weld 2.1.x, so it is not a problem with Weld 2.2.x integration. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:26:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 05:26:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska resolved RF-13717. ------------------------------ Fix Version/s: 4.5.0.Alpha3 Resolution: Done Resolved with this commit: https://github.com/richfaces/richfaces/commit/7318a430ef9aec0c3579a30168a75f9dbc79d4c1 > Some integration tests within components/rich are using wrongly FrameworkDeployment class > ----------------------------------------------------------------------------------------- > > Key: RF-13717 > URL: https://issues.jboss.org/browse/RF-13717 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Alpha3 > > > Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. > They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:30:25 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 05:30:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13717: ----------------------------- Forum Reference: https://community.jboss.org/thread/242312 > Some integration tests within components/rich are using wrongly FrameworkDeployment class > ----------------------------------------------------------------------------------------- > > Key: RF-13717 > URL: https://issues.jboss.org/browse/RF-13717 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Alpha3 > > > Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. > They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:38:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 05:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Affects Version/s: 4.3.8 > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:40:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 05:40:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Workaround Description: As mentioned in description, attribute {{render=idOfComponent}} can be used instead of {{status=idOfComponent}}. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:40:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 05:40:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Workaround Description: As mentioned in description, attribute {{render='idOfComponent'}} can be used instead of {{status='idOfComponent'}}. (was: As mentioned in description, attribute {{render=idOfComponent}} can be used instead of {{status=idOfComponent}}.) > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 05:49:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 05:49:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983397#comment-12983397 ] Matej Novotny commented on RF-13711: ------------------------------------ Sorry for the delay, I finally got to verification. I can reproduce this with 4.3.7 and as well in 4.3.x branch. I will add Metamer page in 4.3.x with this example. The workaround (using {{render}} attribute) works so I have updated the issue with it. [~rustock0] I agree that {{render}} is for different goals and status should be used instead. Thanks for attached sample! > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 06:51:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 06:51:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983397#comment-12983397 ] Matej Novotny edited comment on RF-13711 at 7/9/14 6:51 AM: ------------------------------------------------------------ Sorry for the delay, I finally got to verification. I can reproduce this with 4.3.7 and as well in 4.3.x branch. EDIT: This can be reproduced with 4.5.x as well. I will add Metamer page in 4.3.x (and 4.5.x) with this example. The workaround (using {{render}} attribute) works so I have updated the issue with it. [~rustock0] I agree that {{render}} is for different goals and status should be used instead. Thanks for attached sample! was (Author: manovotn): Sorry for the delay, I finally got to verification. I can reproduce this with 4.3.7 and as well in 4.3.x branch. I will add Metamer page in 4.3.x with this example. The workaround (using {{render}} attribute) works so I have updated the issue with it. [~rustock0] I agree that {{render}} is for different goals and status should be used instead. Thanks for attached sample! > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:02:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 07:02:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983397#comment-12983397 ] Matej Novotny edited comment on RF-13711 at 7/9/14 7:01 AM: ------------------------------------------------------------ Sorry for the delay, I finally got to verification. I can reproduce this with 4.3.7 and as well in 4.3.x branch. EDIT: This can be reproduced with 4.5.x as well. I added Metamer [page in 4.3.x|https://github.com/richfaces/richfaces-qa/blob/4.3.x/metamer/application/src/main/webapp/components/a4jAjax/rf-13711.xhtml] (and [4.5.x|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/a4jAjax/rf-13711.xhtml]) with this example. The workaround (using {{render}} attribute) works so I have updated the issue with it. [~rustock0] I agree that {{render}} is for different goals and status should be used instead. Thanks for attached sample! was (Author: manovotn): Sorry for the delay, I finally got to verification. I can reproduce this with 4.3.7 and as well in 4.3.x branch. EDIT: This can be reproduced with 4.5.x as well. I will add Metamer page in 4.3.x (and 4.5.x) with this example. The workaround (using {{render}} attribute) works so I have updated the issue with it. [~rustock0] I agree that {{render}} is for different goals and status should be used instead. Thanks for attached sample! > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:06:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 07:06:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Steps to Reproduce: * Start JBossAS 7.1 (or for RF 4.5 Wildfly) * Deploy Metamer * Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml] * Open browser console * Click the button ** Expected: Three lines appear in the console: *** {{start}} //triggered by a4j:status *** {{POST...}} //request itself *** {{stop}} //triggered by a4j:status ** Actual: Only request itself is displayed in console > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 08:18:25 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 08:18:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13597) Drag and drop support for file upload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983475#comment-12983475 ] Michal Petrov commented on RF-13597: ------------------------------------ {quote}Regression on Chrome, Safari, Opera 22: after a file (or files) added to upload (dnd/by 'Add' button), the user cannot click on the 'Upload' button, the 'Add' button is clicked instead.{quote} fixed, this was caused by a custom CSS that made the input positioned over the upload button. I made the overflow hidden but I'm not sure if it didn't break the tests. {quote}This DnD feature works well on FF and Safari, where user can drop item on the list of files to upload and also on the 'Add' button. On the other browsers, it works differently: # Chrome, IE 10, IE 11, Opera 22: Items cannot be dropped on the 'Add' button, but can be dropped on the list of files to upload # Opera 12.16: similar to Chrome, but only one item is added to files to upload regardless of how many files were dragged, also there is a prompt window for permitting this action ("Do you want to upload files to ... yes/no"){quote} As mentioned above, ability to drop onto input is up to the browser implementation, unfortunately I cannot do anything about the Opera prompt. {quote}It would be great if items can be dropped also on the FileUpload toolbar{quote} Files can now be dropped anywhere on the component. In Chrome the icon changes when the files are dragged over the component but other browsers don't do that. > Drag and drop support for file upload > ------------------------------------- > > Key: RF-13597 > URL: https://issues.jboss.org/browse/RF-13597 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 4.1.0.Final > Reporter: abhishek vijra > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Drag/Drop support should be added to file upload component . > Like the primefaces fileUploadDnd : http://www.primefaces.org/showcase/ui/fileUploadDnd.jsf -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 08:18:25 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 08:18:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13597) Drag and drop support for file upload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13597. -------------------------------- Resolution: Done > Drag and drop support for file upload > ------------------------------------- > > Key: RF-13597 > URL: https://issues.jboss.org/browse/RF-13597 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 4.1.0.Final > Reporter: abhishek vijra > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Drag/Drop support should be added to file upload component . > Like the primefaces fileUploadDnd : http://www.primefaces.org/showcase/ui/fileUploadDnd.jsf -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 09:40:24 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 09:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13692) Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13692. -------------------------------- Resolution: Done Implemented the workaround from SOLDER-322, there are no more exceptions. > Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception > ------------------------------------------------------------------------------ > > Key: RF-13692 > URL: https://issues.jboss.org/browse/RF-13692 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is an error during deployment of Photoalbum example on WildFly 8.1.0.Final or 8.0.0.Final > {code} > 09:28:51,675 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization > at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:159) > at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:91) > at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215) > at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208) > 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:606) > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232) > at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169) > at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {code} > and > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."richfaces-photoalbum.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 23 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 22 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.VIEW."org.richfaces.photoalbum.model.actions.IAlbumAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.VIEW."org.richfaces.photoalbum.model.actions.IEventAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.VIEW."org.richfaces.photoalbum.model.actions.IImageAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.VIEW."org.richfaces.photoalbum.search.ISearchAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.VIEW."org.richfaces.photoalbum.model.actions.IShelfAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.VIEW."org.richfaces.photoalbum.model.actions.IUserAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START, JBAS014799: ... and 16 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START, JBAS014799: ... and 4 more ] > service jboss.persistenceunit."richfaces-photoalbum.war#photoAlbum" (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService, JBAS014799: ... and 13 more ] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > {code} > Note that it *works* on EAP 6.2.3.GA and EAP 6.3.0.ER8 > Both WildFly containers use Weld 2.1.x, so it is not a problem with Weld 2.2.x integration. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 09:48:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 9 Jul 2014 09:48:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13716: ------------------------------- Priority: Blocker (was: Major) > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Priority: Blocker > Fix For: 4.5.0.Alpha3 > > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 10:04:24 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 10:04:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13707) Photoalbum: incorrect account details shown after creating a new one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13707. -------------------------------- Fix Version/s: 4.3.8 Resolution: Done > Photoalbum: incorrect account details shown after creating a new one > -------------------------------------------------------------------- > > Key: RF-13707 > URL: https://issues.jboss.org/browse/RF-13707 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.8 > Reporter: Juraj H?ska > Labels: photoalbum > Fix For: 4.3.8, 4.5-Tracking > > > When user create a new account in Photoalbum application there are shown account details, which are incorrect: > * missing login, first name, surname > * wrong sex value (there is always female - I tried other than my photos as avatars, so the problem will be somewhere else :) ) > * missing Birthday and email -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 10:04:24 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 9 Jul 2014 10:04:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13707) Photoalbum: incorrect account details shown after creating a new one In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov reassigned RF-13707: ---------------------------------- Assignee: Michal Petrov > Photoalbum: incorrect account details shown after creating a new one > -------------------------------------------------------------------- > > Key: RF-13707 > URL: https://issues.jboss.org/browse/RF-13707 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.8 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.8, 4.5-Tracking > > > When user create a new account in Photoalbum application there are shown account details, which are incorrect: > * missing login, first name, surname > * wrong sex value (there is always female - I tried other than my photos as avatars, so the problem will be somewhere else :) ) > * missing Birthday and email -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 11:49:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 11:49:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983586#comment-12983586 ] Juraj H?ska commented on RF-13687: ---------------------------------- I have tried to test new implementation of {{tabPanel}}. I have found one difference between new and old implementation: * action method bound to {{rich:tab}} via its {{action}} attribute is executed only when was previously inactive, and is activated. In previous implementation one can click on the active header many times, and the action method was invoked nevertheless. Is this a bug ? It is at least change of behavior which can affect some users. Reopening. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 11:51:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 9 Jul 2014 11:51:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983587#comment-12983587 ] Juraj H?ska commented on RF-13687: ---------------------------------- Former test visible in [this|https://github.com/richfaces/richfaces/commit/0c3e9ff2fc3ceaa6087b4c787adbef815166fa36#commitcomment-6948255] comment is reproducing the issue I am talking about above. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:50:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:50:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reopened RF-13687: -------------------------------- Assignee: Brian Leathem (was: Juraj H?ska) > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:52:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:52:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983602#comment-12983602 ] Brian Leathem commented on RF-13706: ------------------------------------ Great, thanks [~ppitonak]. That makes sense and explains the current situation. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:54:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:54:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13711: ------------------------------- Fix Version/s: 4.5-Tracking > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:56:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13716: ------------------------------- Original Estimate: 2 hours Remaining Estimate: 2 hours Sprint: 4.5.0.Alpha3 - Sprint 5 > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Priority: Blocker > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:56:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13716: ---------------------------------- Assignee: Brian Leathem > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Assignee: Brian Leathem > Priority: Blocker > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 12:56:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 12:56:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983607#comment-12983607 ] Brian Leathem commented on RF-13717: ------------------------------------ Thanks [~jhuska]! > Some integration tests within components/rich are using wrongly FrameworkDeployment class > ----------------------------------------------------------------------------------------- > > Key: RF-13717 > URL: https://issues.jboss.org/browse/RF-13717 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Alpha3 > > > Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. > They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 13:38:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 13:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983616#comment-12983616 ] Brian Leathem commented on RF-13716: ------------------------------------ [~manovotn] I am unable to reproduce this with the latest from the 4.5.x branch. Perhaps it was resolved with this commit {{[eea815f|https://github.com/richfaces/richfaces/commit/eea815f7cbc2dabadd669ef45006a6f5d1e7d12b]}}? > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Assignee: Brian Leathem > Priority: Blocker > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 13:42:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 13:42:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983617#comment-12983617 ] Brian Leathem commented on RF-11782: ------------------------------------ [~ppitonak] from the linked metamer sample, how can I determine whether or not it is behaving as expected? > [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" > ---------------------------------------------------------------------------- > > Key: RF-11782 > URL: https://issues.jboss.org/browse/RF-11782 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.CR1 > Environment: mojarra-2.1.4, RF-CR1 > Reporter: Rene O > Assignee: Brian Leathem > Labels: lazy-loaded > Fix For: 5-Tracking > > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached: > http://localhost:8080/jsf2testcase/tabswitchtest.jsf > Steps to reproduce the issue: > 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB > 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table > {code:title=xhtml} > ... > > > > Here is tab #1 > > > > > > List A > > > > > > > > > > List B > > > > > > > > ... > {code} > {code:title=java} > ... > public List getTestListA() { > System.out.println("getTestListA"); > return testListA; > } > ... > public List getTestListB() { > System.out.println("getTestListB"); > return testListB; > } > ... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 13:42:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 13:42:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Labels: needs-qe (was: ) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Pavol Pitonak > Labels: needs-qe > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 13:44:25 2014 From: issues at jboss.org (Patrick Schmidt (JIRA)) Date: Wed, 9 Jul 2014 13:44:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983618#comment-12983618 ] Patrick Schmidt commented on RF-12108: -------------------------------------- METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Pavol Pitonak > Labels: needs-qe > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:03:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:03:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13687. -------------------------------- Resolution: Done Nice catch [~jhuska]. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:15:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:15:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13716. -------------------------------- Resolution: Out of Date Please re-open if this issue continues to be a problem. > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Assignee: Brian Leathem > Priority: Blocker > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:15:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:15:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13716: ------------------------------- Fix Version/s: (was: 4.5.0.Alpha3) > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Assignee: Brian Leathem > Priority: Blocker > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:17:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:17:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13660: ------------------------------- Sprint: 4.5.0.Alpha3 - Sprint 4, 4.5.0.Alpha3 - Sprint 5, 4.5.0.Alpha3 - Sprint 6 (was: 4.5.0.Alpha3 - Sprint 4, 4.5.0.Alpha3 - Sprint 5) > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:51:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:51:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13694) Update README files for RichFaces 4.5.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13694. -------------------------------- Assignee: Brian Leathem Resolution: Done > Update README files for RichFaces 4.5.x > --------------------------------------- > > Key: RF-13694 > URL: https://issues.jboss.org/browse/RF-13694 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: doc > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > {{README.md}} and {{dist/src/main/resources/txt/readme.txt}} need to be updated with RichFaces 4.5.x. > For {{README.md}} e.g.: > * change of the title to RichFaces 4.5 > * remove "New approach to styling based on LESS" > * alter "Smooth Migration from RF4 to RF5" > and other -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:55:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983676#comment-12983676 ] Brian Leathem commented on RF-13714: ------------------------------------ Thanks for sharing your use case. That makes the issue more clear. > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Fix For: 4.5-Tracking > > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:55:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13714) DropDownMenu not working inside tab-header In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13714: ------------------------------- Issue Type: Feature Request (was: Bug) > DropDownMenu not working inside tab-header > ------------------------------------------ > > Key: RF-13714 > URL: https://issues.jboss.org/browse/RF-13714 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.7 > Environment: Wildfly 8.1.0.GA => JSF 2.2 > Tested with recent Firefox and Chromium versions. > Reporter: Martin H?ller > Labels: dropDownMenu, tabPanel > Fix For: 4.5-Tracking > > Attachments: tabPanel.png > > > The component seems broken, when used in the header-fact of a . The menu simply doesn't open. Here is simplified example-code to reproduce: > {code:xml} > > > > > > > > > > > > {code} > If I use the same menu-code in the but outside the header-facet, it works. > This did work with Richfaces 3.3! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 15:57:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 9 Jul 2014 15:57:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-13715: ---------------------------------- Assignee: Pavol Pitonak This is likely a CSS issue. QE please provide a metamer sample that can be used for analysis. > not working inside header facet > --------------------------------------------------------- > > Key: RF-13715 > URL: https://issues.jboss.org/browse/RF-13715 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.7 > Environment: Firefox 26, Chromium 31, Opera 12.16 > Reporter: Martin H?ller > Assignee: Pavol Pitonak > Labels: tooltip > > A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: > {code:xml} > > > > > myTab > > some tooltip > > > > tab content > > > {code} > The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 18:12:25 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Wed, 9 Jul 2014 18:12:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983688#comment-12983688 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- I'm afraid that the extra _readyToSubmit_ check breaks my solution. The requestDelay determines how long an entry should stay at the end of the queue, waiting to be combined with similar requests. If we're removing stale entries from the queue, and we encounter the last entry in the queue which is still waiting to get combined, we should remove it from the queue if it is stale. Otherwise it will cause problems at the time it's actually submitted. As Pavol said, I developed the fix for the 4.3 version, and there the unit test ran fine. Today I merged my original patch to the 4.5 version, and the unit test failed over there. But the root cause had nothing to do with my original fix, but with the fact that the _richfaces_ variable has been renamed to _rf_ in 4.5, so that _richfaces.getDomElement_ does not work any more. Changing it to _rf.getDomElement_ fixed the unit test. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 18:31:24 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Wed, 9 Jul 2014 18:31:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983691#comment-12983691 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- When investigating the unit test problems, I found a potential problem in the code. This line removes an element from the queue: {noformat} items.shift; {noformat} So the request delay timer is not stopped for entries that are removed from the queue. I propose to replace that line with: {noformat} var removedEntry = items.shift(); removedEntry.stopTimer(); {noformat} When the timer is not stopped, the callback onRequestDelayPassed will be called on removed entries that still have a running timer. That doesn't seem to do much harm, but still it's better to fix this. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 02:24:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 10 Jul 2014 02:24:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13716) Charts 4.5 Showcase/Metamer a4j:ajax re-render In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13716. ------------------------------ Yes you are correct, it is no longer an issue. Closing. > Charts 4.5 Showcase/Metamer a4j:ajax re-render > ---------------------------------------------- > > Key: RF-13716 > URL: https://issues.jboss.org/browse/RF-13716 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output, showcase > Affects Versions: 4.5.0.Alpha3 > Environment: Latest FF/Chrome > Wildfly 8.1 > Reporter: Matej Novotny > Assignee: Brian Leathem > Priority: Blocker > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > The chart component in [Showcase|https://github.com/richfaces/richfaces/blob/4.5.x/examples/showcase/src/main/webapp/richfaces/chart/samples/events-sample.xhtml#L51] (and in [Metamer|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/application/src/main/webapp/components/richChart/simpleLine.xhtml#L70] as well) uses a4j:ajax to rerender output with server-side message. It always looks something like this: > {code} > > //some attribute settings > > // axis settings... > > > > {code} > With [this|https://github.com/richfaces/richfaces/commit/ba9dcfacd8aa67348924d8e127a6805e958c9450] commit, ajax re-rendering stopped working (in both, Metamer and Showcase) so it might be connected to fixes in RF-13706 in general. > Although I tried Metamer tests for a4j:ajax and they all pass successfully I do not think this issue is related to charts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:38:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 03:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983746#comment-12983746 ] Pavol Pitonak commented on RF-11782: ------------------------------------ # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTabPanel/lazyLoading.xhtml # check the list of JSF phases at the top of page - there is getTestListA, getTestListB - none of these should be there # switch to tab2 - getTestListA should be in list, nothing is there # switch to tab3 - getTestListB should be in list, getTestListA is there # switch to tab1 - nothing should be in list, getTestListA and getTestListB are there > [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" > ---------------------------------------------------------------------------- > > Key: RF-11782 > URL: https://issues.jboss.org/browse/RF-11782 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.CR1 > Environment: mojarra-2.1.4, RF-CR1 > Reporter: Rene O > Assignee: Brian Leathem > Labels: lazy-loaded > Fix For: 5-Tracking > > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached: > http://localhost:8080/jsf2testcase/tabswitchtest.jsf > Steps to reproduce the issue: > 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB > 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table > {code:title=xhtml} > ... > > > > Here is tab #1 > > > > > > List A > > > > > > > > > > List B > > > > > > > > ... > {code} > {code:title=java} > ... > public List getTestListA() { > System.out.println("getTestListA"); > return testListA; > } > ... > public List getTestListB() { > System.out.println("getTestListB"); > return testListB; > } > ... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:46:27 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 03:46:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reassigned RF-13715: ---------------------------------- Assignee: Martin Tomasek (was: Pavol Pitonak) > not working inside header facet > --------------------------------------------------------- > > Key: RF-13715 > URL: https://issues.jboss.org/browse/RF-13715 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.7 > Environment: Firefox 26, Chromium 31, Opera 12.16 > Reporter: Martin H?ller > Assignee: Martin Tomasek > Labels: tooltip > > A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: > {code:xml} > > > > > myTab > > some tooltip > > > > tab content > > > {code} > The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:56:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 03:56:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reassigned RF-13568: ---------------------------------- Assignee: Martin Tomasek (was: Ji?? ?tefek) > IllegalArgumentException for PushResource.jsf > --------------------------------------------- > > Key: RF-13568 > URL: https://issues.jboss.org/browse/RF-13568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-push/poll > Affects Versions: 5.0.0.Alpha3 > Environment: WildFly snapshot with Undertow 1.0.1 > Reporter: Juergen Zimmermann > Assignee: Martin Tomasek > > Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following: > {code} > [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present > at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 04:12:24 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 04:12:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13682: ------------------------------- Labels: (was: needs-qe) > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 04:12:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 04:12:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13682) Stateless view: CSS stylesheets not included in head after form submit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak closed RF-13682. ------------------------------ Verified with 4.5.0-SNAPSHOT on WildFly 8.1.0.Final. > Stateless view: CSS stylesheets not included in head after form submit > ---------------------------------------------------------------------- > > Key: RF-13682 > URL: https://issues.jboss.org/browse/RF-13682 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.7 > Environment: OpenSuse 13.1 x64 > OpenJDK 1.7.0_51 > Apache Tomcat 8.0.8 > JSF: org.glassfish:javax.faces:2.1.28 > Reporter: Tony Cramer > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: rf-demo-skinning.zip, rf-demo-skinning_and_style.zip > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If view is stateless Issue 1. skinning.css is not included after submitting a form at all. > Issue 2. Any other stylesheets manually included with h:outputStylesheet are not included in head but in body after submit. > Maven project reproducing the issue attached. > Please use "rf-demo-skinning_and_style.zip" - reproduces both issues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 04:35:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 10 Jul 2014 04:35:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13713) Create Smoke test(s) for chart in RF 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13713. ------------------------------ I added test for zoom (and resetZoom) into integration tests. Also I made use of FailingOnFirefox annotation. Currently there is only rendering test running on FF. As for PhantomJS and Chrome everything works fine. Also I created tests for basic attributes (title,styleClass,..) in Metamer. Those tests can run in any template and browser. Test coverage of charts should now be sufficient and we should now when something goes wrong. Closing issue. > Create Smoke test(s) for chart in RF 4.5 > ---------------------------------------- > > Key: RF-13713 > URL: https://issues.jboss.org/browse/RF-13713 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > Fix For: 4.5.0.Alpha3 > > > As charts were added recently we have no tests covering this component. > We need to have at least some smoke test too quickly determine when something goes wrong. Rest can be tested in Metamer. > These tests might run only with some browsers - investigate. > Also test JS API because it will be needed in order to test listeners. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:29:25 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 05:29:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13678) Render @all does not work for nested a4j:region in collapsibleSubTable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13678. ---------------------------- Verified. Closing. > Render @all does not work for nested a4j:region in collapsibleSubTable > ---------------------------------------------------------------------- > > Key: RF-13678 > URL: https://issues.jboss.org/browse/RF-13678 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Suppose nested {{regions}} in a {{collapsibleSubTable}}. > Those regions are not updated when a {{commandButton}} with {{render}} attribute set to {{@all}} is submitted. > IMHO it is somehow connected with RF-13677, however, this issue occurs only with combination of {{regions}} and {{collapsibleSubTable}}, other iteration components works in this matter. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:47:24 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Thu, 10 Jul 2014 05:47:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983801#comment-12983801 ] Martin Tomasek commented on RF-13715: ------------------------------------- Hi, The reproducer was created in metamer application. Rich Tooltip > RF-13715. I can confirm that in version 4.3.x component doesn't work correctly. I also checked bug in version 4.5.x and component work correctly. The tooltip was displayed. > not working inside header facet > --------------------------------------------------------- > > Key: RF-13715 > URL: https://issues.jboss.org/browse/RF-13715 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.7 > Environment: Firefox 26, Chromium 31, Opera 12.16 > Reporter: Martin H?ller > Assignee: Martin Tomasek > Labels: tooltip > > A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: > {code:xml} > > > > > myTab > > some tooltip > > > > tab content > > > {code} > The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:47:24 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Thu, 10 Jul 2014 05:47:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek updated RF-13715: -------------------------------- Assignee: (was: Martin Tomasek) > not working inside header facet > --------------------------------------------------------- > > Key: RF-13715 > URL: https://issues.jboss.org/browse/RF-13715 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.7 > Environment: Firefox 26, Chromium 31, Opera 12.16 > Reporter: Martin H?ller > Labels: tooltip > > A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: > {code:xml} > > > > > myTab > > some tooltip > > > > tab content > > > {code} > The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 06:13:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 06:13:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13687) TabPanel header is not updated after switching of tabs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13687. ---------------------------- Verified. Closing. > TabPanel header is not updated after switching of tabs > ------------------------------------------------------ > > Key: RF-13687 > URL: https://issues.jboss.org/browse/RF-13687 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.5.0.Alpha3, 5.0.0.Alpha3, 5.0.0.Alpha4 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: needs-qe > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If {{TabPanel}} header is updated dynamically with AJAX, then switching among the tabs shows not the updated value of the header, but the initial one. Its updated after refresh of the page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 06:53:25 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 10 Jul 2014 06:53:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reassigned RF-12108: ---------------------------------- Assignee: Juraj H?ska (was: Pavol Pitonak) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 06:55:26 2014 From: issues at jboss.org (Patrick Schmidt (JIRA)) Date: Thu, 10 Jul 2014 06:55:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983832#comment-12983832 ] Patrick Schmidt commented on RF-12108: -------------------------------------- METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:39:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 07:39:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983851#comment-12983851 ] Juraj H?ska commented on RF-13660: ---------------------------------- I was trying to proceed with this issue, and, I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:39:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 07:39:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983851#comment-12983851 ] Juraj H?ska edited comment on RF-13660 at 7/10/14 7:38 AM: ----------------------------------------------------------- I was trying to proceed with this issue, and I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint. was (Author: jhuska): I was trying to proceed with this issue, and, I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:41:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 07:41:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983851#comment-12983851 ] Juraj H?ska edited comment on RF-13660 at 7/10/14 7:40 AM: ----------------------------------------------------------- I was trying to proceed with this issue, and I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint to not to delay 4.5.0.Alpha3 staging. was (Author: jhuska): I was trying to proceed with this issue, and I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:43:26 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 07:43:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983851#comment-12983851 ] Juraj H?ska edited comment on RF-13660 at 7/10/14 7:43 AM: ----------------------------------------------------------- I was trying to proceed with this issue, and I am not able to resolve it without further information. My observations and questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint to not to delay 4.5.0.Alpha3 staging. was (Author: jhuska): I was trying to proceed with this issue, and I am not able to resolve it without further information. My observations a questions: * {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars. * {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? * why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? Because [~michpetrov] advised me that it is indeed a test issue, not the framework one, and after discussion with [~ppitonak], I would opt for shifting this issue to Beta1 sprint to not to delay 4.5.0.Alpha3 staging. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:49:25 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 10 Jul 2014 07:49:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983858#comment-12983858 ] Matej Novotny commented on RF-13711: ------------------------------------ Alright I made a little bit of research on this because I found out we have this kind of usage in [Showcase|http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=status&sample=referencedUsage&skin=blueSky] and also we have similar use case in Metamer. So here are the results... What matters is, whether you have {{status}} attribute set or not. I will use following code snippet to explain in better. {code:xml} {code} The first button with attached ajax behavior has status set. This button *will not work*. This behaviour is IMHO a bug. The other button, however, *will work*. (Too see why a4j:status affects components which do not specifically use status attribute see [documentation|http://docs.jboss.org/richfaces/latest_4_3_X/Component_Reference/en-US/html_single/#sect-Component_Reference-a4jstatus-Specifying_a_region]). This is a correct solution but with more complex page, a4j:status might react on more requests than intended. But still I think this can be considered a workaround until we investigate further. Using a4j:commandButton instead of h:commandButton behaves equally. Also I made a mistake placing the reproducer in a4j:ajax instead of a4j:status, I will move and also alter the reproducer accordingly to my findings. I will update the issue information as well. [~rustock0] you can try the workaround I suggested, it might fit your needs better. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 08:51:25 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Thu, 10 Jul 2014 08:51:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13718) Update release guide for 4.5 In-Reply-To: References: Message-ID: Michal Petrov created RF-13718: ---------------------------------- Summary: Update release guide for 4.5 Key: RF-13718 URL: https://issues.jboss.org/browse/RF-13718 Project: RichFaces Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.5.0.Alpha3 Reporter: Michal Petrov The howto-release.adoc describes the release for RF 5 which doesn't seem to be applicable, the components/howto-release.adoc is for 4.5 components from when there were dependent on RF 5 core. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 08:51:27 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 10 Jul 2014 08:51:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983858#comment-12983858 ] Matej Novotny edited comment on RF-13711 at 7/10/14 8:51 AM: ------------------------------------------------------------- Alright I made a little bit of research on this because I found out we have this kind of usage in [Showcase|http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=status&sample=referencedUsage&skin=blueSky] and also we have similar use case in Metamer. So here are the results... What matters is, whether you have {{status}} attribute set or not. I will use following code snippet to explain in better. {code:xml} {code} The first button with attached ajax behavior has status set. This button *will not work*. This behaviour is IMHO a bug. The other button, however, *will work*. (Too see why a4j:status affects components which do not specifically use status attribute see [documentation|http://docs.jboss.org/richfaces/latest_4_3_X/Component_Reference/en-US/html_single/#sect-Component_Reference-a4jstatus-Specifying_a_region]). This is a correct solution but with more complex page, a4j:status might react on more requests than intended. But still I think this can be considered a workaround until we investigate further. Using a4j:commandButton instead of h:commandButton behaves equally. NOTE: a4j:status with facets works correctly (for this we have Metamer [page|http://localhost:8080/metamer/faces/components/a4jStatus/referencedUsage.xhtml]), the problem is with onstart/onstop/onerror which should execute JS code Also I made a mistake placing the reproducer in a4j:ajax instead of a4j:status, I will move and also alter the reproducer accordingly to my findings. I will update the issue information as well. [~rustock0] you can try the workaround I suggested, it might fit your needs better. was (Author: manovotn): Alright I made a little bit of research on this because I found out we have this kind of usage in [Showcase|http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=status&sample=referencedUsage&skin=blueSky] and also we have similar use case in Metamer. So here are the results... What matters is, whether you have {{status}} attribute set or not. I will use following code snippet to explain in better. {code:xml} {code} The first button with attached ajax behavior has status set. This button *will not work*. This behaviour is IMHO a bug. The other button, however, *will work*. (Too see why a4j:status affects components which do not specifically use status attribute see [documentation|http://docs.jboss.org/richfaces/latest_4_3_X/Component_Reference/en-US/html_single/#sect-Component_Reference-a4jstatus-Specifying_a_region]). This is a correct solution but with more complex page, a4j:status might react on more requests than intended. But still I think this can be considered a workaround until we investigate further. Using a4j:commandButton instead of h:commandButton behaves equally. Also I made a mistake placing the reproducer in a4j:ajax instead of a4j:status, I will move and also alter the reproducer accordingly to my findings. I will update the issue information as well. [~rustock0] you can try the workaround I suggested, it might fit your needs better. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:21:27 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 09:21:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983907#comment-12983907 ] Juraj H?ska commented on RF-12108: ---------------------------------- It seems that with recent RichFaces {{4.5.0.Alpha3-SNAPSHOT}} this issue is resolved. > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Juraj H?ska > Labels: needs-qe > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:23:25 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 09:23:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-12108: ----------------------------- Labels: (was: needs-qe) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Juraj H?ska > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:23:26 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 10 Jul 2014 09:23:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-12108: ----------------------------- Assignee: (was: Juraj H?ska) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:40:25 2014 From: issues at jboss.org (Evgeny Mironenko (JIRA)) Date: Thu, 10 Jul 2014 10:40:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983956#comment-12983956 ] Evgeny Mironenko commented on RF-13711: --------------------------------------- [~manovotn] thank you for the explanation, but in my case I have one common status for more than one form. Therefore, I need a handed down status. Of course I will use {{render}} instead of {{status}} but it will be great, if this problem will be fixed in next versions. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:29:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:29:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11782) [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11782: ------------------------------- Fix Version/s: 4.5-Tracking (was: 5-Tracking) > [rich:tabPanel] switching tabs doesn't work correctly with switchtype="ajax" > ---------------------------------------------------------------------------- > > Key: RF-11782 > URL: https://issues.jboss.org/browse/RF-11782 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.CR1 > Environment: mojarra-2.1.4, RF-CR1 > Reporter: Rene O > Assignee: Brian Leathem > Labels: lazy-loaded > Fix For: 4.5-Tracking > > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached: > http://localhost:8080/jsf2testcase/tabswitchtest.jsf > Steps to reproduce the issue: > 1. switch to 'Tab 3' -> console/server-log shows 'getTestListA' and 'getTestListB' -> this is a bug, expected is only 'getTestListB', because tab3 has only one table with testListB > 2. switch to 'Tab 1' -> console/server-log shows 'getTestListB' -> this is a bug, expected is nothing new in console/server-log, because tab1 has no table > {code:title=xhtml} > ... > > > > Here is tab #1 > > > > > > List A > > > > > > > > > > List B > > > > > > > > ... > {code} > {code:title=java} > ... > public List getTestListA() { > System.out.println("getTestListA"); > return testListA; > } > ... > public List getTestListB() { > System.out.println("getTestListB"); > return testListB; > } > ... > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:31:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:31:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Comment: was deleted (was: METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). ) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:34:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:34:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Comment: was deleted (was: METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). ) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 4.5-Tracking > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:38:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:38:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984018#comment-12984018 ] Brian Leathem commented on RF-13706: ------------------------------------ Yeah, I'd already caught the {{richfaces.*}} calls and fixed those in a subsequent commit. I like your suggestion to explicitly stop the timer. Unexpired timers is what I was trying to achieve with the {{readyToSubmit()}} check, but your approach seems more sound. I've adopted your changes and pushed them to the {{4.5.x}} branch. They will not make it in our current 4.5.0.Alpha3 stage, but may make it in if we have to re-stage (for another reason). Otherwise this change will land in a subsequent 4.5.0.Beta1 release. Note: this fix resolved the long standing issue: RF-12108. Thanks [~marcelkolsteren] for the Pull Request! > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:38:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:38:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12108: ------------------------------- Fix Version/s: 4.5.0.Alpha3 (was: 4.5-Tracking) > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Fix For: 4.5.0.Alpha3 > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:38:27 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:38:27 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem reassigned RF-12108: ---------------------------------- Assignee: Brian Leathem > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:38:28 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:38:28 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-12108. -------------------------------- Resolution: Done > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:40:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13660: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 4.5.0.Alpha3) > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Beta1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:52:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 13:52:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984021#comment-12984021 ] Brian Leathem commented on RF-13660: ------------------------------------ {quote} {{SystemEventListener}} is part of JSF, it is not included in any of the above mentioned jars {quote} {{InitializationListener}} is our implementation of the JSF {{SystemEventListener}} interface. It is our implementation that is included and invoked twice. {quote} {{FrameworkDeployment}} creates jar which is IMHO equal to {{richfaces-core-4.5.0-SNAPSHOT.jar}}, do we need to have all of them in deployed war ? {quote} The purpose of the deployment is to dynamically create the jar to include in the Arquillian tests, without invoking the full maven build cycle (using Shrinwraop instead) and bringing in the incremental changes. It's purpose is to improve the development turnaround time in when using TDD. {quote} why {{FrameworkDeployment}} is working only with core, and {{org.richfaces:richfaces-a4j:4.5.0-SNAPSHOT}} and with rich components as well ? {quote} I'm not sure I understand what you are asking exactly, but some core tests need rich/a4j components to expose the functionality being tested. ---- I expect resolution of this issue to involve the following: # Make sure we have a dynamically created deployment for each of the {{Core}}, {{a4j}}, and {{rich}} jars # Each of these deployments should contain dependency jars as appropriate, making sure to exclude any dependency duplicated by the dynamically generated jar As is stands right now, we have the legacy {{Framework}} dynamic jar leftover from the RF 5 backport. We also have a problem with Shrinkwrap pulling in a duplicate dependency. > RichFaces 4.5 integration tests - error after test execution > ------------------------------------------------------------ > > Key: RF-13660 > URL: https://issues.jboss.org/browse/RF-13660 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.5.0.Alpha2 > Environment: AS: Wildfly > Browser: PhantomJS > Reporter: Matej Novotny > Assignee: Juraj H?ska > Fix For: 4.5.0.Beta1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > This issue originated from RF-13591. > There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/src/test/integration/org/richfaces/integration/resource/ITResourceMapping.java]. > The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines. > Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/56/console]. > The exception in server console is: > {code} > 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException > at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:] > at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:] > at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:] > at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final] > at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 14:00:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 14:00:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13715) not working inside header facet In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13715. -------------------------------- Resolution: Out of Date Thanks [~mtomasek]. I'm resolving this issue as out-of-date since it works in our upcoming 4.5 release. > not working inside header facet > --------------------------------------------------------- > > Key: RF-13715 > URL: https://issues.jboss.org/browse/RF-13715 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.7 > Environment: Firefox 26, Chromium 31, Opera 12.16 > Reporter: Martin H?ller > Labels: tooltip > > A tooltip doesn't show up, when it's used in a header-facet of a component. The following code demonstrates the problem: > {code:xml} > > > > > myTab > > some tooltip > > > > tab content > > > {code} > The same tooltip works in the tab's content. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 14:02:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 14:02:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13718) Update release guide for 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13718: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Update release guide for 4.5 > ---------------------------- > > Key: RF-13718 > URL: https://issues.jboss.org/browse/RF-13718 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Michal Petrov > Fix For: 4.5.0.Beta1 > > > The howto-release.adoc describes the release for RF 5 which doesn't seem to be applicable, the components/howto-release.adoc is for 4.5 components from when there were dependent on RF 5 core. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 18:13:24 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Thu, 10 Jul 2014 18:13:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984070#comment-12984070 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- Thanks! In order to prevent that the fix for this issue will be broken in the future, I created an extra qunit test. Here is the pull request: [https://github.com/richfaces4/core/pull/25] I also fixed the problem that the QUnitTest class executed all test modules in each of the test methods, instead of only the module for which the test method is intended. Each test module was executed many times, which is a waste of test time, and which clutters the test results if a test is failing. Furthermore, I added the change for stopping the timer. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 18:33:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 10 Jul 2014 18:33:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984074#comment-12984074 ] Brian Leathem commented on RF-13706: ------------------------------------ This is great, thanks [~marcelkolsteren]. I'll merge your PR. Would you mind formulating one for RichFaces 4.5 as well: https://github.com/richfaces/richfaces/tree/4.5.x > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 02:59:25 2014 From: issues at jboss.org (=?UTF-8?Q?Jon=C3=A1=C5=A1_Trantina_=28JIRA=29?=) Date: Fri, 11 Jul 2014 02:59:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: Jon?? Trantina created RF-13719: ----------------------------------- Summary: rich.fileUpload breaks form action in portal Key: RF-13719 URL: https://issues.jboss.org/browse/RF-13719 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.3.5 Environment: JBoss Portal 6.1.1 Reporter: Jon?? Trantina When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. In fileupload.js __submit method there is the following code: {code:JavaScript} var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); {code} the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. In portal the solution is {code:JavaScript} var originalFormAction =this.form.attr("action"); {code} and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? To reproduce you can use the reproducer attached. Example URLs: form action {code} /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action {code} input[name='javax.faces.encodedURL'] {code} /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 03:01:26 2014 From: issues at jboss.org (=?UTF-8?Q?Jon=C3=A1=C5=A1_Trantina_=28JIRA=29?=) Date: Fri, 11 Jul 2014 03:01:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon?? Trantina updated RF-13719: -------------------------------- Attachment: reproducer.zip > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 03:07:24 2014 From: issues at jboss.org (=?UTF-8?Q?Jon=C3=A1=C5=A1_Trantina_=28JIRA=29?=) Date: Fri, 11 Jul 2014 03:07:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984114#comment-12984114 ] Jon?? Trantina commented on RF-13719: ------------------------------------- To reproduce via reproducer.zip, just build and deploy the portlet on JPP. Access the portlet and: 1) click submit button - observe the logs and see form was submitted 2) choose some files and upload them 2.5) see in the DOM that form action url has changed 3) click submit button - form is not submitted well > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:45:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 11 Jul 2014 07:45:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: Juraj H?ska created RF-13720: -------------------------------- Summary: Mobile Showcase - CSV demo with JS error and does not work Key: RF-13720 URL: https://issues.jboss.org/browse/RF-13720 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-validators Affects Versions: 4.5.0.Alpha3 Environment: mobile devices Reporter: Juraj H?ska Showcase demo for _client side validation_ is not working on mobile devices. There is a JS error thrown, stating: {code} TypeError: RichFaces.csv.validate is not a function if(clientHandler){clientHandler.call(this,event) {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:55:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 11 Jul 2014 07:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13720: ----------------------------- Priority: Critical (was: Major) > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Priority: Critical > Labels: mobile, regression > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:55:24 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Fri, 11 Jul 2014 07:55:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13720: ----------------------------- Labels: mobile regression (was: mobile) > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Priority: Critical > Labels: mobile, regression > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:59:24 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Fri, 11 Jul 2014 07:59:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Steps to Reproduce: * Start Wildfly * Deploy Metamer * Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml] * Open browser console * Click the button ** Expected: Three lines appear in the console: *** {{start}} //triggered by a4j:status *** {{POST...}} //request itself *** {{stop}} //triggered by a4j:status ** Actual: Only request itself is displayed in console was: * Start JBossAS 7.1 (or for RF 4.5 Wildfly) * Deploy Metamer * Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml] * Open browser console * Click the button ** Expected: Three lines appear in the console: *** {{start}} //triggered by a4j:status *** {{POST...}} //request itself *** {{stop}} //triggered by a4j:status ** Actual: Only request itself is displayed in console > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 09:26:24 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Fri, 11 Jul 2014 09:26:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13721) dataTable: columnClasses attribute doesn't work as described In-Reply-To: References: Message-ID: Michal Petrov created RF-13721: ---------------------------------- Summary: dataTable: columnClasses attribute doesn't work as described Key: RF-13721 URL: https://issues.jboss.org/browse/RF-13721 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tables Affects Versions: 5.0.0.Alpha3, 4.5.0.Alpha2, 4.3.7 Reporter: Michal Petrov The description of @columnClasses says bq. ? If you have less class names than columns, the class will be applied to every n-fold column where n is the order in which the class is listed in the attribute. This is not the case, if you define n classes they will only be applied to the first n columns. This only affects components that use AbstractRowRenderer. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 11:52:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 11:52:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984330#comment-12984330 ] Brian Leathem commented on RF-13719: ------------------------------------ [~kenfinni]: any insight here? > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 11:52:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 11:52:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13719: ------------------------------- Labels: gss (was: ) > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 11:54:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 11:54:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984333#comment-12984333 ] Brian Leathem commented on RF-13720: ------------------------------------ Are we sure this works on Desktop? The same resources should be served in both cases, so it surprises me that this erros on mobile but not desktop. > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Priority: Critical > Labels: mobile, regression > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 11:54:26 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 11:54:26 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13721) dataTable: columnClasses attribute doesn't work as described In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13721: ------------------------------- Fix Version/s: 4.5-Tracking > dataTable: columnClasses attribute doesn't work as described > ------------------------------------------------------------ > > Key: RF-13721 > URL: https://issues.jboss.org/browse/RF-13721 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.3.7, 4.5.0.Alpha2, 5.0.0.Alpha3 > Reporter: Michal Petrov > Fix For: 4.5-Tracking > > > The description of @columnClasses says > bq. ? If you have less class names than columns, the class will be applied to every n-fold column where n is the order in which the class is listed in the attribute. > This is not the case, if you define n classes they will only be applied to the first n columns. This only affects components that use AbstractRowRenderer. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 12:12:24 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Fri, 11 Jul 2014 12:12:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984350#comment-12984350 ] Ken Finnigan commented on RF-13719: ----------------------------------- I know that's something that is tested, and last time I did it worked fine. One comment would be that the reproducer is using RF 4.3.1.Final, not 4.3.5.Final, and it also uses PBR 3.2.0.Final, which I'm pretty sure is the incorrect version for JPP 6.1.1 [~jtrantin], have you spoken with JPP QE about this? Maybe [~pmensik] can assist? > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 12:54:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 12:54:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13720: ------------------------------- Priority: Major (was: Critical) > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Labels: mobile, regression > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 12:54:25 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 12:54:25 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13720: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Labels: mobile, regression > Fix For: 4.5.0.Beta1 > > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 16:27:24 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Fri, 11 Jul 2014 16:27:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984430#comment-12984430 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- I received a mail from "ci-builds" at RedHat that the build "richfaces-4.3-core - Build # 347" failed. But I don't have access to the Jenkins page that shows the details, and on my local machine a "mvn install" on the RichFaces core module runs fine. What went wrong in that build and is it related to my PR? > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 17:38:24 2014 From: issues at jboss.org (Cody Lerum (JIRA)) Date: Fri, 11 Jul 2014 17:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5 In-Reply-To: References: Message-ID: Cody Lerum created RF-13722: ------------------------------- Summary: Document CDK Maven Changes for 4.5 Key: RF-13722 URL: https://issues.jboss.org/browse/RF-13722 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.5.0.Alpha3 Reporter: Cody Lerum Fix For: 4.5-Tracking The maven build requires a 2 step process now with a set to precompile before the cdk runs {code} maven-compiler-plugin precompile-sources-for-cdk generate-sources compile org.richfaces.cdk richfaces-cdk-maven-plugin ${org.richfaces.cdk.version} cdk-generate-sources process-sources generate {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 17:38:24 2014 From: issues at jboss.org (Cody Lerum (JIRA)) Date: Fri, 11 Jul 2014 17:38:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984438#comment-12984438 ] Cody Lerum commented on RF-13722: --------------------------------- Document in wiki > Document CDK Maven Changes for 4.5 > ---------------------------------- > > Key: RF-13722 > URL: https://issues.jboss.org/browse/RF-13722 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: cdk > Affects Versions: 4.5.0.Alpha3 > Reporter: Cody Lerum > Fix For: 4.5-Tracking > > > The maven build requires a 2 step process now with a set to precompile before the cdk runs > {code} > > > maven-compiler-plugin > > > precompile-sources-for-cdk > generate-sources > > compile > > > > > > org.richfaces.cdk > richfaces-cdk-maven-plugin > ${org.richfaces.cdk.version} > > > cdk-generate-sources > process-sources > > generate > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 17:40:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 17:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13722: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 4.5-Tracking) > Document CDK Maven Changes for 4.5 > ---------------------------------- > > Key: RF-13722 > URL: https://issues.jboss.org/browse/RF-13722 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: cdk > Affects Versions: 4.5.0.Alpha3 > Reporter: Cody Lerum > Fix For: 4.5.0.Beta1 > > > The maven build requires a 2 step process now with a set to precompile before the cdk runs > {code} > > > maven-compiler-plugin > > > precompile-sources-for-cdk > generate-sources > > compile > > > > > > org.richfaces.cdk > richfaces-cdk-maven-plugin > ${org.richfaces.cdk.version} > > > cdk-generate-sources > process-sources > > generate > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 17:40:24 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 11 Jul 2014 17:40:24 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13722) Document CDK Maven Changes for 4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984439#comment-12984439 ] Brian Leathem commented on RF-13722: ------------------------------------ Great, thanks for filing this [~clerum]. Agreed, the rest ofthe CDK docs are in the wiki atm, so a wiki page addresseing CDK 4.3 to 4.5 migrations would be the best place to hang this for now. > Document CDK Maven Changes for 4.5 > ---------------------------------- > > Key: RF-13722 > URL: https://issues.jboss.org/browse/RF-13722 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: cdk > Affects Versions: 4.5.0.Alpha3 > Reporter: Cody Lerum > Fix For: 4.5.0.Beta1 > > > The maven build requires a 2 step process now with a set to precompile before the cdk runs > {code} > > > maven-compiler-plugin > > > precompile-sources-for-cdk > generate-sources > > compile > > > > > > org.richfaces.cdk > richfaces-cdk-maven-plugin > ${org.richfaces.cdk.version} > > > cdk-generate-sources > process-sources > > generate > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 12 10:00:30 2014 From: issues at jboss.org (John Kiro (JIRA)) Date: Sat, 12 Jul 2014 10:00:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984513#comment-12984513 ] John Kiro commented on RF-12448: -------------------------------- The issue is still there, and reproducible even on the showcase of RF 5 ( version 5.0.0.Alpha3) (http://showcase5-richfaces.rhcloud.com/richfaces/component-sample.jsf?demo=calendar&skin=blueSky). In my opinion, the fix is not that difficult, and given the priority (still set to Critical for more than 3 years), it should take more attention. Will add more information subsequently about my observation in the component Javascript code. > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Priority: Critical > Fix For: 5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calendar&skin=blueSky > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 03:24:29 2014 From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=) Date: Mon, 14 Jul 2014 03:24:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13723) fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE In-Reply-To: References: Message-ID: Ji?? ?tefek created RF-13723: -------------------------------- Summary: fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE Key: RF-13723 URL: https://issues.jboss.org/browse/RF-13723 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.5.0.Alpha3 Environment: IE 11, IE 10 Reporter: Ji?? ?tefek Priority: Minor The 'Clear All' button does nothing when clicked after maxFilesQuantity reached by adding items using the 'Add' button. It works after items were added by DnD. You have to click somewhere on the page, to get the button working. It works fine in FF, Chrome. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 03:36:29 2014 From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=) Date: Mon, 14 Jul 2014 03:36:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13597) Drag and drop support for file upload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ji?? ?tefek closed RF-13597. ---------------------------- Good job. Looks good on all mentioned browsers. Verified, closing. > Drag and drop support for file upload > ------------------------------------- > > Key: RF-13597 > URL: https://issues.jboss.org/browse/RF-13597 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 4.1.0.Final > Reporter: abhishek vijra > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Drag/Drop support should be added to file upload component . > Like the primefaces fileUploadDnd : http://www.primefaces.org/showcase/ui/fileUploadDnd.jsf -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 03:52:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Mon, 14 Jul 2014 03:52:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984577#comment-12984577 ] Michal Petrov commented on RF-13706: ------------------------------------ [~marcelkolsteren] it wasn't your fault :) Jenkins couldn't access the JBoss repo for some reason (there might have been a maintenance), the later builds are passing. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 04:14:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Mon, 14 Jul 2014 04:14:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984584#comment-12984584 ] Pavol Pitonak commented on RF-13706: ------------------------------------ As Michal wrote, everything works fine now. [~marcelkolsteren], FYI you can see results of Jenkins jobs here https://hudson.jboss.org/hudson/view/Richfaces/job/richfaces-4.3-core. I updated Jenkins notifications to contain this link. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 04:56:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 04:56:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984600#comment-12984600 ] Juraj H?ska commented on RF-13720: ---------------------------------- Yes, I tried it again, and desktop version works fine. Function {{RichFaces.csv.validate}} is available after a page refresh. > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Labels: mobile, regression > Fix For: 4.5.0.Beta1 > > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 04:58:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 04:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13720: ----------------------------- Steps to Reproduce: # deploy showcase, and load: http://localhost:8080/showcase/mobile/#clientValidation:jsr303 # ensure that the browser cache was clear before page loading # type one character to input and make a blur over the input # see that there are no error messages > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Labels: mobile, regression > Fix For: 4.5.0.Beta1 > > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 05:24:30 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 05:24:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13709) Remove the chart components from the RichFaces mobile showcase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13709. ------------------------------ Verified, closing issue. > Remove the chart components from the RichFaces mobile showcase > -------------------------------------------------------------- > > Key: RF-13709 > URL: https://issues.jboss.org/browse/RF-13709 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: showcase > Reporter: Brian Leathem > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The chart components need additional work to function in a mobile environment. In the mean time we should remove them from the mobile showcase. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 05:26:30 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 05:26:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13675) Showcase: chart component improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13675. ------------------------------ Verified, closing. > Showcase: chart component improvements > -------------------------------------- > > Key: RF-13675 > URL: https://issues.jboss.org/browse/RF-13675 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Luk?? Macko > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The chart sample on the showcase needs some descriptive text. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 05:42:30 2014 From: issues at jboss.org (Petr Mensik (JIRA)) Date: Mon, 14 Jul 2014 05:42:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984609#comment-12984609 ] Petr Mensik commented on RF-13719: ---------------------------------- I was able to reproduce the issue with enclosed WAR - I also tried newest version of components (PBR 3.3.2 and RF 4.3.7) but form is still incorrectly submitted. > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 05:52:30 2014 From: issues at jboss.org (=?UTF-8?Q?Jon=C3=A1=C5=A1_Trantina_=28JIRA=29?=) Date: Mon, 14 Jul 2014 05:52:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon?? Trantina updated RF-13719: -------------------------------- Attachment: reproducer2.zip Uploaded reproducer with RF 4.3.5.Final and PortletBridge 3.3.1.Final which should be the right version for JPP 6.1 > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 05:54:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 05:54:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13717) Some integration tests within components/rich are using wrongly FrameworkDeployment class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13717. ------------------------------ Verified, there are no more compilation errors. Closing issue. > Some integration tests within components/rich are using wrongly FrameworkDeployment class > ----------------------------------------------------------------------------------------- > > Key: RF-13717 > URL: https://issues.jboss.org/browse/RF-13717 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Alpha3 > > > Some tests in {{components/rich}} are using {{FrameworkDeployment}} from core module. Because of it they can not be compiled. > They should use {{UIDeployment}} instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 06:00:36 2014 From: issues at jboss.org (=?UTF-8?Q?Jon=C3=A1=C5=A1_Trantina_=28JIRA=29?=) Date: Mon, 14 Jul 2014 06:00:36 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984612#comment-12984612 ] Jon?? Trantina commented on RF-13719: ------------------------------------- This is why I think this is a bug in RF: RF looks for content of input[name='javax.faces.encodedURL'] and restores it to form action with higher priority than prior action in form. However, content of input[name='javax.faces.encodedURL'] is a URL for submitting partial AJAX requests. According to [1] the input is created only if action URL (used for submitting normal requests) and partial action URL (used for submitting partial requests) are different. Therefore in my opinion partial action URL should never be put into form's action url. Is that right? [1] https://javaserverfaces.java.net/docs/2.0/pdldocs/facelets/h/form.html > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 06:56:32 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 06:56:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13692) Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13692. ------------------------------ Verified, closing issue. > Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception > ------------------------------------------------------------------------------ > > Key: RF-13692 > URL: https://issues.jboss.org/browse/RF-13692 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is an error during deployment of Photoalbum example on WildFly 8.1.0.Final or 8.0.0.Final > {code} > 09:28:51,675 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization > at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:159) > at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:91) > at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215) > at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208) > 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:606) > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232) > at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169) > at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128) > at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > {code} > and > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."richfaces-photoalbum.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 23 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 22 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.VIEW."org.richfaces.photoalbum.model.actions.IAlbumAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.VIEW."org.richfaces.photoalbum.model.actions.IEventAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.VIEW."org.richfaces.photoalbum.model.actions.IImageAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.VIEW."org.richfaces.photoalbum.search.ISearchAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.VIEW."org.richfaces.photoalbum.model.actions.IShelfAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.VIEW."org.richfaces.photoalbum.model.actions.IUserAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator] > service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."richfaces-photoalbum.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > service jboss.deployment.unit."richfaces-photoalbum.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START, JBAS014799: ... and 16 more ] > service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START, JBAS014799: ... and 4 more ] > service jboss.persistenceunit."richfaces-photoalbum.war#photoAlbum" (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService, JBAS014799: ... and 13 more ] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum] > service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService] > {code} > Note that it *works* on EAP 6.2.3.GA and EAP 6.3.0.ER8 > Both WildFly containers use Weld 2.1.x, so it is not a problem with Weld 2.2.x integration. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:26:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 07:26:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: Juraj H?ska created RF-13724: -------------------------------- Summary: Showcase - leftovers of old Editor skinning setup cause 404 error Key: RF-13724 URL: https://issues.jboss.org/browse/RF-13724 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.5.0.Alpha3 Reporter: Juraj H?ska Priority: Trivial In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} {code} This causes 404 HTTP errors, while those skins can not be found in the resources. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:26:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 07:26:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned RF-13724: -------------------------------- Assignee: Juraj H?ska > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:36:32 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 07:36:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13724: ----------------------------- Assignee: (was: Juraj H?ska) > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Priority: Trivial > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:38:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 07:38:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13724: ----------------------------- Description: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} {code} This causes 404 HTTP errors, while those skins can not be found in the resources. Note that this errors do not affect any functionality nor they are somehow visible elsewhere than JS console. was: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} {code} This causes 404 HTTP errors, while those skins can not be found in the resources. > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Priority: Trivial > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:38:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 07:38:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13724: ----------------------------- Description: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} {code} This causes 404 HTTP errors, while those skins can not be found in the resources. Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console. was: In the example for editor advanced configuration, there is leftover of old skinning setup: {code:xml} {code} This causes 404 HTTP errors, while those skins can not be found in the resources. Note that this errors do not affect any functionality nor they are somehow visible elsewhere than JS console. > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Priority: Trivial > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 08:10:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 08:10:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12108) Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek closed RF-12108. ------------------------------- Verified in version 4.5.0.Alpha3 > Components second tab changes are not rendered after performing some ajax action if attribute ajaxRendered="true" inside located on first tab > --------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RF-12108 > URL: https://issues.jboss.org/browse/RF-12108 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.0.Final, 4.2.2.Final > Environment: JDK1.6, > JBoss 6.0.Final, JBoss 7.1.1.Final > richfaces 4.1.0.Final/4.2.0.Final/4.2.2.Final > seam 3.1 > IE 9, Chrome, Firefox > Reporter: Artur Mioduszewski > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: sample.xhtml > > > In case getting 2 tabs (in my case it is primefaces tabs): > {code:title=RENDERING ON SECOND TAB NOT WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > {code:title=RENDERING ON SECOND TAB CORRECTLY WORKS (after clicking link)} > First tab: > > > > > Second tab (some code with ajax) > Ex. > > > > > {code} > When I change tabs order, problem does not exist. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 08:10:33 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 08:10:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13651) Integration tests failing in chrome In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek closed RF-13651. ------------------------------- Verified. > Integration tests failing in chrome > ----------------------------------- > > Key: RF-13651 > URL: https://issues.jboss.org/browse/RF-13651 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - functional > Reporter: Brian Leathem > Assignee: Matej Novotny > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The framework tests pass in phantomjs but some fail in chrome. > Resolution of this issue involves running and stabilizing the tests in all supported browsers. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 08:14:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 08:14:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13653) Update component namespaces in 4.5 examples In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek closed RF-13653. ------------------------------- > Update component namespaces in 4.5 examples > ------------------------------------------- > > Key: RF-13653 > URL: https://issues.jboss.org/browse/RF-13653 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > With the exception of showcase, all examples use the r namespace, it needs to be changed back to a4j/rich. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 08:52:30 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 08:52:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13706. ------------------------------ Verified. Works for 4.3.x. As for 4.5.x, this is *not included in 4.5.0.Alpha3*, but the fix works fine for me, so we can include it in the next release. > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:02:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 09:02:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13694) Update README files for RichFaces 4.5.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny closed RF-13694. ------------------------------ Verified, closing issue. > Update README files for RichFaces 4.5.x > --------------------------------------- > > Key: RF-13694 > URL: https://issues.jboss.org/browse/RF-13694 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: doc > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > {{README.md}} and {{dist/src/main/resources/txt/readme.txt}} need to be updated with RichFaces 4.5.x. > For {{README.md}} e.g.: > * change of the title to RichFaces 4.5 > * remove "New approach to styling based on LESS" > * alter "Smooth Migration from RF4 to RF5" > and other -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:22:31 2014 From: issues at jboss.org (Ken Finnigan (JIRA)) Date: Mon, 14 Jul 2014 09:22:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984730#comment-12984730 ] Ken Finnigan commented on RF-13719: ----------------------------------- [~jtrantin], this seemed somewhat familiar when looking at it today, and I discovered RF-12273. RF-12273 actually introduced the code you refer to in fileUpload.js above, and it was introduced to make the component work in a portlet environment. Without that change, it's not possible to upload files in a portlet at all. There may be a bug somewhere, but as fileUpload is usually used in an Ajax form, without a non Ajax submit, I don't think it's something that has been tested. Not sure if any of that is much help or not > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:52:30 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 09:52:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek reopened RF-13690: --------------------------------- We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 09:52:30 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 09:52:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek reopened RF-13691: --------------------------------- We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:06:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:06:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984747#comment-12984747 ] Martin Tomasek edited comment on RF-13691 at 7/14/14 10:04 AM: --------------------------------------------------------------- We can still reproduce issue but only on Wildfly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on Wildfly 8.1. was (Author: mtomasek): We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:06:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:06:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984746#comment-12984746 ] Martin Tomasek edited comment on RF-13690 at 7/14/14 10:05 AM: --------------------------------------------------------------- We can still reproduce issue but only on Wildfly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on Wildfly 8.1. was (Author: mtomasek): We can still reproduce issue. Steps to reproduce are exactly the same as before. We also tried functionality on commit a5ee6651647f2f07ca89aca6946d3f7b79d967ea and we were able to reproduce the issue. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:08:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:08:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek updated RF-13690: -------------------------------- Environment: WildFly 8.1. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:08:32 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:08:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984746#comment-12984746 ] Martin Tomasek edited comment on RF-13690 at 7/14/14 10:07 AM: --------------------------------------------------------------- We can still reproduce issue but only on WildFly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on WildFly 8.1. was (Author: mtomasek): We can still reproduce issue but only on Wildfly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on Wildfly 8.1. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:08:33 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:08:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984747#comment-12984747 ] Martin Tomasek edited comment on RF-13691 at 7/14/14 10:07 AM: --------------------------------------------------------------- We can still reproduce issue but only on WildFly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on WildFly 8.1. was (Author: mtomasek): We can still reproduce issue but only on Wildfly 8.1. with JSF 2.2. Component works fine on EAP 6.3. with JSF < 2.2. We also tried functionality on a5ee6651647f2f07ca89aca6946d3f7b79d967ea and behaviour was the same as I described before. Works on EAP 6.3. didn't work on Wildfly 8.1. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:08:34 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Mon, 14 Jul 2014 10:08:34 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek updated RF-13691: -------------------------------- Environment: WildFly 8.1. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 10:48:33 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Jul 2014 10:48:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984785#comment-12984785 ] Matej Novotny commented on RF-11093: ------------------------------------ [~bleathem] I am trying to verify this issue but I am not sure how to create a reproducer/how to verify this. Steps to reproduce aren't much help, I can't see what is meant by "visiting component's tree" in commandLink. Could you please give me some hint? > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:02:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 11:02:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13723) fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13723: ------------------------------- Fix Version/s: 4.5.0.Beta1 > fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE > --------------------------------------------------------------------------------- > > Key: RF-13723 > URL: https://issues.jboss.org/browse/RF-13723 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: IE 11, IE 10 > Reporter: Ji?? ?tefek > Priority: Minor > Labels: IE10, IE11 > Fix For: 4.5.0.Beta1 > > > The 'Clear All' button does nothing when clicked after maxFilesQuantity reached by adding items using the 'Add' button. It works after items were added by DnD. > You have to click somewhere on the page, to get the button working. > It works fine in FF, Chrome. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:04:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 11:04:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13724: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Beta1 > > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:16:35 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 11:16:35 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13664) EDT firstChild call will return a text element when the source code is formatted to have one element per line In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13664. ---------------------------- Thanks Brian for clarification. Verified. Closing. > EDT firstChild call will return a text element when the source code is formatted to have one element per line > ------------------------------------------------------------------------------------------------------------- > > Key: RF-13664 > URL: https://issues.jboss.org/browse/RF-13664 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-tables > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Formatting the generated html and viewing the result in chrome leads to an error in the EDT call: > {{this.frozenHeaderPartElement.firstChild.rows}}. This is because when the element is followed by a newline, a text element is returned from the firstChild call. > Some solutions to this are discussed in the stackoverflow question: > http://stackoverflow.com/questions/2299807/element-firstchild-is-returning-textnode-instead-of-an-object-in-ff > I recommend we use jQuery here to resolve the first child in a cross-browser way. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:40:33 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 11:40:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reopened RF-13673: ------------------------------ Reopening the issue because setting of plain skin breaks components visual state. Please see attachments with screenshots for autocomplete or for calendar. > Backport the plain skin fix from RF 5 > ------------------------------------- > > Key: RF-13673 > URL: https://issues.jboss.org/browse/RF-13673 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: skinning > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: autocompleteInPlain.png, calendarWithPlain.png > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Backport RF-11103. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:40:34 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 14 Jul 2014 11:40:34 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13673: ----------------------------- Attachment: autocompleteInPlain.png calendarWithPlain.png > Backport the plain skin fix from RF 5 > ------------------------------------- > > Key: RF-13673 > URL: https://issues.jboss.org/browse/RF-13673 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: skinning > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: autocompleteInPlain.png, calendarWithPlain.png > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Backport RF-11103. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 12:38:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 12:38:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984862#comment-12984862 ] Brian Leathem commented on RF-13690: ------------------------------------ This issue works fine on WildFly 8.0.0.Final (jsf-impl-2.2.5-jbossorg-3), but breaks on WildFly 8.1.0.Final (jsf-impl-2.2.6-jbossorg-4). > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 12:40:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 12:40:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984863#comment-12984863 ] Brian Leathem commented on RF-13690: ------------------------------------ Issues [resolved in mojarra 2.2.6|https://java.net/jira/browse/JAVASERVERFACES-3154?jql=project%20%3D%20JAVASERVERFACES%20AND%20fixVersion%20%3D%202.2.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 12:44:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 12:44:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984863#comment-12984863 ] Brian Leathem edited comment on RF-13690 at 7/14/14 12:43 PM: -------------------------------------------------------------- Issues [resolved in mojarra 2.2.6|https://java.net/jira/browse/JAVASERVERFACES-3154?jql=project%20%3D%20JAVASERVERFACES%20AND%20fixVersion%20%3D%202.2.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]. It seems likely that this breakage is due to JAVASERVERFACES-3152. was (Author: bleathem): Issues [resolved in mojarra 2.2.6|https://java.net/jira/browse/JAVASERVERFACES-3154?jql=project%20%3D%20JAVASERVERFACES%20AND%20fixVersion%20%3D%202.2.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 12:44:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 12:44:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984863#comment-12984863 ] Brian Leathem edited comment on RF-13690 at 7/14/14 12:44 PM: -------------------------------------------------------------- Issues [resolved in mojarra 2.2.6|https://java.net/jira/browse/JAVASERVERFACES-3154?jql=project%20%3D%20JAVASERVERFACES%20AND%20fixVersion%20%3D%202.2.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]. It seems likely that this breakage is due to [JAVASERVERFACES-3152.|https://java.net/jira/browse/JAVASERVERFACES-3152] was (Author: bleathem): Issues [resolved in mojarra 2.2.6|https://java.net/jira/browse/JAVASERVERFACES-3154?jql=project%20%3D%20JAVASERVERFACES%20AND%20fixVersion%20%3D%202.2.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]. It seems likely that this breakage is due to JAVASERVERFACES-3152. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 12:46:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 12:46:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13673. -------------------------------- Resolution: Done Please file new issues for the components with a broken plain skin (a single issue to cover all broken components). It is unlikely we will resolve this for 4.5.0.Alpha3. > Backport the plain skin fix from RF 5 > ------------------------------------- > > Key: RF-13673 > URL: https://issues.jboss.org/browse/RF-13673 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: skinning > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: autocompleteInPlain.png, calendarWithPlain.png > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Backport RF-11103. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 17:10:30 2014 From: issues at jboss.org (Marcel Kolsteren (JIRA)) Date: Mon, 14 Jul 2014 17:10:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984923#comment-12984923 ] Marcel Kolsteren commented on RF-13706: --------------------------------------- I integrated my unit test into the 4.5.x branch. Please pull here: https://github.com/richfaces/richfaces/pull/94 > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 18:14:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 18:14:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984931#comment-12984931 ] Brian Leathem commented on RF-13690: ------------------------------------ I reverted the change introduced by [JAVASERVERFACES-3152|https://java.net/jira/browse/JAVASERVERFACES-3152] and rebuilt mojarra 2.2.6. Replacing the jsf-impl jar with this new one in WildFly 8.1 resolved the problem, so I can confirm this issue is caused by [JAVASERVERFACES-3152|https://java.net/jira/browse/JAVASERVERFACES-3152]. The relevant change in [JAVASERVERFACES-3152|https://java.net/jira/browse/JAVASERVERFACES-3152] is: {code} ---------------------------- Index: jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java =================================================================== --- jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java (revision 12814) +++ jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java (working copy) @@ -787,7 +787,9 @@ // Just need to check whether there are any ids under this // subtree. Make sure row index is cleared out since // getSubtreeIdsToVisit() needs our row-less client id. - setIndex(context.getFacesContext(), -1); + if (requiresRowIteration(context)) { + setIndex(context.getFacesContext(), -1); + } Collection idsToVisit = context.getSubtreeIdsToVisit(this); assert(idsToVisit != null); {code} and it's meant to address: {quote} {{}}'s value attribute gets evaluated during each and every ajax call, even when {{}} is outside the render area {quote} > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 18:20:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 18:20:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984932#comment-12984932 ] Brian Leathem commented on RF-13690: ------------------------------------ The method in full: {code} // Tests whether we need to visit our children as part of // a tree visit private boolean doVisitChildren(VisitContext context) { // Just need to check whether there are any ids under this // subtree. Make sure row index is cleared out since // getSubtreeIdsToVisit() needs our row-less client id. // // We only need to position if row iteration is actually needed. // if (requiresRowIteration(context)) { setIndex(context.getFacesContext(), -1); } Collection idsToVisit = context.getSubtreeIdsToVisit(this); assert(idsToVisit != null); // All ids or non-empty collection means we need to visit our children. return (!idsToVisit.isEmpty()); } {code} > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 18:58:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 18:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984938#comment-12984938 ] Brian Leathem commented on RF-13690: ------------------------------------ [~michpetrov] given that this and RF-13691 are the remaining blocking issues for our 4.5.0.Alpha3 release, would you mind taking a look at this issue? I'll synch up with you in the (my) morning and pick up where you leave off. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:00:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 19:00:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984939#comment-12984939 ] Brian Leathem commented on RF-13719: ------------------------------------ [~kenfinni] is this something that you can dig into and find a resolution? > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:10:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 19:10:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12448: ------------------------------- Priority: Major (was: Critical) > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Fix For: 5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calendar&skin=blueSky > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:14:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 19:14:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984940#comment-12984940 ] Brian Leathem commented on RF-12448: ------------------------------------ [~johnkeg2014] this issue has had no comments, votes, nor watches since it was created until yours. This is why it has not yet been looked at too closely. If you would like to formulate a Pull Request resolving this issue, we would gladly review it and include it in an upcoming release (provided it passes our QA). Should you be interested in doing so, have a look at the pull request guide here: https://community.jboss.org/wiki/GuideToUsePullRequestsWithGitHubAndJIRA Note: RichFaces the {{[4.5.x|https://github.com/richfaces/richfaces/tree/4.5.x]}} branch is the most logical place to resolve this issue atm. > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Fix For: 4.5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calendar&skin=blueSky > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:14:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 19:14:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-12448: ------------------------------- Fix Version/s: 4.5-Tracking (was: 5-Tracking) > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Fix For: 4.5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calendar&skin=blueSky > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 19:18:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 14 Jul 2014 19:18:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984942#comment-12984942 ] Brian Leathem commented on RF-11093: ------------------------------------ [~manovotn] you could try nesting {{a4j:repeat}} tags with the same {{var}} attribute value. [~yvalot] do you have a reproducer for this issue you could share with our QE team? > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 02:26:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 15 Jul 2014 02:26:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984971#comment-12984971 ] Matej Novotny commented on RF-13706: ------------------------------------ Thanks for tests in 4.5 branch [~marcelkolsteren]! I checked the [Jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/job/richfaces-4.5/110/testReport/org.richfaces.javascript/QUnitTest/] and it's all good :) > dequeued Ajax request not processed correctly if its source element has been updated > ------------------------------------------------------------------------------------ > > Key: RF-13706 > URL: https://issues.jboss.org/browse/RF-13706 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Reporter: Marcel Kolsteren > Assignee: Marcel Kolsteren > Fix For: 4.3.8, 4.5.0.Alpha3 > > Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page. > The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen. > To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked: > {noformat} > > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > > > > > > {noformat} > The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7. > The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 03:48:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 15 Jul 2014 03:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13673. ---------------------------- Sorry I have not worked with {{plain}} skin so far. I discussed it with Pavol, and the behavior is expected. This issue is verified. Closing. > Backport the plain skin fix from RF 5 > ------------------------------------- > > Key: RF-13673 > URL: https://issues.jboss.org/browse/RF-13673 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: skinning > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Attachments: autocompleteInPlain.png, calendarWithPlain.png > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Backport RF-11103. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 04:54:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 15 Jul 2014 04:54:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to IllegalAccessException In-Reply-To: References: Message-ID: Juraj H?ska created RF-13725: -------------------------------- Summary: Showcase can not be deployed on Tomcat 7 due to IllegalAccessException Key: RF-13725 URL: https://issues.jboss.org/browse/RF-13725 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.5.0.Alpha3 Reporter: Juraj H?ska Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: {code} SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:374) at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:374) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:02:30 2014 From: issues at jboss.org (mel turphin (JIRA)) Date: Tue, 15 Jul 2014 05:02:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13726) partialViewContext.release triggering assertNotReleased In-Reply-To: References: Message-ID: mel turphin created RF-13726: -------------------------------- Summary: partialViewContext.release triggering assertNotReleased Key: RF-13726 URL: https://issues.jboss.org/browse/RF-13726 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: core Affects Versions: 4.3.7 Environment: JSF 2.2 Mojarra + Richfaces 4.3 Eclipse + Tomcat Reporter: mel turphin Priority: Critical when the release method is called on com.sun.faces.context.FacesContextImpl the first thing that is done is to mark relased=true released = true; later on partialViewContext.release can be called partialViewContext.release(); this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released ExtendedPartialViewContextImpl org.richfaces.context.ExtendedPartialViewContext.release() setInstance(facesContext, null); facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); getAttributes --> assertNotReleased(); -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:02:31 2014 From: issues at jboss.org (Yannick Valot (JIRA)) Date: Tue, 15 Jul 2014 05:02:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985036#comment-12985036 ] Yannick Valot commented on RF-11093: ------------------------------------ Alas, this issue is quite old and I do not have a reproducer available Maybe this could do the trick : 1) In the repeat, include a commandLink and bind it to an action (action="#{someBean.someAction}") 2) In "someAction" : 2a) visit the componentTree by calling FacesContext.getCurrentInstance().getViewRoot().visitTree(...) (the callback does not actually need to do anything useful) 2b) After the visit, read the attribute value, without the patch, it will be null or contain some old value not related to the current row. > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:10:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 15 Jul 2014 05:10:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13725: ----------------------------- Summary: Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration (was: Showcase can not be deployed on Tomcat 7 due to IllegalAccessException) > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:12:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 15 Jul 2014 05:12:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985049#comment-12985049 ] Juraj H?ska commented on RF-13725: ---------------------------------- Metamer *can* be deployed on Tomcat 7, and it is because it uses different Weld version. Showcase uses Weld dependency which brings {{weld-servlet-1.1.4.Final.jar}}. Metamer works with {{weld-servlet-1.1.18.Final.jar}}. > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:20:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Tue, 15 Jul 2014 05:20:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985054#comment-12985054 ] Juraj H?ska commented on RF-13725: ---------------------------------- I have tried to deploy Showcase with {{weld-servlet-1.1.18.Final.jar}}, and it was successful. Therefore, upgrading of {{weld-servlet}} dependency would resolve this issue. > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:42:29 2014 From: issues at jboss.org (mel turphin (JIRA)) Date: Tue, 15 Jul 2014 05:42:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13726) partialViewContext.release triggering assertNotReleased In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mel turphin updated RF-13726: ----------------------------- Description: when the release method is called on com.sun.faces.context.FacesContextImpl the first thing that is done is to mark relased=true released = true; later on partialViewContext.release can be called partialViewContext.release(); this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released ExtendedPartialViewContextImpl org.richfaces.context.ExtendedPartialViewContext.release() setInstance(facesContext, null); facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); getAttributes --> assertNotReleased(); stack trace: SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception java.lang.IllegalStateException at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705) at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237) at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55) at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64) at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424) at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:744) was: when the release method is called on com.sun.faces.context.FacesContextImpl the first thing that is done is to mark relased=true released = true; later on partialViewContext.release can be called partialViewContext.release(); this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released ExtendedPartialViewContextImpl org.richfaces.context.ExtendedPartialViewContext.release() setInstance(facesContext, null); facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); getAttributes --> assertNotReleased(); > partialViewContext.release triggering assertNotReleased > ------------------------------------------------------- > > Key: RF-13726 > URL: https://issues.jboss.org/browse/RF-13726 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Environment: JSF 2.2 Mojarra + Richfaces 4.3 > Eclipse + Tomcat > Reporter: mel turphin > Priority: Critical > > when the release method is called on > com.sun.faces.context.FacesContextImpl > the first thing that is done is to mark relased=true > > released = true; > later on partialViewContext.release can be called > partialViewContext.release(); > this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released > ExtendedPartialViewContextImpl > org.richfaces.context.ExtendedPartialViewContext.release() > setInstance(facesContext, null); > facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); > getAttributes --> assertNotReleased(); > stack trace: > SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception > java.lang.IllegalStateException > at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705) > at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237) > at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55) > at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64) > at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424) > at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 06:00:36 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Tue, 15 Jul 2014 06:00:36 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985094#comment-12985094 ] Martin Tomasek commented on RF-13568: ------------------------------------- [~juergen.zimmermann] could you please provide steps to reproduce this issue? > IllegalArgumentException for PushResource.jsf > --------------------------------------------- > > Key: RF-13568 > URL: https://issues.jboss.org/browse/RF-13568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-push/poll > Affects Versions: 5.0.0.Alpha3 > Environment: WildFly snapshot with Undertow 1.0.1 > Reporter: Juergen Zimmermann > Assignee: Martin Tomasek > > Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following: > {code} > [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present > at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 08:06:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Tue, 15 Jul 2014 08:06:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985144#comment-12985144 ] Michal Petrov commented on RF-13690: ------------------------------------ What we need to happen is for the {{setIndex()}} method to execute during RestoreViewPhase. This is what's happening in {{FaceletPartialStateManagementStrategy.restoreView()}}: {code} Set hints = EnumSet.of(VisitHint.SKIP_ITERATION, VisitHint.EXECUTE_LIFECYCLE); VisitContext visitContext = VisitContext.createVisitContext(context, null, hints); viewRoot.visitTree(visitContext, new VisitCallback() { ? }); {code} The {{VisitHint.SKIP_ITERATION}} is what prevents setIndex from executing. We can intercept the creation of the visitContext in our {{ExtendedVisitContextFactory.getVisitContext()}} but I do not know if that is of any use. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:44:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:44:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11568) Collapsible panel: toggleListener doesn't work inside iteration components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985205#comment-12985205 ] Pavol Pitonak commented on RF-11568: ------------------------------------ It works on EAP 6.2, EAP 6.3 (both JSF 2.1.x) and Tomcat 7 (JSF 2.2.7) but fails on WildFly 8.1.0.Final (JSF 2.2.6) and Tomcat 7 (JSF 2.2.6). > Collapsible panel: toggleListener doesn't work inside iteration components > -------------------------------------------------------------------------- > > Key: RF-11568 > URL: https://issues.jboss.org/browse/RF-11568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.Milestone3 > Environment: RichFaces 4.1.0-SNAPSHOT > Metamer 4.1.0-SNAPSHOT r.22819 > JBoss Web 7.0.2.Final (Mojarra 2.1.3) > OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux > Chrome 14.0.835.202 @ Linux i686, Firefox 7.0.1 > Reporter: Pavol Pitonak > Labels: ci_issue > Fix For: 5-Future > > > # deploy Metamer and open http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml > # collapse the panel and verify that string "* panel collapsed" appeared in the page header > # expand the panel and verify that string "* panel expanded" appeared in the page header > # open the same page in iteration component (e.g. richList) > # collapse the panel and verify that string "* panel collapsed" appeared in the page header > # expand the panel and verify that string "* panel expanded" appeared in the page header > result: > listener is called only for collapsed panel, not for expanded panel > the component behaves wrong only in following templates: > * a4jRepeat > * richCollapsibleSubTable > * richDataGrid > * richDataTable > * richExtendedDataTable > * richList -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:56:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:56:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: Pavol Pitonak created RF-13727: ---------------------------------- Summary: Switchable panels do not work after rerendering whole page Key: RF-13727 URL: https://issues.jboss.org/browse/RF-13727 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-panels-layout-themes Affects Versions: 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 Mojarra 2.1.7-jbossorg-1 JBoss AS 7.1.1.Final OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 Reporter: Pavol Pitonak Fix For: 5-Tracking # deploy Metamer and open one of these pages: ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=a4jRepeat ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=a4jRepeat # switch/collapse panel # verify that the panel was switched # click "Full Page Refresh" button (3th button in page header) # verify that the panel is still switched result: after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) this error appears in following templates: * a4jRepeat * richCollapsibleSubTable * richDataGrid * richDataTable * richExtendedDataTable * richList -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:58:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Description: # deploy Metamer and open one of these pages: ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat # switch/collapse panel # verify that the panel was switched # click "Full Page Refresh" button (3th button in page header) # verify that the panel is still switched result: * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) * it works in other templates * seems to be JSF 2.2 issue was: # deploy Metamer and open one of these pages: ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=a4jRepeat ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=a4jRepeat # switch/collapse panel # verify that the panel was switched # click "Full Page Refresh" button (3th button in page header) # verify that the panel is still switched result: after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) this error appears in following templates: * a4jRepeat * richCollapsibleSubTable * richDataGrid * richDataTable * richExtendedDataTable * richList > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 > Mojarra 2.1.7-jbossorg-1 > JBoss AS 7.1.1.Final > OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux > Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Fix For: 5-Tracking > > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:58:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:58:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Affects Version/s: 4.5.0.Alpha3 (was: 4.1.0.Final) (was: 4.2.0.Final) (was: 4.2.1.CR1) > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 > Mojarra 2.1.7-jbossorg-1 > JBoss AS 7.1.1.Final > OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux > Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Fix For: 5-Tracking > > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:58:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:58:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Fix Version/s: (was: 5-Tracking) > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 > Mojarra 2.1.7-jbossorg-1 > JBoss AS 7.1.1.Final > OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux > Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Reporter: Pavol Pitonak > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 09:58:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 09:58:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12131) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-12131: ------------------------------- Environment: RichFaces 4.5.0-SNAPSHOT Metamer 4.5.0-SNAPSHOT Mojarra 2.2.6/2.2.7 Apache Tomcat 7.0.54, WildFly 8.1.0.Final OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux Firefox 30.0 @ Linux x86_64 was: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 Mojarra 2.1.7-jbossorg-1 JBoss AS 7.1.1.Final OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-12131 > URL: https://issues.jboss.org/browse/RF-12131 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Fix For: 5-Tracking > > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=a4jRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=a4jRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > this error appears in following templates: > * a4jRepeat > * richCollapsibleSubTable > * richDataGrid > * richDataTable > * richExtendedDataTable > * richList -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:00:32 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 10:00:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Environment: RichFaces 4.5.0-SNAPSHOT Metamer 4.5.0-SNAPSHOT Mojarra 2.2.6/2.2.7 Apache Tomcat 7.0.54, WildFly 8.1.0.Final OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux Firefox 30.0 @ Linux x86_64 was: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 Mojarra 2.1.7-jbossorg-1 JBoss AS 7.1.1.Final OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:00:32 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 10:00:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12131) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-12131: ------------------------------- Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 Mojarra 2.1.7-jbossorg-1 JBoss AS 7.1.1.Final OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 was: RichFaces 4.5.0-SNAPSHOT Metamer 4.5.0-SNAPSHOT Mojarra 2.2.6/2.2.7 Apache Tomcat 7.0.54, WildFly 8.1.0.Final OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux Firefox 30.0 @ Linux x86_64 > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-12131 > URL: https://issues.jboss.org/browse/RF-12131 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1 > Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1 > Mojarra 2.1.7-jbossorg-1 > JBoss AS 7.1.1.Final > OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux > Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Fix For: 5-Tracking > > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=a4jRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=a4jRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > this error appears in following templates: > * a4jRepeat > * richCollapsibleSubTable > * richDataGrid > * richDataTable > * richExtendedDataTable > * richList -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:06:33 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 10:06:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Labels: jsf22 (was: ) > Switchable panels do not work after rerendering whole page > ---------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22 > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:06:34 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Tue, 15 Jul 2014 10:06:34 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13727: ------------------------------- Summary: Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 (was: Switchable panels do not work after rerendering whole page) > Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 > ---------------------------------------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22 > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:10:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 10:10:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13725: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Fix For: 4.5.0.Beta1 > > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:36:29 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Tue, 15 Jul 2014 11:36:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Rich edit cant display after page load if page is opened directly In-Reply-To: References: Message-ID: Martin Tomasek created RF-13728: ----------------------------------- Summary: Rich edit cant display after page load if page is opened directly Key: RF-13728 URL: https://issues.jboss.org/browse/RF-13728 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.5.0.Alpha3 Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. Reporter: Martin Tomasek Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:46:32 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 11:46:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13727: ------------------------------- Labels: jsf22 uiRepeat#setIndex (was: jsf22) > Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 > ---------------------------------------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22, uiRepeat#setIndex > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:46:34 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 11:46:34 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11568) Collapsible panel: toggleListener doesn't work inside iteration components In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11568: ------------------------------- Labels: ci_issue uiRepeat#setIndex (was: ci_issue) > Collapsible panel: toggleListener doesn't work inside iteration components > -------------------------------------------------------------------------- > > Key: RF-11568 > URL: https://issues.jboss.org/browse/RF-11568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.1.0.Milestone3 > Environment: RichFaces 4.1.0-SNAPSHOT > Metamer 4.1.0-SNAPSHOT r.22819 > JBoss Web 7.0.2.Final (Mojarra 2.1.3) > OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux > Chrome 14.0.835.202 @ Linux i686, Firefox 7.0.1 > Reporter: Pavol Pitonak > Labels: ci_issue, uiRepeat#setIndex > Fix For: 5-Future > > > # deploy Metamer and open http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml > # collapse the panel and verify that string "* panel collapsed" appeared in the page header > # expand the panel and verify that string "* panel expanded" appeared in the page header > # open the same page in iteration component (e.g. richList) > # collapse the panel and verify that string "* panel collapsed" appeared in the page header > # expand the panel and verify that string "* panel expanded" appeared in the page header > result: > listener is called only for collapsed panel, not for expanded panel > the component behaves wrong only in following templates: > * a4jRepeat > * richCollapsibleSubTable > * richDataGrid > * richDataTable > * richExtendedDataTable > * richList -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:46:36 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 11:46:36 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13690: ------------------------------- Labels: regression uiRepeat#setIndex (was: regression) > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression, uiRepeat#setIndex > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:48:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 11:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13691: ------------------------------- Labels: regression uiRepeat#setIndex (was: regression) > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression, uiRepeat#setIndex > Fix For: 4.5.0.Alpha3 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:58:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 11:58:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13525) Remove GAE sample from Archetypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13525: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 5.0.0.Alpha4) > Remove GAE sample from Archetypes > --------------------------------- > > Key: RF-13525 > URL: https://issues.jboss.org/browse/RF-13525 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 5.0.0.Alpha3 > Reporter: Luk?? Fry? > Fix For: 4.5.0.Beta1 > > > I suggest to remove GAE archetype since it is unmaintained. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 12:00:33 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 12:00:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13525) Remove GAE sample from Archetypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985284#comment-12985284 ] Brian Leathem commented on RF-13525: ------------------------------------ We should additionally remove the unmaintained _components_ archetype. > Remove GAE sample from Archetypes > --------------------------------- > > Key: RF-13525 > URL: https://issues.jboss.org/browse/RF-13525 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 5.0.0.Alpha3 > Reporter: Luk?? Fry? > Fix For: 4.5.0.Beta1 > > > I suggest to remove GAE archetype since it is unmaintained. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 13:40:29 2014 From: issues at jboss.org (mel turphin (JIRA)) Date: Tue, 15 Jul 2014 13:40:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13726) partialViewContext.release triggering assertNotReleased In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mel turphin updated RF-13726: ----------------------------- looks related to [richfaces-issues] [JBoss JIRA] (RF-13685) > partialViewContext.release triggering assertNotReleased > ------------------------------------------------------- > > Key: RF-13726 > URL: https://issues.jboss.org/browse/RF-13726 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Environment: JSF 2.2 Mojarra + Richfaces 4.3 > Eclipse + Tomcat > Reporter: mel turphin > Priority: Critical > > when the release method is called on > com.sun.faces.context.FacesContextImpl > the first thing that is done is to mark relased=true > > released = true; > later on partialViewContext.release can be called > partialViewContext.release(); > this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released > ExtendedPartialViewContextImpl > org.richfaces.context.ExtendedPartialViewContext.release() > setInstance(facesContext, null); > facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); > getAttributes --> assertNotReleased(); > stack trace: > SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception > java.lang.IllegalStateException > at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705) > at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237) > at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55) > at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64) > at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424) > at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:20:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:20:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985414#comment-12985414 ] Brian Leathem commented on RF-13690: ------------------------------------ This regression is caused by an upstream change in mojarra. We need to create a reproducer and file an upstream issue. Bumping to 4.5.0.Beta1. > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression, uiRepeat#setIndex > Fix For: 4.5.0.Beta1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:20:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:20:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13690: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 4.5.0.Alpha3) > DataTable in uiRepeat - scrolling in table makes columns unsorted again > ----------------------------------------------------------------------- > > Key: RF-13690 > URL: https://issues.jboss.org/browse/RF-13690 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression, uiRepeat#setIndex > Fix For: 4.5.0.Beta1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:20:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:20:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985415#comment-12985415 ] Brian Leathem commented on RF-13691: ------------------------------------ Re-check once RF-13690 is resolved to make sure this is indeed a duplicate. > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Assignee: Brian Leathem > Labels: regression, uiRepeat#setIndex > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:20:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:20:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13691) EDT in uiRepeat - selection corrupted in multiple paged table In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13691. -------------------------------- Assignee: (was: Brian Leathem) Fix Version/s: (was: 4.5.0.Alpha3) Resolution: Duplicate Issue > EDT in uiRepeat - selection corrupted in multiple paged table > ------------------------------------------------------------- > > Key: RF-13691 > URL: https://issues.jboss.org/browse/RF-13691 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Juraj H?ska > Labels: regression, uiRepeat#setIndex > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When {{EDT}} is in {{uiRepeat}} and has multiple pages, then selection of rows functionality does not work as expected. > It seems that there is a problem with row indices. Please see steps to reproduce. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:24:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:24:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985417#comment-12985417 ] Brian Leathem commented on RF-13727: ------------------------------------ [~ppitonak] you have {{Mojarra 2.2.6}} in the _environment_ of this issue. Is that correct? Can you check in WildFly 8.0.0.Final to make sure that this is indeed an issue in {{Mojarra 2.2.6}}? > Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 > ---------------------------------------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22, uiRepeat#setIndex > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:26:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:26:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13726) partialViewContext.release triggering assertNotReleased In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13726. -------------------------------- Resolution: Duplicate Issue > partialViewContext.release triggering assertNotReleased > ------------------------------------------------------- > > Key: RF-13726 > URL: https://issues.jboss.org/browse/RF-13726 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: core > Affects Versions: 4.3.7 > Environment: JSF 2.2 Mojarra + Richfaces 4.3 > Eclipse + Tomcat > Reporter: mel turphin > Priority: Critical > > when the release method is called on > com.sun.faces.context.FacesContextImpl > the first thing that is done is to mark relased=true > > released = true; > later on partialViewContext.release can be called > partialViewContext.release(); > this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released > ExtendedPartialViewContextImpl > org.richfaces.context.ExtendedPartialViewContext.release() > setInstance(facesContext, null); > facesContext.getAttributes().put(ATTRIBUTE_NAME, instance); > getAttributes --> assertNotReleased(); > stack trace: > SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception > java.lang.IllegalStateException > at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705) > at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237) > at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55) > at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64) > at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424) > at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 20:28:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 15 Jul 2014 20:28:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Rich edit cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985418#comment-12985418 ] Brian Leathem commented on RF-13728: ------------------------------------ I am not able to reproduce this. Can you verify this is an issue on other machines/environments? > Rich edit cant display after page load if page is opened directly > ----------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 01:48:30 2014 From: issues at jboss.org (Anurag Debnath (JIRA)) Date: Wed, 16 Jul 2014 01:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anurag Debnath updated RF-13719: -------------------------------- > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 03:26:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 03:26:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13728: ----------------------------- Summary: Editor cant display after page load if page is opened directly (was: Rich edit cant display after page load if page is opened directly) > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 03:28:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 03:28:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13728: ----------------------------- Description: Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: {code} Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 {code} Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. was: Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 03:50:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 03:50:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985476#comment-12985476 ] Juraj H?ska commented on RF-13728: ---------------------------------- I can reproduce the issue as well on my machine, with {{EAP 6.3.0.ER8}}. > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 03:54:33 2014 From: issues at jboss.org (Martin Weiler (JIRA)) Date: Wed, 16 Jul 2014 03:54:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Weiler updated RF-13719: ------------------------------- > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 03:54:34 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Wed, 16 Jul 2014 03:54:34 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985480#comment-12985480 ] Martin Tomasek commented on RF-13728: ------------------------------------- I tried showcase and component didnt work properly. Step do reproduce are the same as above with url: http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=editor&skin=blueSky > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 04:10:30 2014 From: issues at jboss.org (Anurag Debnath (JIRA)) Date: Wed, 16 Jul 2014 04:10:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anurag Debnath updated RF-13719: -------------------------------- > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:00:33 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 16 Jul 2014 07:00:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov reassigned RF-13728: ---------------------------------- Assignee: Michal Petrov > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:06:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Wed, 16 Jul 2014 07:06:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985565#comment-12985565 ] Pavol Pitonak commented on RF-13727: ------------------------------------ It does work in WildFly 8.0 (Mojarra 2.2.5). > Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 > ---------------------------------------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22, uiRepeat#setIndex > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:16:31 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 16 Jul 2014 07:16:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13729) Kitchensink archetype on Wildfly with mobile devices In-Reply-To: References: Message-ID: Matej Novotny created RF-13729: ---------------------------------- Summary: Kitchensink archetype on Wildfly with mobile devices Key: RF-13729 URL: https://issues.jboss.org/browse/RF-13729 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: archetype Affects Versions: 4.5.0.Alpha3 Environment: Server: Wildfly 8.1 Final (or older version) Archetype: kitchensink 4.5.0Alpha3 Some mobile device (eg. smartphone) Reporter: Matej Novotny When you deploy kitchensink to Wildfly and access the main page via mobile device (clear browser memory and cache), it loads desktop page instead of mobile. If I use EAP (tried with 6.2.4 and 6.3) and load the main apge with mobile device, it loads the correct page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:22:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 16 Jul 2014 07:22:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13729) Kitchensink archetype on Wildfly with mobile devices In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985570#comment-12985570 ] Matej Novotny commented on RF-13729: ------------------------------------ [~jhuska] told me about a similar unresolved issue he reported: RF-12386. Although that one might be related only to myfaces and/or Tomcat. > Kitchensink archetype on Wildfly with mobile devices > ---------------------------------------------------- > > Key: RF-13729 > URL: https://issues.jboss.org/browse/RF-13729 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 4.5.0.Alpha3 > Environment: Server: Wildfly 8.1 Final (or older version) > Archetype: kitchensink 4.5.0Alpha3 > Some mobile device (eg. smartphone) > Reporter: Matej Novotny > > When you deploy kitchensink to Wildfly and access the main page via mobile device (clear browser memory and cache), it loads desktop page instead of mobile. > If I use EAP (tried with 6.2.4 and 6.3) and load the main apge with mobile device, it loads the correct page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 07:24:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 16 Jul 2014 07:24:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13720) Mobile Showcase - CSV demo with JS error and does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985572#comment-12985572 ] Matej Novotny commented on RF-13720: ------------------------------------ Same bug can be observed with kitchensink archetype (4.5.0.Alpha3) on mobile devices. > Mobile Showcase - CSV demo with JS error and does not work > ---------------------------------------------------------- > > Key: RF-13720 > URL: https://issues.jboss.org/browse/RF-13720 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.5.0.Alpha3 > Environment: mobile devices > Reporter: Juraj H?ska > Labels: mobile, regression > Fix For: 4.5.0.Beta1 > > > Showcase demo for _client side validation_ is not working on mobile devices. > There is a JS error thrown, stating: > {code} > TypeError: RichFaces.csv.validate is not a function > if(clientHandler){clientHandler.call(this,event) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:26:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Wed, 16 Jul 2014 10:26:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: Martin Tomasek created RF-13730: ----------------------------------- Summary: Upgrade Mojarra 2.2.7 in build/pom.xml Key: RF-13730 URL: https://issues.jboss.org/browse/RF-13730 Project: RichFaces Issue Type: Component Upgrade Security Level: Public (Everyone can see) Reporter: Martin Tomasek In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from {code} 2.2.6 {code} to {code} 2.2.7 {code} Information: WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:58:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 16 Jul 2014 10:58:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985677#comment-12985677 ] Michal Petrov commented on RF-13728: ------------------------------------ There seems to be an issue with resource path resolution. In the editor template we're setting {code} window.CKEDITOR_BASEPATH = '#{facesContext.externalContext.requestContextPath}/org.richfaces.resources/javax.faces.resource/org.richfaces.ckeditor/'; {code} however the editor is initializing before the variable is set. I can only reproduce it if I restart the browser though, clear cache + reload does not affect it. > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 11:46:32 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 11:46:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request In-Reply-To: References: Message-ID: Juraj H?ska created RF-13731: -------------------------------- Summary: NPE on Tomcat 7 after Ajax request Key: RF-13731 URL: https://issues.jboss.org/browse/RF-13731 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.5.0.Alpha3 Environment: Tomcat 7 and Firefox only Reporter: Juraj H?ska There is a NPE thrown after an AJAX request in either showcase or in Metamer: {code} SEVERE: java.lang.NullPointerException at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) {code} Exception is being thrown only after initial page load, after refresh it works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 11:48:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 11:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13731: ----------------------------- Description: There is a NPE thrown after an AJAX request in either showcase (showcase can be deployed only when {{weld-servlet.jar}} is changed manually to higher version - RF-13725) or in Metamer: {code} SEVERE: java.lang.NullPointerException at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) {code} Exception is being thrown only after initial page load, after refresh it works. was: There is a NPE thrown after an AJAX request in either showcase or in Metamer: {code} SEVERE: java.lang.NullPointerException at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) {code} Exception is being thrown only after initial page load, after refresh it works. > NPE on Tomcat 7 after Ajax request > ---------------------------------- > > Key: RF-13731 > URL: https://issues.jboss.org/browse/RF-13731 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Environment: Tomcat 7 and Firefox only > Reporter: Juraj H?ska > > There is a NPE thrown after an AJAX request in either showcase (showcase can be deployed only when {{weld-servlet.jar}} is changed manually to higher version - RF-13725) or in Metamer: > {code} > SEVERE: java.lang.NullPointerException > at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) > at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) > at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) > at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > {code} > Exception is being thrown only after initial page load, after refresh it works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 11:48:31 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 16 Jul 2014 11:48:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985697#comment-12985697 ] Michal Petrov commented on RF-13728: ------------------------------------ Ok, the basepath being null is no problem. If the basepath isn't found the script (ckeditor.js) goes through {code} on subsequent requests the id is not there, the problem is that the URL with jsessionid doesn't match the regex that's supposed to find it. So this is an issue in CKEditor itself. > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 11:48:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Wed, 16 Jul 2014 11:48:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-13731: ----------------------------- Steps to Reproduce: # e.g. on Metamer # deploy it on Tomcat 7 # load http://localhost:8080/metamer # try to type something in the search input # see the NPE in Tomcat log > NPE on Tomcat 7 after Ajax request > ---------------------------------- > > Key: RF-13731 > URL: https://issues.jboss.org/browse/RF-13731 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Environment: Tomcat 7 and Firefox only > Reporter: Juraj H?ska > > There is a NPE thrown after an AJAX request in either showcase (showcase can be deployed only when {{weld-servlet.jar}} is changed manually to higher version - RF-13725) or in Metamer: > {code} > SEVERE: java.lang.NullPointerException > at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) > at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) > at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) > at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > {code} > Exception is being thrown only after initial page load, after refresh it works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:06:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 12:06:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13728: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:06:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 12:06:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13729) Kitchensink archetype on Wildfly with mobile devices In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13729: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Kitchensink archetype on Wildfly with mobile devices > ---------------------------------------------------- > > Key: RF-13729 > URL: https://issues.jboss.org/browse/RF-13729 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 4.5.0.Alpha3 > Environment: Server: Wildfly 8.1 Final (or older version) > Archetype: kitchensink 4.5.0Alpha3 > Some mobile device (eg. smartphone) > Reporter: Matej Novotny > Fix For: 4.5.0.Beta1 > > > When you deploy kitchensink to Wildfly and access the main page via mobile device (clear browser memory and cache), it loads desktop page instead of mobile. > If I use EAP (tried with 6.2.4 and 6.3) and load the main apge with mobile device, it loads the correct page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:08:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 12:08:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13731: ------------------------------- Fix Version/s: 4.5.0.Beta1 > NPE on Tomcat 7 after Ajax request > ---------------------------------- > > Key: RF-13731 > URL: https://issues.jboss.org/browse/RF-13731 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Environment: Tomcat 7 and Firefox only > Reporter: Juraj H?ska > Fix For: 4.5.0.Beta1 > > > There is a NPE thrown after an AJAX request in either showcase (showcase can be deployed only when {{weld-servlet.jar}} is changed manually to higher version - RF-13725) or in Metamer: > {code} > SEVERE: java.lang.NullPointerException > at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) > at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) > at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) > at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) > at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) > at org.richfaces.demo.arrangeablemodel.PersistenceLifecycle.execute(PersistenceLifecycle.java:58) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:96) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > {code} > Exception is being thrown only after initial page load, after refresh it works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:10:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 12:10:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13727: ------------------------------- Fix Version/s: 4.5.0.Beta1 > Switchable panels do not work after rerendering whole page inside ui:repeat with JSF 2.2 > ---------------------------------------------------------------------------------------- > > Key: RF-13727 > URL: https://issues.jboss.org/browse/RF-13727 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-panels-layout-themes > Affects Versions: 4.5.0.Alpha3 > Environment: RichFaces 4.5.0-SNAPSHOT > Metamer 4.5.0-SNAPSHOT > Mojarra 2.2.6/2.2.7 > Apache Tomcat 7.0.54, WildFly 8.1.0.Final > OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux > Firefox 30.0 @ Linux x86_64 > Reporter: Pavol Pitonak > Labels: jsf22, uiRepeat#setIndex > Fix For: 4.5.0.Beta1 > > > # deploy Metamer and open one of these pages: > ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.xhtml?templates=uiRepeat > ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simple.xhtml?templates=uiRepeat > # switch/collapse panel > # verify that the panel was switched > # click "Full Page Refresh" button (3th button in page header) > # verify that the panel is still switched > result: > * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded) > * it works in other templates > * seems to be JSF 2.2 issue -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 17:58:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 17:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985790#comment-12985790 ] Brian Leathem commented on RF-13730: ------------------------------------ We tack the JSF 2.2 version in released versions of WildFly. I'll close this issue for now, but we should re-visit it when WildFly 9 hits the Beta / CR stage. > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 17:58:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 16 Jul 2014 17:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13730. -------------------------------- Resolution: Deferred > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 03:12:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 17 Jul 2014 03:12:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13730: ------------------------------- Affects Version/s: 4.5.0.Alpha3 > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 03:20:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 17 Jul 2014 03:20:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13652) Forward port the 4.3.7 fixes into the 4.5.x branch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13652. ---------------------------- Thanks for clarification Brian. Verified. Closing. > Forward port the 4.3.7 fixes into the 4.5.x branch > -------------------------------------------------- > > Key: RF-13652 > URL: https://issues.jboss.org/browse/RF-13652 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 4.5.0.Alpha3 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 03:20:30 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 17 Jul 2014 03:20:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska reassigned RF-11093: -------------------------------- Assignee: Juraj H?ska (was: Yannick Valot) > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 03:46:29 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Thu, 17 Jul 2014 03:46:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985844#comment-12985844 ] Pavol Pitonak commented on RF-13730: ------------------------------------ [~bleathem], why didn't you just set fixVersion to 4.5-Tracking? > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 04:20:30 2014 From: issues at jboss.org (Byambaa MD (JIRA)) Date: Thu, 17 Jul 2014 04:20:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13712) FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985850#comment-12985850 ] Byambaa MD commented on RF-13712: --------------------------------- Okey. i will test only richfaces environment. > FileUpload does not work on Wildfly 8.0 and Wildfly 8.1 > ------------------------------------------------------- > > Key: RF-13712 > URL: https://issues.jboss.org/browse/RF-13712 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.7 > Environment: 4.3.7 FileUpload does not work on wildfly > Reporter: Byambaa MD > Labels: waiting_on_user > Attachments: AS error log.png, can't Render.png, chrome js error log.png, file upload done !.png, fileupload error on wildfly.png, Render code.png, Web application libraries and main page structure.png > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 05:56:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 17 Jul 2014 05:56:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RF-13719: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1120627 > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 08:14:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 17 Jul 2014 08:14:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated RF-13711: ------------------------------- Steps to Reproduce: For verification with automated test: * Start Wildfly * Run [Metamer test|https://github.com/richfaces/richfaces-qa/blob/4.5.x/metamer/ftest/src/test/java/org/richfaces/tests/metamer/ftest/a4jStatus/TestRF13711.java] ** {{mvn clean verify -Pwildfly-remote-8-1 -Dtest=TestRF13711}} * See the results Alternatively you can reproduce it manually: * Start Wildfly * Deploy Metamer * Go to [this page|http://localhost:8080/metamer/faces/components/a4jStatus/rf-13711.xhtml] * Follow the instructions on that page to reproduce this was: * Start Wildfly * Deploy Metamer * Go to [this page|http://localhost:8080/metamer/faces/components/a4jAjax/rf-13711.xhtml] * Open browser console * Click the button ** Expected: Three lines appear in the console: *** {{start}} //triggered by a4j:status *** {{POST...}} //request itself *** {{stop}} //triggered by a4j:status ** Actual: Only request itself is displayed in console > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 08:16:33 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 17 Jul 2014 08:16:33 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985892#comment-12985892 ] Matej Novotny commented on RF-13711: ------------------------------------ I refactored and moved the reproducer to correct section in Metamer (in the a4jStatus instead of a4jAjax). There is also and automated test I created. It is marked as Future and IssueTracking until we address this issue. Both changes should be in all necessary branches. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 08:20:29 2014 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 17 Jul 2014 08:20:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13711) a4j:ajax status does not work as expected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985892#comment-12985892 ] Matej Novotny edited comment on RF-13711 at 7/17/14 8:19 AM: ------------------------------------------------------------- I refactored and moved the reproducer to correct section in Metamer (in the a4jStatus instead of a4jAjax). There is also and automated test I created. It is marked as Future and IssueTracking until we address this issue. Both changes should be in all necessary branches. Steps to reproduce have been updated accordingly. was (Author: manovotn): I refactored and moved the reproducer to correct section in Metamer (in the a4jStatus instead of a4jAjax). There is also and automated test I created. It is marked as Future and IssueTracking until we address this issue. Both changes should be in all necessary branches. > a4j:ajax status does not work as expected > ----------------------------------------- > > Key: RF-13711 > URL: https://issues.jboss.org/browse/RF-13711 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.7, 4.3.8 > Environment: IE8, Mozilla Firefox 30 > Reporter: Evgeny Mironenko > Assignee: Matej Novotny > Fix For: 4.5-Tracking > > > Status attribute for {{a4j:ajax}} does not work as expected. > I tried to create simple project with content: > {code:title=index.xhtml} > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > xmlns:h="http://java.sun.com/jsf/html" > xmlns:a4j="http://richfaces.org/a4j"> > > > > onstop="console.log('stop')"/> >
> > > > > >
> > > {code} > It did not work for me. I do not see any log messages in the console. > As workaround I can use the {{render}} attribute instead of {{status}}, but we use it for another goals, am I right? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 09:22:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 17 Jul 2014 09:22:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985925#comment-12985925 ] Juraj H?ska commented on RF-11093: ---------------------------------- Verified on this branch: https://github.com/richfaces/richfaces-qa/tree/RF-11093 * [facelet|https://github.com/richfaces/richfaces-qa/blob/RF-11093/metamer/application/src/main/webapp/components/a4jRepeat/RF-11093.xhtml] * [bean|https://github.com/richfaces/richfaces-qa/blob/RF-11093/metamer/application/src/main/java/org/richfaces/tests/metamer/bean/issues/RF11093.java] With the older versions of RF the {{var}} value is {{null}}, with {{4.5.Alpha3}} correct value is logged. Verified. Closing. > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Juraj H?ska > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 09:22:31 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 17 Jul 2014 09:22:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska updated RF-11093: ----------------------------- Assignee: Yannick Valot (was: Juraj H?ska) > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 09:22:32 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Thu, 17 Jul 2014 09:22:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11093) UIDataAdaptor context variable backup broken (reentrance problem) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-11093. ---------------------------- > UIDataAdaptor context variable backup broken (reentrance problem) > ----------------------------------------------------------------- > > Key: RF-11093 > URL: https://issues.jboss.org/browse/RF-11093 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Environment: Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2. > Reporter: Yannick Valot > Assignee: Yannick Valot > Fix For: 4.5.0.Alpha3 > > Attachments: UIDataAdaptor.java.patch > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I am encountering a reentrance problem with org.richfaces.component.UIDataAdaptor (using it as a dataTable). > I need to perform a visit of the component tree while executing an action on a command link in one row of the same table. > {code} > > ... some stuff here ... > > ... some stuff here ... > > {code} > After the action on the command link has visited the component tree, myItem is no longer available in context. > When the UIDataAdaptor sets or resets the "myItem" context variable, it backs up any previous value by calling captureOrigValue(FacesContext), and later restores it by calling restoreOrigValue(FacesContext), but it looks as if the visit backs the variable up twice (in a nested fashion), and it erases myItem between the two backups : > - backup variable (old value is correctly backed up) (in visitTree(VisitContext visitContext, VisitCallback callback)) > - erase variable (setRowKey(facesContext, null) in same function) > - erase variable (doVisitChildren(VisitContext context, boolean visitRows)) > - erase variable (visitTree(VisitContext visitContext, VisitCallback callback)) > - backup variable (erases backed up value) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - ... > - restore value (restores null) (walk(FacesContext faces, DataVisitor visitor, Object argument)) > - restore value (restores null) (in visitTree(VisitContext visitContext, VisitCallback callback)) > etc. > The problem can be solved by *stacking* backed up variables, instead of storing them in a simple attribute, to allow for any kind of reentrance. > (I do not say that this is the best possible patch, but it has solved the problem for me). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 09:30:30 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Thu, 17 Jul 2014 09:30:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13732) RichList with scroll bar doesn't work correctly inside uiRepeat In-Reply-To: References: Message-ID: Martin Tomasek created RF-13732: ----------------------------------- Summary: RichList with scroll bar doesn't work correctly inside uiRepeat Key: RF-13732 URL: https://issues.jboss.org/browse/RF-13732 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-ScrollableDataTable Affects Versions: 4.5.0.Alpha3 Environment: WildFly 8.1. Reporter: Martin Tomasek RichList with scroller doesn't work correctly if component is inside uiRepeat component. Scroller is visible and display data correctly but if user navigate to second page and then to first page, scroller stuck on second page but displayed data are from first page. The next page icon ( >> ) doesn't work correctly inside ui:Repeat. It still stuck on second page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 14:06:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 17 Jul 2014 14:06:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13732) RichList with scroll bar doesn't work correctly inside uiRepeat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13732: ------------------------------- Labels: uiRepeat#setIndex (was: ) > RichList with scroll bar doesn't work correctly inside uiRepeat > --------------------------------------------------------------- > > Key: RF-13732 > URL: https://issues.jboss.org/browse/RF-13732 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-ScrollableDataTable > Affects Versions: 4.5.0.Alpha3 > Environment: WildFly 8.1. > Reporter: Martin Tomasek > Labels: uiRepeat#setIndex > > RichList with scroller doesn't work correctly if component is inside uiRepeat component. > Scroller is visible and display data correctly but if user navigate to second page and then to first page, scroller stuck on second page but displayed data are from first page. > The next page icon ( >> ) doesn't work correctly inside ui:Repeat. It still stuck on second page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 14:06:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Thu, 17 Jul 2014 14:06:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986021#comment-12986021 ] Brian Leathem commented on RF-13730: ------------------------------------ That would have worked to. Feel free to re-open and do so [~ppitonak]. > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 02:48:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Fri, 18 Jul 2014 02:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak reopened RF-13730: -------------------------------- > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Martin Tomasek > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 02:48:30 2014 From: issues at jboss.org (Pavol Pitonak (JIRA)) Date: Fri, 18 Jul 2014 02:48:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13730) Upgrade Mojarra 2.2.7 in build/pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavol Pitonak updated RF-13730: ------------------------------- Fix Version/s: 4.5-Tracking > Upgrade Mojarra 2.2.7 in build/pom.xml > -------------------------------------- > > Key: RF-13730 > URL: https://issues.jboss.org/browse/RF-13730 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Martin Tomasek > Fix For: 4.5-Tracking > > > In related to [RFPL-3242|https://issues.jboss.org/browse/RFPL-3242] we need upgrade Mojarra to version 2.2.7. Upgrade please file build/pom.xml and change value from > {code} > 2.2.6 > {code} > to > {code} > 2.2.7 > {code} > Information: > WildFly 9.0.0.Alpha1-SNAPSHOT has version 2.2.7-jbossorg-1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 04:04:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Fri, 18 Jul 2014 04:04:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13728. -------------------------------- Resolution: Done > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 04:28:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 18 Jul 2014 04:28:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986151#comment-12986151 ] RH Bugzilla Integration commented on RF-13719: ---------------------------------------------- Jon?? Trantina changed the Status of [bug 1120627|https://bugzilla.redhat.com/show_bug.cgi?id=1120627] from NEW to CLOSED > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 05:44:31 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Fri, 18 Jul 2014 05:44:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13728) Editor cant display after page load if page is opened directly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek closed RF-13728. ------------------------------- Verified in 4.5.x. > Editor cant display after page load if page is opened directly > -------------------------------------------------------------- > > Key: RF-13728 > URL: https://issues.jboss.org/browse/RF-13728 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: Fifefox 30, Chrome 35.0.1916.153, EAP 6.3. > Reporter: Martin Tomasek > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > Component richEditor is not displayed after page load if browser has empty cache and page is opened directy. For example Google Chrome anonymous mode, Firefox with cleared cache (ctrl+shift+d+delete - clear all) opening url http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain. Console displays these error messages: > {code} > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/config.js?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/skins/moono/editor.css?t=E4KA > Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/metamer/faces/components/richEditor/lang/en.js?t=E4KA > Uncaught TypeError: Cannot set property 'dir' of undefined ckeditor.js;jsessionid=cCSt9DELY4qr8as9rF23pBU7:218 > {code} > Component starts work correctly after another page load or if your first request is not to this component but to another one - open http://localhost:8080/metamer/ and then directly http://localhost:8080/metamer/faces/components/richEditor/simple.xhtml?template=plain - component is visible and work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 07:44:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Fri, 18 Jul 2014 07:44:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13725. -------------------------------- Assignee: Michal Petrov Resolution: Done > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 08:26:29 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Fri, 18 Jul 2014 08:26:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986261#comment-12986261 ] Juergen Zimmermann commented on RF-13568: ----------------------------------------- When using the latest WildFly snapshot (and thus Undertow 1.1.0.Beta5), then the issue is gone. > IllegalArgumentException for PushResource.jsf > --------------------------------------------- > > Key: RF-13568 > URL: https://issues.jboss.org/browse/RF-13568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-push/poll > Affects Versions: 5.0.0.Alpha3 > Environment: WildFly snapshot with Undertow 1.0.1 > Reporter: Juergen Zimmermann > Assignee: Martin Tomasek > > Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following: > {code} > [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present > at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 10:22:30 2014 From: issues at jboss.org (Martin Tomasek (JIRA)) Date: Fri, 18 Jul 2014 10:22:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tomasek resolved RF-13568. --------------------------------- Resolution: Out of Date I will mark this issue as out-of-date, because issue is gone since new version of WildFly. [~juergen.zimmermann] thank you for cooperation. > IllegalArgumentException for PushResource.jsf > --------------------------------------------- > > Key: RF-13568 > URL: https://issues.jboss.org/browse/RF-13568 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-push/poll > Affects Versions: 5.0.0.Alpha3 > Environment: WildFly snapshot with Undertow 1.0.1 > Reporter: Juergen Zimmermann > Assignee: Martin Tomasek > > Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following: > {code} > [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present > at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 11:40:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 18 Jul 2014 11:40:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13724: ------------------------------- Assignee: Juraj H?ska (was: Michal Petrov) > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Beta1 > > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 11:42:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 18 Jul 2014 11:42:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13719: ------------------------------- Comment: was deleted (was: A comment with security level 'Red Hat' was removed.) > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 11:42:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Fri, 18 Jul 2014 11:42:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-13719: ------------------------------- Comment: was deleted (was: Jon?? Trantina changed the Status of [bug 1120627|https://bugzilla.redhat.com/show_bug.cgi?id=1120627] from NEW to CLOSED) > rich.fileUpload breaks form action in portal > -------------------------------------------- > > Key: RF-13719 > URL: https://issues.jboss.org/browse/RF-13719 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.5 > Environment: JBoss Portal 6.1.1 > Reporter: Jon?? Trantina > Labels: gss > Attachments: reproducer.zip, reproducer2.zip > > > When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well. > In fileupload.js __submit method there is the following code: > {code:JavaScript} > var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']"); > var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action"); > {code} > the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails. > In portal the solution is > {code:JavaScript} > var originalFormAction =this.form.attr("action"); > {code} > and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments. > Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly? > To reproduce you can use the reproducer attached. > Example URLs: > form action > {code} > /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action > {code} > input[name='javax.faces.encodedURL'] > {code} > /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 19 09:38:31 2014 From: issues at jboss.org (Edward I (JIRA)) Date: Sat, 19 Jul 2014 09:38:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-8125) Tables: built-in sorting/filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986464#comment-12986464 ] Edward I commented on RF-8125: ------------------------------ Is this going to be added to dataTable as well? > Tables: built-in sorting/filtering > ---------------------------------- > > Key: RF-8125 > URL: https://issues.jboss.org/browse/RF-8125 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Reporter: Anton Belevich > Assignee: Brian Leathem > Fix For: 4.3.0.M3 > > Original Estimate: 2 days > Remaining Estimate: 2 days > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 19 09:40:32 2014 From: issues at jboss.org (Patrick Schmidt (JIRA)) Date: Sat, 19 Jul 2014 09:40:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-8125) Tables: built-in sorting/filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986465#comment-12986465 ] Patrick Schmidt commented on RF-8125: ------------------------------------- METZLER Clerk ----------------------------------------------------------------------- Patrick Schmidt Ich bin abwesend und ausschlie?lich freitag vormittags im Haus und werde Ihre E-Mail dann bearbeiten. In dringenden F?llen wenden Sie sich bitte an Martin Winzer (mwinzer at metzler.com). > Tables: built-in sorting/filtering > ---------------------------------- > > Key: RF-8125 > URL: https://issues.jboss.org/browse/RF-8125 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.0.0.Final > Reporter: Anton Belevich > Assignee: Brian Leathem > Fix For: 4.3.0.M3 > > Original Estimate: 2 days > Remaining Estimate: 2 days > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 19 09:44:29 2014 From: issues at jboss.org (Edward I (JIRA)) Date: Sat, 19 Jul 2014 09:44:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13733) dataTable built-in sorting In-Reply-To: References: Message-ID: Edward I created RF-13733: ----------------------------- Summary: dataTable built-in sorting Key: RF-13733 URL: https://issues.jboss.org/browse/RF-13733 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: component-tables Affects Versions: 4.3.7 Reporter: Edward I dataTable built-in sorting is still not implemented - only implemented in extendedDataTable so far. Is this still being planned? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 02:58:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 02:58:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13725. ---------------------------- Verified. Closing. > Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration > ------------------------------------------------------------------------ > > Key: RF-13725 > URL: https://issues.jboss.org/browse/RF-13725 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown: > {code} > SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener > java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor > at org.jboss.weld.logging.WeldMessageConveyor.(WeldMessageConveyor.java:61) > at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27) > at org.jboss.weld.logging.LoggerFactory.(LoggerFactory.java:37) > at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51) > at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36) > at org.jboss.weld.environment.servlet.Listener.(Listener.java:70) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 03:02:29 2014 From: issues at jboss.org (=?UTF-8?Q?Juraj_H=C3=BAska_=28JIRA=29?=) Date: Mon, 21 Jul 2014 03:02:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juraj H?ska closed RF-13724. ---------------------------- Verified. Closing. > Showcase - leftovers of old Editor skinning setup cause 404 error > ----------------------------------------------------------------- > > Key: RF-13724 > URL: https://issues.jboss.org/browse/RF-13724 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: showcase > Affects Versions: 4.5.0.Alpha3 > Reporter: Juraj H?ska > Assignee: Juraj H?ska > Priority: Trivial > Fix For: 4.5.0.Beta1 > > > In the example for editor advanced configuration, there is leftover of old skinning setup: > {code:xml} > > > > > > > > {code} > This causes 404 HTTP errors, while those skins can not be found in the resources. > Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 07:37:32 2014 From: issues at jboss.org (John Kiro (JIRA)) Date: Mon, 21 Jul 2014 07:37:32 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-12448) Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-12448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986609#comment-12986609 ] John Kiro commented on RF-12448: -------------------------------- Thanks Brian for your feedback. Will check the instructions for pull requests, and hopefully will submit a fix. > Calendar: April 2011 is missing when timezone is set to +2 Asia/Amman (EEST) > ---------------------------------------------------------------------------- > > Key: RF-12448 > URL: https://issues.jboss.org/browse/RF-12448 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input, localization > Environment: RichFaces 4.3.0.M1 > JBoss AS 7.1.1.Final > Google Chrome 21.0.1180.89 > Reporter: Pavol Pitonak > Fix For: 4.5-Tracking > > Attachments: calendar.png > > > # deploy Showcase and open http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=calendar&skin=blueSky > # click on input to open calendar's popup > # navigate to April 2011 > result: > * there is no April 2011 > * March 2011 is gray and contains only 1s (see screenshot) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:39:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Mon, 21 Jul 2014 10:39:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13723) fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986695#comment-12986695 ] Michal Petrov commented on RF-13723: ------------------------------------ Clicking on an element should produce {{mousedown}}, {{mouseup}} and {{click}} events but in this case the click event never fires. I can't tell why it is happening, running a profiler produces the same results up until the mouseup event. > fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE > --------------------------------------------------------------------------------- > > Key: RF-13723 > URL: https://issues.jboss.org/browse/RF-13723 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.5.0.Alpha3 > Environment: IE 11, IE 10 > Reporter: Ji?? ?tefek > Priority: Minor > Labels: IE10, IE11 > Fix For: 4.5.0.Beta1 > > > The 'Clear All' button does nothing when clicked after maxFilesQuantity reached by adding items using the 'Add' button. It works after items were added by DnD. > You have to click somewhere on the page, to get the button working. > It works fine in FF, Chrome. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 11:59:31 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Mon, 21 Jul 2014 11:59:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13686) Props interfaces overlap and are not fully implemented In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986755#comment-12986755 ] Michal Petrov commented on RF-13686: ------------------------------------ I've noticed AbstractAutocomplete still references the xml files and even though they are not part of the project they still seem to be used by CDK somehow. (AbstractAutocomplete defines getTabIndex but the @Attribute annotation is missing and yet the generated UIAutocomplete has a getTabindex method). > Props interfaces overlap and are not fully implemented > ------------------------------------------------------ > > Key: RF-13686 > URL: https://issues.jboss.org/browse/RF-13686 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > In addition to RF-13679 - @styleClass is also defined in CoreProps which many classes implement and in several classes it is hardcoded (like AbstractAutocomplete), several other interfaces are not being implemented. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 12:05:31 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Mon, 21 Jul 2014 12:05:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13686) Props interfaces overlap and are not fully implemented In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986758#comment-12986758 ] Brian Leathem commented on RF-13686: ------------------------------------ Most of the xml attribute files were defined in the CDK rather than in the framework and are still present: https://github.com/richfaces/richfaces-cdk/tree/master/attributes/src/main/resources/META-INF/cdk/attributes If any components continue to reference them, they should be updated to use interfaces as well. > Props interfaces overlap and are not fully implemented > ------------------------------------------------------ > > Key: RF-13686 > URL: https://issues.jboss.org/browse/RF-13686 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > In addition to RF-13679 - @styleClass is also defined in CoreProps which many classes implement and in several classes it is hardcoded (like AbstractAutocomplete), several other interfaces are not being implemented. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 03:51:30 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Tue, 22 Jul 2014 03:51:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13525) Remove GAE sample from Archetypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13525. -------------------------------- Assignee: Michal Petrov Resolution: Done > Remove GAE sample from Archetypes > --------------------------------- > > Key: RF-13525 > URL: https://issues.jboss.org/browse/RF-13525 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 5.0.0.Alpha3 > Reporter: Luk?? Fry? > Assignee: Michal Petrov > Fix For: 4.5.0.Beta1 > > > I suggest to remove GAE archetype since it is unmaintained. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 10:45:38 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 22 Jul 2014 10:45:38 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-11453) Add autocomplete functionality to the rich:select component In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem updated RF-11453: ------------------------------- Fix Version/s: 4.5.0.Beta1 (was: 4.5-Tracking) > Add autocomplete functionality to the rich:select component > ----------------------------------------------------------- > > Key: RF-11453 > URL: https://issues.jboss.org/browse/RF-11453 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-selects > Reporter: Cody Lerum > Fix For: 4.5.0.Beta1 > > > Add an "autocompleteMethod" to rich:select -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 10:55:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 22 Jul 2014 10:55:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-10970) UIAutocomplete should work with object, such as o p:autocomplete the primefaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987113#comment-12987113 ] Brian Leathem commented on RF-10970: ------------------------------------ This issue is duplicated bty RF-11332 which was rendered obsolete by RF-13690. > UIAutocomplete should work with object, such as o p:autocomplete the primefaces > ------------------------------------------------------------------------------- > > Key: RF-10970 > URL: https://issues.jboss.org/browse/RF-10970 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.0.0.Final > Reporter: Wanderlei Magri > Labels: AutoComplete > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > I think it UIAutocomplete should work with object, such as o p:autocomplete the primefaces.Working directly with objects, for example you pass a list of objects to autocomplete it and the return value is an object, being able to use the convert. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 10:55:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 22 Jul 2014 10:55:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-10970) UIAutocomplete should work with object, such as o p:autocomplete the primefaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-10970. -------------------------------- Fix Version/s: (was: 5-Future) Resolution: Duplicate Issue > UIAutocomplete should work with object, such as o p:autocomplete the primefaces > ------------------------------------------------------------------------------- > > Key: RF-10970 > URL: https://issues.jboss.org/browse/RF-10970 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.0.0.Final > Reporter: Wanderlei Magri > Labels: AutoComplete > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > I think it UIAutocomplete should work with object, such as o p:autocomplete the primefaces.Working directly with objects, for example you pass a list of objects to autocomplete it and the return value is an object, being able to use the convert. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 12:25:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 22 Jul 2014 12:25:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13734) Migrate the sandbox to build with RichFaces 4.5.x In-Reply-To: References: Message-ID: Brian Leathem created RF-13734: ---------------------------------- Summary: Migrate the sandbox to build with RichFaces 4.5.x Key: RF-13734 URL: https://issues.jboss.org/browse/RF-13734 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: examples Reporter: Brian Leathem Fix For: 4.5.0.Beta1 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 12:27:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Tue, 22 Jul 2014 12:27:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13734) Migrate the sandbox to build with RichFaces 4.5.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987161#comment-12987161 ] Brian Leathem commented on RF-13734: ------------------------------------ The current status of building against 5.x should be preserved in a {{5.x}} branch. > Migrate the sandbox to build with RichFaces 4.5.x > ------------------------------------------------- > > Key: RF-13734 > URL: https://issues.jboss.org/browse/RF-13734 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: examples > Reporter: Brian Leathem > Fix For: 4.5.0.Beta1 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 13:41:29 2014 From: issues at jboss.org (Horst Scheruga (JIRA)) Date: Tue, 22 Jul 2014 13:41:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13735) @NotBlank message overridden by @NotNull message during CSV In-Reply-To: References: Message-ID: Horst Scheruga created RF-13735: ----------------------------------- Summary: @NotBlank message overridden by @NotNull message during CSV Key: RF-13735 URL: https://issues.jboss.org/browse/RF-13735 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component Affects Versions: 4.3.7 Environment: Windows 7 Tomcat 8.0.5 Reporter: Horst Scheruga Priority: Minor I use Bean Validation and set the following anotation @NotNull(message = "my message") During Client Side Validation this message is only shown if the value is not null and empty (e.g. " ") if it is null, the default null message comes up instead! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 13:43:31 2014 From: issues at jboss.org (Horst Scheruga (JIRA)) Date: Tue, 22 Jul 2014 13:43:31 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13736) Make button text searchable by browsers In-Reply-To: References: Message-ID: Horst Scheruga created RF-13736: ----------------------------------- Summary: Make button text searchable by browsers Key: RF-13736 URL: https://issues.jboss.org/browse/RF-13736 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Horst Scheruga Priority: Minor As a user I hate it, when I do not find buttons by using browsers "find" utility. The text on all richfaces button is not found in this way. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 22 16:33:30 2014 From: issues at jboss.org (Torben Greiser (JIRA)) Date: Tue, 22 Jul 2014 16:33:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13735) @NotBlank message overridden by @NotNull message during CSV In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987233#comment-12987233 ] Torben Greiser commented on RF-13735: ------------------------------------- Have you set {code} javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL true {code} in your {{web.xml}}? > @NotBlank message overridden by @NotNull message during CSV > ----------------------------------------------------------- > > Key: RF-13735 > URL: https://issues.jboss.org/browse/RF-13735 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 4.3.7 > Environment: Windows 7 > Tomcat 8.0.5 > Reporter: Horst Scheruga > Priority: Minor > > I use Bean Validation and set the following anotation > @NotNull(message = "my message") > During Client Side Validation this message is only shown if the value is not null and empty (e.g. " ") if it is null, the default null message comes up instead! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 06:39:29 2014 From: issues at jboss.org (Marek Novotny (JIRA)) Date: Wed, 23 Jul 2014 06:39:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13737) update readme in distribution how to use renamed Richfaces maven artifacts In-Reply-To: References: Message-ID: Marek Novotny created RF-13737: ---------------------------------- Summary: update readme in distribution how to use renamed Richfaces maven artifacts Key: RF-13737 URL: https://issues.jboss.org/browse/RF-13737 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.5.0.Alpha3 Reporter: Marek Novotny readme.txt states: 2. Using Maven To setup your project using Maven, follow the instruction on the wiki at http://community.jboss.org/wiki/HowtoaddRichFaces4xtomavenbasedproject ^^ the above URL is outdated for new 4.5.0.Alpha3 artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 07:13:30 2014 From: issues at jboss.org (Marek Novotny (JIRA)) Date: Wed, 23 Jul 2014 07:13:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13738) Richfaces BOM 4.5.0.Alpha3 is not uploaded in maven repository In-Reply-To: References: Message-ID: Marek Novotny created RF-13738: ---------------------------------- Summary: Richfaces BOM 4.5.0.Alpha3 is not uploaded in maven repository Key: RF-13738 URL: https://issues.jboss.org/browse/RF-13738 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Marek Novotny Richfaces bom is not available in jboss.org maven repository, even it is tagged in github repo https://github.com/richfaces/richfaces/blob/4.5.0.Alpha3/bom/pom.xml https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.richfaces~richfaces-bom~4.5.0.Alpha3~~ -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 11:49:29 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 23 Jul 2014 11:49:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13738) Richfaces BOM 4.5.0.Alpha3 is not uploaded in maven repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13738. -------------------------------- Resolution: Rejected The BOM was renamed to {{richfaces-cache-bom}} since it now only manages the cache dependencies (see RF-13626). The required framework dependencies are managed transitively, and a depchain was created to manage the push dependencies ({{richfaces-push-depchain}}). This is poorly documented with the 4.5.0.Alpha3 release, we'll correct this with the 4.5.0.Beta1 release. > Richfaces BOM 4.5.0.Alpha3 is not uploaded in maven repository > -------------------------------------------------------------- > > Key: RF-13738 > URL: https://issues.jboss.org/browse/RF-13738 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marek Novotny > > Richfaces bom is not available in jboss.org maven repository, even it is tagged in github repo https://github.com/richfaces/richfaces/blob/4.5.0.Alpha3/bom/pom.xml > https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.richfaces~richfaces-bom~4.5.0.Alpha3~~ -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 11:55:30 2014 From: issues at jboss.org (Brian Leathem (JIRA)) Date: Wed, 23 Jul 2014 11:55:30 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13737) update readme in distribution how to use renamed Richfaces maven artifacts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Leathem resolved RF-13737. -------------------------------- Resolution: Duplicate Issue Updating the wiki pages is being tracked by RFPL-3415 > update readme in distribution how to use renamed Richfaces maven artifacts > -------------------------------------------------------------------------- > > Key: RF-13737 > URL: https://issues.jboss.org/browse/RF-13737 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.5.0.Alpha3 > Reporter: Marek Novotny > > readme.txt states: > 2. Using Maven > To setup your project using Maven, follow the instruction on the wiki at > http://community.jboss.org/wiki/HowtoaddRichFaces4xtomavenbasedproject > ^^ the above URL is outdated for new 4.5.0.Alpha3 artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 12:33:29 2014 From: issues at jboss.org (Michal Petrov (JIRA)) Date: Wed, 23 Jul 2014 12:33:29 -0400 (EDT) Subject: [richfaces-issues] [JBoss JIRA] (RF-13736) Make button text searchable by browsers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RF-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Petrov resolved RF-13736. -------------------------------- Resolution: Rejected This is a browser/HTML thing. It only searches through text nodes and buttons don't create a text node (with the exception of the {{