[JBoss JIRA] (RF-13042) Render h:commandlink: keeps reloading js
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13042?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13042:
-------------------------------
Sprint: (was: 5.0.0.Alpha2 - Sprint 3)
> Render h:commandlink: keeps reloading js
> ----------------------------------------
>
> Key: RF-13042
> URL: https://issues.jboss.org/browse/RF-13042
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.3.Final, 4.3.2
> Reporter: Nicolas Daniels
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Javascript resource is reloaded at each render, and so javascript was becoming heavier and heavier to run (to end by a not responsive alter on FF -or even FF hangs forever).
>
> After more investigation, I noticed it is due to the h:commandlink tag which was inside my rerendered part.
> Workaround:
> Add:
> {code:xml}
> <h:inputText rendered="false">
> <f:ajax />
> </h:inputText>
> {code}
> in your page, Js is not reloading anymore. (I inserted it at the end but I guess it works anywhere)
> See forum link for more details.
--
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
12 years, 5 months
[JBoss JIRA] (RF-13127) onvalid and oninvalide pass wrong element when using rich:element with String field
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13127?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13127:
-------------------------------
Sprint: (was: 5.0.0.Alpha2 - Sprint 3)
> onvalid and oninvalide pass wrong element when using rich:element with String field
> -----------------------------------------------------------------------------------
>
> Key: RF-13127
> URL: https://issues.jboss.org/browse/RF-13127
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.3
> Reporter: Louis Parisi
> Labels: testcase_provided
> Fix For: 5.0.0.Alpha2
>
> Attachments: JSFTemplate.zip, RF-13127.zip, richfaces.zip
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but intermittently returns the element from row zero and sometimes another rown when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field.
> {code}
> <h:inputText id="vendor" value="#{car.vendor}" valueChangeListener="#{car.valueChanged}">
> <rich:validator oninvalid="valueModified(#{rich:element('vendor')}, false)"
> onvalid="valueModified(#{rich:element('vendor')}, true)"/>
> </h:inputText>
> {code}
> {code}
> <script>
> function valueModified(element, valid) {
> // use element.style rather than jQuery as it
> // does not set entire background
> alert("valueModified: " + element.id + " | valid: " + valid);
> element.style.background='yellow';
> if (valid) {
> jQuery(element).css("border-color", "lightgray");
> } else {
> jQuery(element).css("border-color", "red");
> }
> }
> </script>
> {code}
> Some other tests I did while trying to debug are:
> * I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field.
> * The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field.
--
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
12 years, 5 months
[JBoss JIRA] (RF-11000) Hit miss for class loader cost performance problem in Richfaces 4.1.0.
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11000?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11000:
-------------------------------
Fix Version/s: 5.0.0.Alpha3
(was: 5.0.0.Alpha2)
> Hit miss for class loader cost performance problem in Richfaces 4.1.0.
> ----------------------------------------------------------------------
>
> Key: RF-11000
> URL: https://issues.jboss.org/browse/RF-11000
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.Milestone1
> Environment: Linux, Java 6
> Reporter: Pawel J.
> Assignee: Brian Leathem
> Labels: patch_proposed
> Fix For: 5.0.0.Alpha3
>
> Attachments: ResourceFactoryImpl-patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> There are scenarios when resources are retrieved during no partial
> request processing:
> # JSF html renderer (such as ScriptRenderer from faces) require to
> know resources names to include them to html/head,
> # Resources content request.
> We have two types of resources: dynamic and static. Predefined dynamic
> resources (such as StateHolderResource) are read using class loader as
> they are java classes. Static resources are kept in resources folder
> as part of richfaces release jars (jquery.js, richfaces.js, etc).
> There is a special case with compiled css that is consider as dynamic
> resources but is not important in our case.
> The problem appears when we try to load static resources using dynamic
> loader. This make unnecessary lookup in java class loader space which
> cost time and of course we miss the call as static resources not
> exists there.
> Statistics that shows class loader hits for every richfaces/ajax4jsf no partial request that will be eliminated after patch:
> {code}
> Resource::jquery.js ::loading::timens:: 558000 ns::timems::0.558 ms::all::1.561496 sec
> Resource::richfaces.js ::loading::timens:: 490000 ns::timems::0.490 ms::all::1.561986 sec
> Resource::richfaces-base-component.js::loading::timens:: 593000 ns::timems::0.593 ms::all::1.563672 sec
> Resource::richfaces-queue.js ::loading::timens:: 672000 ns::timems::0.672 ms::all::1.564350 sec
> Resource::richfaces-event.js ::loading::timens::3292000 ns::timems::3.292 ms::all::1.569386 sec
> {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
12 years, 5 months
[JBoss JIRA] (RF-11000) Hit miss for class loader cost performance problem in Richfaces 4.1.0.
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11000?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11000:
-------------------------------
Sprint: (was: 5.0.0.Alpha2 - Sprint 3)
> Hit miss for class loader cost performance problem in Richfaces 4.1.0.
> ----------------------------------------------------------------------
>
> Key: RF-11000
> URL: https://issues.jboss.org/browse/RF-11000
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.Milestone1
> Environment: Linux, Java 6
> Reporter: Pawel J.
> Assignee: Brian Leathem
> Labels: patch_proposed
> Fix For: 5.0.0.Alpha2
>
> Attachments: ResourceFactoryImpl-patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> There are scenarios when resources are retrieved during no partial
> request processing:
> # JSF html renderer (such as ScriptRenderer from faces) require to
> know resources names to include them to html/head,
> # Resources content request.
> We have two types of resources: dynamic and static. Predefined dynamic
> resources (such as StateHolderResource) are read using class loader as
> they are java classes. Static resources are kept in resources folder
> as part of richfaces release jars (jquery.js, richfaces.js, etc).
> There is a special case with compiled css that is consider as dynamic
> resources but is not important in our case.
> The problem appears when we try to load static resources using dynamic
> loader. This make unnecessary lookup in java class loader space which
> cost time and of course we miss the call as static resources not
> exists there.
> Statistics that shows class loader hits for every richfaces/ajax4jsf no partial request that will be eliminated after patch:
> {code}
> Resource::jquery.js ::loading::timens:: 558000 ns::timems::0.558 ms::all::1.561496 sec
> Resource::richfaces.js ::loading::timens:: 490000 ns::timems::0.490 ms::all::1.561986 sec
> Resource::richfaces-base-component.js::loading::timens:: 593000 ns::timems::0.593 ms::all::1.563672 sec
> Resource::richfaces-queue.js ::loading::timens:: 672000 ns::timems::0.672 ms::all::1.564350 sec
> Resource::richfaces-event.js ::loading::timens::3292000 ns::timems::3.292 ms::all::1.569386 sec
> {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
12 years, 5 months
[JBoss JIRA] (RF-12899) Deadlock appears in push component
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12899?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12899:
-------------------------------
Sprint: (was: 5.0.0.Alpha2 - Sprint 3)
> Deadlock appears in push component
> ----------------------------------
>
> Key: RF-12899
> URL: https://issues.jboss.org/browse/RF-12899
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.2.2.Final
> Reporter: Jiří Mikulášek
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Our application freezes occasionally. We used Jstack and have seen the deadlock below. It seems to be very simillar to RF-12013, but the stack is slightly different
> Found one Java-level deadlock:
> =============================
> {code}
> "localhost-startStop-2":
> waiting to lock monitor 0x000000000782a368 (object 0x000000078da957e0, a org.richfaces.application.push.impl.SessionImpl),
> which is held by "http-nio-30085-exec-4"
> "http-nio-30085-exec-4":
> waiting to lock monitor 0x00000000085cbe00 (object 0x000000078e8ecf90, a org.atmosphere.cpr.AtmosphereResourceImpl),
> which is held by "Atmosphere-AsyncWrite-0"
> "Atmosphere-AsyncWrite-0":
> waiting to lock monitor 0x000000000782a368 (object 0x000000078da957e0, a org.richfaces.application.push.impl.SessionImpl),
> which is held by "http-nio-30085-exec-4"
> {code}
> Java stack information for the threads listed above:
> ===================================================
> {code}
> "localhost-startStop-2":
> at org.richfaces.application.push.impl.SessionImpl.disconnect(SessionImpl.java:117)
> - waiting to lock <0x000000078da957e0> (a org.richfaces.application.push.impl.SessionImpl)
> at org.richfaces.application.push.impl.RequestImpl.disconnect(RequestImpl.java:128)
> at org.richfaces.application.push.impl.RequestImpl.onResume(RequestImpl.java:136)
> at org.atmosphere.cpr.AtmosphereResourceImpl.onResume(AtmosphereResourceImpl.java:658)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:607)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:591)
> at org.atmosphere.cpr.AtmosphereResourceImpl.resume(AtmosphereResourceImpl.java:187)
> - locked <0x000000078e8b64a8> (a org.atmosphere.cpr.AtmosphereResourceImpl)
> at org.atmosphere.cpr.DefaultBroadcaster.resumeAll(DefaultBroadcaster.java:300)
> - locked <0x000000078e8d1ac8> (a java.util.concurrent.ConcurrentLinkedQueue)
> at org.atmosphere.cpr.DefaultBroadcasterFactory.destroy(DefaultBroadcasterFactory.java:274)
> - locked <0x000000078cb112d8> (a org.atmosphere.cpr.DefaultBroadcasterFactory)
> at org.atmosphere.cpr.AtmosphereServlet.destroy(AtmosphereServlet.java:867)
> at org.atmosphere.cpr.MeteorServlet.destroy(MeteorServlet.java:88)
> at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1481)
> - locked <0x0000000784b6a168> (a org.apache.catalina.core.StandardWrapper)
> at org.apache.catalina.core.StandardWrapper.stopInternal(StandardWrapper.java:1842)
> - locked <0x0000000784b6a168> (a org.apache.catalina.core.StandardWrapper)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> - locked <0x0000000784b6a168> (a org.apache.catalina.core.StandardWrapper)
> at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5471)
> - locked <0x000000078312e828> (a org.apache.catalina.core.StandardContext)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
> - locked <0x000000078312e828> (a org.apache.catalina.core.StandardContext)
> at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)
> at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> "http-nio-30085-exec-4":
> at org.atmosphere.cpr.AtmosphereResourceImpl.resume(AtmosphereResourceImpl.java:168)
> - waiting to lock <0x000000078e8ecf90> (a org.atmosphere.cpr.AtmosphereResourceImpl)
> at org.atmosphere.cpr.Meteor.resume(Meteor.java:240)
> at org.richfaces.application.push.impl.RequestImpl.resume(RequestImpl.java:71)
> at org.richfaces.application.push.impl.SessionImpl.releaseRequest(SessionImpl.java:112)
> at org.richfaces.application.push.impl.SessionImpl.connect(SessionImpl.java:85)
> - locked <0x000000078da957e0> (a org.richfaces.application.push.impl.SessionImpl)
> at org.richfaces.application.push.impl.RequestImpl.onSuspend(RequestImpl.java:119)
> at org.atmosphere.cpr.AtmosphereResourceImpl.onSuspend(AtmosphereResourceImpl.java:652)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:611)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:591)
> at org.atmosphere.cpr.AtmosphereResourceImpl.suspend(AtmosphereResourceImpl.java:347)
> at org.atmosphere.cpr.Meteor.suspend(Meteor.java:213)
> at org.richfaces.application.push.impl.RequestImpl.suspend(RequestImpl.java:67)
> at org.richfaces.webapp.PushHandlerFilter.doFilter(PushHandlerFilter.java:107)
> at org.atmosphere.util.AtmosphereFilterChain.doFilter(AtmosphereFilterChain.java:139)
> at org.atmosphere.util.AtmosphereFilterChain.invokeFilterChain(AtmosphereFilterChain.java:116)
> at org.atmosphere.handler.ReflectorServletProcessor$FilterChainServletWrapper.service(ReflectorServletProcessor.java:293)
> at org.atmosphere.handler.ReflectorServletProcessor.onRequest(ReflectorServletProcessor.java:151)
> at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:219)
> at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:154)
> at org.atmosphere.container.Tomcat7CometSupport.service(Tomcat7CometSupport.java:85)
> at org.atmosphere.cpr.AtmosphereServlet.doCometSupport(AtmosphereServlet.java:1218)
> at org.atmosphere.cpr.AtmosphereServlet.event(AtmosphereServlet.java:1286)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:484)
> at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:377)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1686)
> - locked <0x000000078e7fcc28> (a org.apache.tomcat.util.net.NioChannel)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> "Atmosphere-AsyncWrite-0":
> at org.richfaces.application.push.impl.SessionImpl.disconnect(SessionImpl.java:117)
> - waiting to lock <0x000000078da957e0> (a org.richfaces.application.push.impl.SessionImpl)
> at org.richfaces.application.push.impl.RequestImpl.disconnect(RequestImpl.java:128)
> at org.richfaces.application.push.impl.RequestImpl.onDisconnect(RequestImpl.java:140)
> at org.atmosphere.cpr.AtmosphereResourceImpl.onDisconnect(AtmosphereResourceImpl.java:664)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:609)
> at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:591)
> at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:719)
> at org.atmosphere.cpr.DefaultBroadcaster$3.run(DefaultBroadcaster.java:749)
> - locked <0x000000078e8ecf90> (a org.atmosphere.cpr.AtmosphereResourceImpl)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Found 1 deadlock.
--
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
12 years, 5 months