[JBoss JIRA] (RF-13611) RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13611?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13611:
-------------------------------
Fix Version/s: 4.3.7
> RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
> ---------------------------------------------------------
>
> Key: RF-13611
> URL: https://issues.jboss.org/browse/RF-13611
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Fix For: 4.3.7
>
>
> I'm using WildFly 8.0.0.CR1 and Weld 2.2.0.Final (via the WildFly patch mechanism). However, I'm getting the stacktrace below. When I patch WildFly 8.0.0.CR1 with the predecessor version Weld 2.2.0.CR2, then the issue is gone.
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.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: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: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DefinitionException: WELD-000412: ObserverMethod.getReception() returned null for org.richfaces.push.cdi.PushCDIExtension$PushObserverMethod@31e23242
> at org.jboss.weld.util.Observers.validateObserverMethod(Observers.java:118)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.addObserverMethod(AfterBeanDiscoveryImpl.java:158)
> at org.richfaces.push.cdi.PushCDIExtension.afterBeanDiscovery(PushCDIExtension.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
> at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
> at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
> at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> 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:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> 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}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13607) Tables/Menus logged warnings for invalid children
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13607?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13607:
------------------------------------
Please provide an example of sample code that you would expect to throw an error.
> Tables/Menus logged warnings for invalid children
> -------------------------------------------------
>
> Key: RF-13607
> URL: https://issues.jboss.org/browse/RF-13607
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-menu, component-tables
> Affects Versions: 4.3.4
> Environment: JBoss EAP 6.1.1
> Reporter: Michael Colin
>
> Whenever you put an invalid child into a component like the rich:extendedDataTable I would expect to get an exception or a warning at the very least. Currently the component just seems to ignore those false children which makes debugging difficult (when trying to create a composite component of rich:column, for example) and might lead to false code to just stay where it is because it doesn't generate an error and is simply "forgotten".
> Wrong code should generate harsh exceptions so it shows and can be fixed in a timely manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13606) WebSphere/MyFaces in 4.3.6
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13606?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13606.
--------------------------------
Resolution: Incomplete Description
Sorry, but a stacktrace on it's own does not constitute an issue report.
Feel free to re-open the issue with a sample application attached that deploys fine in other containers, but fails in your preferred container.
> WebSphere/MyFaces in 4.3.6
> --------------------------
>
> Key: RF-13606
> URL: https://issues.jboss.org/browse/RF-13606
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.6
> Environment: WebSphere AS 8.0.0.8
> Reporter: Konstantin Morozov
>
> Application started successfully, but throws exception when launched:
> {code}
> org.richfaces.resource.external.MyFacesExternalResourceTracker handleException error while delegating resource handling to myfaces impl
> java.lang.NoSuchMethodException: org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.isRenderedStylesheet(javax.faces.context.FacesContext, java.lang.String, java.lang.String)
> at java.lang.Class.throwNoSuchMethodException(Class.java:325)
> at java.lang.Class.getMethod(Class.java:939)
> at org.richfaces.resource.external.MyFacesExternalResourceTracker.<init>(MyFacesExternalResourceTracker.java:52)
> at org.richfaces.resource.external.ExternalResourceTrackerWrapper.getWrapped(ExternalResourceTrackerWrapper.java:94)
> at org.richfaces.resource.external.ExternalResourceTrackerWrapper.markExternalResourceRendered(ExternalResourceTrackerWrapper.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.richfaces.application.ServiceTracker$1.invoke(ServiceTracker.java:153)
> at com.sun.proxy.$Proxy284.markExternalResourceRendered(Unknown Source)
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:358)
> at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:270)
> at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:280)
> at com.sun.faces.renderkit.html_basic.StylesheetRenderer.encodeEnd(StylesheetRenderer.java:97)
> at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
> at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeHeadResources(HeadRenderer.java:105)
> at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeEnd(HeadRenderer.java:92)
> at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
> at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
> at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
> at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3774)
> at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
> at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:981)
> at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
> at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
> at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
> at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
> at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13605) a4j:ajax button click event gets lost
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13605?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13605:
------------------------------------
Indeed, as [~michpetrov] pointed out the problem here is one of competing nearly-simultaneous ajax requests.
The user should consider which even should trigger the ajax update, and should consider moving the ajax _change_ listener on the input text into a _valueChangeListener_ property of the inputText. This way the change listener would get executed when the ajax update initiated by the button was processed.
See:
https://javaserverfaces.java.net/nonav/docs/2.1/vdldocs/facelets/h/inputT...
> a4j:ajax button click event gets lost
> -------------------------------------
>
> Key: RF-13605
> URL: https://issues.jboss.org/browse/RF-13605
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.6
> Reporter: abhishek vijra
> Attachments: queue.zip
>
>
> Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
> Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
> {code}
> <h:panelGroup id="greeting">
> <h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
> </h:panelGroup>
> <!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
> <h:form>
> <h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
> <h:outputLabel value="Name:" for="nameInput" />
> <h:inputText id="nameInput" value="#{richBean.name}">
> <a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
> </h:inputText>
> <f:facet name="footer">
> <h:panelGroup style="display:block; text-align:right">
> <a4j:commandButton id="submit" value="Submit" render="greeting" />
> </h:panelGroup>
> </f:facet>
> </h:panelGrid>
> </h:form>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13606) WebSphere/MyFaces in 4.3.6
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13606?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13606:
-------------------------------
Description:
Application started successfully, but throws exception when launched:
{code}
org.richfaces.resource.external.MyFacesExternalResourceTracker handleException error while delegating resource handling to myfaces impl
java.lang.NoSuchMethodException: org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.isRenderedStylesheet(javax.faces.context.FacesContext, java.lang.String, java.lang.String)
at java.lang.Class.throwNoSuchMethodException(Class.java:325)
at java.lang.Class.getMethod(Class.java:939)
at org.richfaces.resource.external.MyFacesExternalResourceTracker.<init>(MyFacesExternalResourceTracker.java:52)
at org.richfaces.resource.external.ExternalResourceTrackerWrapper.getWrapped(ExternalResourceTrackerWrapper.java:94)
at org.richfaces.resource.external.ExternalResourceTrackerWrapper.markExternalResourceRendered(ExternalResourceTrackerWrapper.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.richfaces.application.ServiceTracker$1.invoke(ServiceTracker.java:153)
at com.sun.proxy.$Proxy284.markExternalResourceRendered(Unknown Source)
at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:358)
at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:270)
at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:280)
at com.sun.faces.renderkit.html_basic.StylesheetRenderer.encodeEnd(StylesheetRenderer.java:97)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeHeadResources(HeadRenderer.java:105)
at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeEnd(HeadRenderer.java:92)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3774)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:981)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702)
{code}
was:
Application started successfully, but throws exception when launched:
org.richfaces.resource.external.MyFacesExternalResourceTracker handleException error while delegating resource handling to myfaces impl
java.lang.NoSuchMethodException: org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.isRenderedStylesheet(javax.faces.context.FacesContext, java.lang.String, java.lang.String)
at java.lang.Class.throwNoSuchMethodException(Class.java:325)
at java.lang.Class.getMethod(Class.java:939)
at org.richfaces.resource.external.MyFacesExternalResourceTracker.<init>(MyFacesExternalResourceTracker.java:52)
at org.richfaces.resource.external.ExternalResourceTrackerWrapper.getWrapped(ExternalResourceTrackerWrapper.java:94)
at org.richfaces.resource.external.ExternalResourceTrackerWrapper.markExternalResourceRendered(ExternalResourceTrackerWrapper.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.richfaces.application.ServiceTracker$1.invoke(ServiceTracker.java:153)
at com.sun.proxy.$Proxy284.markExternalResourceRendered(Unknown Source)
at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:358)
at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:270)
at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:280)
at com.sun.faces.renderkit.html_basic.StylesheetRenderer.encodeEnd(StylesheetRenderer.java:97)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeHeadResources(HeadRenderer.java:105)
at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeEnd(HeadRenderer.java:92)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3774)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:981)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702)
> WebSphere/MyFaces in 4.3.6
> --------------------------
>
> Key: RF-13606
> URL: https://issues.jboss.org/browse/RF-13606
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.6
> Environment: WebSphere AS 8.0.0.8
> Reporter: Konstantin Morozov
>
> Application started successfully, but throws exception when launched:
> {code}
> org.richfaces.resource.external.MyFacesExternalResourceTracker handleException error while delegating resource handling to myfaces impl
> java.lang.NoSuchMethodException: org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtils.isRenderedStylesheet(javax.faces.context.FacesContext, java.lang.String, java.lang.String)
> at java.lang.Class.throwNoSuchMethodException(Class.java:325)
> at java.lang.Class.getMethod(Class.java:939)
> at org.richfaces.resource.external.MyFacesExternalResourceTracker.<init>(MyFacesExternalResourceTracker.java:52)
> at org.richfaces.resource.external.ExternalResourceTrackerWrapper.getWrapped(ExternalResourceTrackerWrapper.java:94)
> at org.richfaces.resource.external.ExternalResourceTrackerWrapper.markExternalResourceRendered(ExternalResourceTrackerWrapper.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.richfaces.application.ServiceTracker$1.invoke(ServiceTracker.java:153)
> at com.sun.proxy.$Proxy284.markExternalResourceRendered(Unknown Source)
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:358)
> at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:270)
> at org.richfaces.resource.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:280)
> at com.sun.faces.renderkit.html_basic.StylesheetRenderer.encodeEnd(StylesheetRenderer.java:97)
> at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
> at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeHeadResources(HeadRenderer.java:105)
> at com.sun.faces.renderkit.html_basic.HeadRenderer.encodeEnd(HeadRenderer.java:92)
> at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:915)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:124)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
> at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
> at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
> at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3774)
> at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
> at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:981)
> at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
> at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
> at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
> at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
> at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13605) a4j:ajax button click event gets lost
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13605?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13605:
-------------------------------
Description:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
{code}
<h:panelGroup id="greeting">
<h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
</h:panelGroup>
<!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
<h:form>
<h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
<h:outputLabel value="Name:" for="nameInput" />
<h:inputText id="nameInput" value="#{richBean.name}">
<a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
</h:inputText>
<f:facet name="footer">
<h:panelGroup style="display:block; text-align:right">
<a4j:commandButton id="submit" value="Submit" render="greeting" />
</h:panelGroup>
</f:facet>
</h:panelGrid>
</h:form>
{code}
was:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
{code}
<h:panelGroup id="greeting">
<h:outputText value="Hello #{richBean.name}!"
rendered="#{not empty richBean.name}" style="font-size:2em" />
</h:panelGroup>
<!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
<h:form>
<h:panelGrid id="panel" columns="2" border="0" cellpadding="0"
cellspacing="10">
<h:outputLabel value="Name:" for="nameInput" />
<h:inputText id="nameInput" value="#{richBean.name}">
<a4j:ajax event="change" listener="#{richBean.normalizeName}"
render="@form" />
</h:inputText>
<f:facet name="footer">
<h:panelGroup style="display:block; text-align:right">
<a4j:commandButton id="submit" value="Submit" render="greeting" />
</h:panelGroup>
</f:facet>
</h:panelGrid>
</h:form>
{code}
> a4j:ajax button click event gets lost
> -------------------------------------
>
> Key: RF-13605
> URL: https://issues.jboss.org/browse/RF-13605
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.6
> Reporter: abhishek vijra
> Attachments: queue.zip
>
>
> Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
> Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
> {code}
> <h:panelGroup id="greeting">
> <h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
> </h:panelGroup>
> <!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
> <h:form>
> <h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
> <h:outputLabel value="Name:" for="nameInput" />
> <h:inputText id="nameInput" value="#{richBean.name}">
> <a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
> </h:inputText>
> <f:facet name="footer">
> <h:panelGroup style="display:block; text-align:right">
> <a4j:commandButton id="submit" value="Submit" render="greeting" />
> </h:panelGroup>
> </f:facet>
> </h:panelGrid>
> </h:form>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13605) a4j:ajax button click event gets lost
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13605?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13605:
-------------------------------
Description:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
{code}
<h:panelGroup id="greeting">
<h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
</h:panelGroup>
<!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
<h:form>
<h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
<h:outputLabel value="Name:" for="nameInput" />
<h:inputText id="nameInput" value="#{richBean.name}">
<a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
</h:inputText>
<f:facet name="footer">
<h:panelGroup style="display:block; text-align:right">
<a4j:commandButton id="submit" value="Submit" render="greeting" />
</h:panelGroup>
</f:facet>
</h:panelGrid>
</h:form>
{code}
was:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
{code}
<h:panelGroup id="greeting">
<h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
</h:panelGroup>
<!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
<h:form>
<h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
<h:outputLabel value="Name:" for="nameInput" />
<h:inputText id="nameInput" value="#{richBean.name}">
<a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
</h:inputText>
<f:facet name="footer">
<h:panelGroup style="display:block; text-align:right">
<a4j:commandButton id="submit" value="Submit" render="greeting" />
</h:panelGroup>
</f:facet>
</h:panelGrid>
</h:form>
{code}
> a4j:ajax button click event gets lost
> -------------------------------------
>
> Key: RF-13605
> URL: https://issues.jboss.org/browse/RF-13605
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.6
> Reporter: abhishek vijra
> Attachments: queue.zip
>
>
> Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
> Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
> {code}
> <h:panelGroup id="greeting">
> <h:outputText value="Hello #{richBean.name}!" rendered="#{not empty richBean.name}" style="font-size:2em" />
> </h:panelGroup>
> <!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
> <h:form>
> <h:panelGrid id="panel" columns="2" border="0" cellpadding="0" cellspacing="10">
> <h:outputLabel value="Name:" for="nameInput" />
> <h:inputText id="nameInput" value="#{richBean.name}">
> <a4j:ajax event="change" listener="#{richBean.normalizeName}" render="@form" />
> </h:inputText>
> <f:facet name="footer">
> <h:panelGroup style="display:block; text-align:right">
> <a4j:commandButton id="submit" value="Submit" render="greeting" />
> </h:panelGroup>
> </f:facet>
> </h:panelGrid>
> </h:form>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13605) a4j:ajax button click event gets lost
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13605?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13605:
-------------------------------
Description:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
{code}
<h:panelGroup id="greeting">
<h:outputText value="Hello #{richBean.name}!"
rendered="#{not empty richBean.name}" style="font-size:2em" />
</h:panelGroup>
<!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
<h:form>
<h:panelGrid id="panel" columns="2" border="0" cellpadding="0"
cellspacing="10">
<h:outputLabel value="Name:" for="nameInput" />
<h:inputText id="nameInput" value="#{richBean.name}">
<a4j:ajax event="change" listener="#{richBean.normalizeName}"
render="@form" />
</h:inputText>
<f:facet name="footer">
<h:panelGroup style="display:block; text-align:right">
<a4j:commandButton id="submit" value="Submit" render="greeting" />
</h:panelGroup>
</f:facet>
</h:panelGrid>
</h:form>
{code}
was:
Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
> a4j:ajax button click event gets lost
> -------------------------------------
>
> Key: RF-13605
> URL: https://issues.jboss.org/browse/RF-13605
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.6
> Reporter: abhishek vijra
> Attachments: queue.zip
>
>
> Clicking on the submit button of a form containing input elements with valuechange event listeners triggers only the execution of the event listeners of the corresponding input elements, but the button click event apparently gets lost and the form isn't actually being submitted. The user has to click on the button again to finally submit it. Explicitly setting the requestDelay of an associated a4j:queue to say 200ms for all events seems to preserve the click event and the form gets submitted as expected in our specific test environment. This isn't a generally acceptable workaround though, as it introduces redundant global delay and hardly preserves the click event reliably across environments with different timing constraints.
> Attached a testcase to isolate the problem, see the attached zip file containing a minimal JSF application with a simple RichFaces-enabled form which reproduces the undesired behavior.
> {code}
> <h:panelGroup id="greeting">
> <h:outputText value="Hello #{richBean.name}!"
> rendered="#{not empty richBean.name}" style="font-size:2em" />
> </h:panelGroup>
> <!-- <a4j:queue name="org.richfaces.queue.global" requestDelay="200" /> -->
> <h:form>
> <h:panelGrid id="panel" columns="2" border="0" cellpadding="0"
> cellspacing="10">
> <h:outputLabel value="Name:" for="nameInput" />
> <h:inputText id="nameInput" value="#{richBean.name}">
> <a4j:ajax event="change" listener="#{richBean.normalizeName}"
> render="@form" />
> </h:inputText>
> <f:facet name="footer">
> <h:panelGroup style="display:block; text-align:right">
> <a4j:commandButton id="submit" value="Submit" render="greeting" />
> </h:panelGroup>
> </f:facet>
> </h:panelGrid>
> </h:form>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months