[JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13731?page=com.atlassian.jira.plugin.s... ]
Cody Lerum commented on RF-13731:
---------------------------------
This looks to be related to RF-13741 and RF-13742
> 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)
9 years, 10 months
[JBoss JIRA] (RF-13731) NPE on Tomcat 7 after Ajax request
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13731?page=com.atlassian.jira.plugin.s... ]
Cody Lerum edited comment on RF-13731 at 7/25/14 3:57 PM:
----------------------------------------------------------
This looks to be related to RF-13741 and RF-13742 which occurs on Wildfly 8.1.0.Final in various ways.
was (Author: clerum):
This looks to be related to RF-13741 and RF-13742
> 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)
9 years, 10 months
[JBoss JIRA] (RF-13742) NPE on Service Side State Saving with Expired View
by Cody Lerum (JIRA)
Cody Lerum created RF-13742:
-------------------------------
Summary: NPE on Service Side State Saving with Expired View
Key: RF-13742
URL: https://issues.jboss.org/browse/RF-13742
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.5.0.Alpha3
Environment: Wildfly 8.1.0.Final
Reporter: Cody Lerum
While testing for the behavior of the application when a view expires I ran into a similar exception as RF-13741
{code}
19:36:42,857 INFO [co.cfly.oss.core.navigation.ExceptionHandlers] (default task-29) Handling FacesException <java.lang.NullPointerException>
19:36:42,858 ERROR [io.undertow.request] (default task-29) UT005023: Exception handling request to /oss/s/i/sales/agent/list.xhtml: javax.servlet.ServletException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [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 org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:205) [rewrite-servlet-2.0.12.Final.jar:2.0.12.Final]
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 co.cfly.oss.web.http.LoggedInFilter.doFilter(LoggedInFilter.java:50) [classes:]
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 com.googlecode.webutilities.filters.CompressionFilter.doFilter(CompressionFilter.java:112) [webutilities-0.0.6.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:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.lang.NullPointerException
at org.richfaces.application.GlobalResourcesViewHandler.addSkinningResourcesToViewRoot(GlobalResourcesViewHandler.java:148) [richfaces-core-4.5.0.Alpha3.jar:4.5.0.Alpha3]
at org.richfaces.application.GlobalResourcesViewHandler.restoreView(GlobalResourcesViewHandler.java:179) [richfaces-core-4.5.0.Alpha3.jar:4.5.0.Alpha3]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:353) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:197) [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.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 org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) [deltaspike-jsf-module-impl-1.0.1.jar:1.0.1]
at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:77) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6]
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13739) Placeholder in collapsibleSubTable template
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13739?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13739:
------------------------------------
Hmm, something's weird with the renderers.
The placeholder element is getting rendered twice: once in its usual space and once just before its parent.
{code}
<span id="form:placeholder">…</span>
<form id="form" name="form" method="post" …>
…
<input type="text" name="input1" id="input1" class="rf-plhdr customPlaceholderClass">
…
<input type="text" name="input3" id="input3" class="rf-plhdr customPlaceholderClass">
<span id="form:placeholder">…</span>
</form>
{code}
RF-12589 introduced a workaround for {{AbstractPlaceholder}} which makes the placeholder render before its parent, but that should only happen if the parent is {{<h:inputText>}} or the like. In the end there should be only one element (works correctly in 4.3.x showcase).
{{PlaceholderRendererBase}}:
{code}
@Override
public void doEncodeEnd(ResponseWriter writer, FacesContext context, UIComponent component) throws IOException {
AbstractPlaceholder placeholder = (AbstractPlaceholder) component;
// skip direct rendering for nested usage (workaround for RF-12589)
if (placeholder.getSelector() == null || placeholder.getSelector().isEmpty()) {
return;
}
}
{code}
I assume this is what makes sure only one element is rendered but the method is never called because it is overridden by doEncodeEnd of {{PlaceholderRenderer}}. There have been some changes with encodeEnd and doEncodeEnd in 4.5, looks like this was overlooked.
> Placeholder in collapsibleSubTable template
> -------------------------------------------
>
> Key: RF-13739
> URL: https://issues.jboss.org/browse/RF-13739
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-misc
> Affects Versions: 4.5.0.Alpha3
> Environment: RichFaces 4.5.0-SNAPSHOT
> Metamer 4.5.0-SNAPSHOT
> Mojarra 2.2.6-jbossorg-4
> JBoss AS 8.1.0.Final
> Java(TM) SE Runtime Environment 1.7.0_25-b15 @ Linux
> Firefox 30.0 @ Linux x86_64
> Reporter: Matej Novotny
> Assignee: Michal Petrov
> Labels: needs-qe
> Fix For: 4.5.0.Beta1
>
>
> Placeholder selector set to empty string ({{selector=""}}) does not work when nested inside richCollapsibleSubTable template. The expected result is that all inputs will contains the placeholder text, however none of them does. If you set selector to a specific ID, the test succeeds.
> This only happens when you attach the placeholder to {{<textarea>}} or {{<input>}}.
> For both cases we have facelets and tests in Metamer and [Jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/...] which runs the tests.
> Link to [facelet|https://github.com/richfaces/richfaces-qa/blob/master/metamer/app...] and [test|https://github.com/richfaces/richfaces-qa/blob/master/metamer/ftest/...] for textarea.
> Link to [facelet|https://github.com/richfaces/richfaces-qa/blob/master/metamer/app...] and [test|https://github.com/richfaces/richfaces-qa/blob/master/metamer/ftest/...] for input.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13732) RichList with scroll bar doesn't work correctly inside uiRepeat
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13732?page=com.atlassian.jira.plugin.s... ]
Matej Novotny edited comment on RF-13732 at 7/25/14 8:25 AM:
-------------------------------------------------------------
Linking together with RF-11787 since these two issues are very similar. Resolving one will probably resolve the other as well.
Also this issue can be tested with a test created for RF-11787 - [testScrollerWithRowsAttributeOutIterationComponents()|https://github.com/...]
EDIT: I marked the above mentioned test as @IssueTracking for this issue as well. Also I resolved the linked issue as duplicate since I verified they both deal with the same problem.
was (Author: manovotn):
Linking together with RF-11787 since these two issues are very similar. Resolving one will probably resolve the other as well.
Also this issue can be tested with a test created for RF-11787 - [testScrollerWithRowsAttributeOutIterationComponents()|https://github.com/...]
> 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)
9 years, 10 months
[JBoss JIRA] (RF-11787) Data scroller doesn't work for list inside data table
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-11787?page=com.atlassian.jira.plugin.s... ]
Matej Novotny resolved RF-11787.
--------------------------------
Labels: (was: ci_issue)
Fix Version/s: (was: 5-Future)
Resolution: Duplicate Issue
The inner scroller works fine now (I will remove {{@Future}} from that test since it succeeds). As for the other one, there is a another up-to-date issue following the problem - RF-13732. So I am resolving this not to have duplicated issues.
> Data scroller doesn't work for list inside data table
> -----------------------------------------------------
>
> Key: RF-11787
> URL: https://issues.jboss.org/browse/RF-11787
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.1.0.CR2, 4.3.0.M1
> Environment: RichFaces 4.1.0.CR2
> Metamer 4.1.0.20111201-CR2 r.23028
> Mojarra 2.1.3-b02
> JBoss AS 7.1.0.Beta1
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Chrome 15.0.874.121 @ Linux i686
> Reporter: Pavol Pitonak
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richList/scroller.xhtml?te...
> # switch to page 6 using first data scroller
> ## *result:* list is not switched
> # switch to the next page using first data scroller
> ## *result:* list is not switched
> # switch to page 4 using second data scroller
> ## *result:* list is switched to page 4
> # switch to the next page using second data scroller
> ## *result:* list is switched but to the page 2 instead of page 4
> Similar use-case using rich:dataTable instead of rich:list works fine (http://localhost:8080/metamer/faces/components/richDataTable/scroller.xhtml).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13732) RichList with scroll bar doesn't work correctly inside uiRepeat
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13732?page=com.atlassian.jira.plugin.s... ]
Matej Novotny commented on RF-13732:
------------------------------------
Linking together with RF-11787 since these two issues are very similar. Resolving one will probably resolve the other as well.
Also this issue can be tested with a test created for RF-11787 - [testScrollerWithRowsAttributeOutIterationComponents()|https://github.com/...]
> 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)
9 years, 10 months
[JBoss JIRA] (RF-13740) Richfaces 4.5 with MyFaces
by Matej Novotny (JIRA)
Matej Novotny created RF-13740:
----------------------------------
Summary: Richfaces 4.5 with MyFaces
Key: RF-13740
URL: https://issues.jboss.org/browse/RF-13740
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.5.0.Alpha3
Environment: Simpleapp archetype
Firefox/Chrome
Myfaces (I tried with several latest versions)
Tomcat 7
Reporter: Matej Novotny
Priority: Critical
When you deploy RichFaces 4.5 application with MyFaces as JSF implementation to Tomcat, any Ajax request will get NPE as a response. Therefore the whole application will not work.
Easiest way to reproduce this is with archetypes - see steps to reproduce.
But it can be also reproducer with Metamer (generate WAR file with myfaced and deploy to Tomcat 7)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13739) Placeholder in collapsibleSubTable template
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13739?page=com.atlassian.jira.plugin.s... ]
Matej Novotny reopened RF-13739:
--------------------------------
Reopening, the fix caused some more problems.
Placeholder now affect *all inputs* on the page when there is no template used (e.g. in plain template) and no selector set. Even the attribute setting inputs in the footer part of Metamer.
* Such behaviour was not present before and leads to test failures.
** I tried {{testSelector*}} tests and most of them fail atm because setting placeholder value with {{placeholderAttributes.set(PlaceholderAttributes.selector, "");}} has stopped working. Whichever value I set, no field is ever targeted.
** When setting the same thing manually , it works (but still, all fields will be targeted including those in footer when selector is empty string).
** This behavior only happens with plain template, in other templates value can be set both, manually and via placeholderAttributes.set() ans hence the tests pass correctly.
* The fields for setting placeholder value and selector are affected as well and contain watermark text. Once you change the template, they are no longer affected. I believe this causes the inability to set the values from code while in plain template.
> Placeholder in collapsibleSubTable template
> -------------------------------------------
>
> Key: RF-13739
> URL: https://issues.jboss.org/browse/RF-13739
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-misc
> Affects Versions: 4.5.0.Alpha3
> Environment: RichFaces 4.5.0-SNAPSHOT
> Metamer 4.5.0-SNAPSHOT
> Mojarra 2.2.6-jbossorg-4
> JBoss AS 8.1.0.Final
> Java(TM) SE Runtime Environment 1.7.0_25-b15 @ Linux
> Firefox 30.0 @ Linux x86_64
> Reporter: Matej Novotny
> Assignee: Michal Petrov
> Labels: needs-qe
> Fix For: 4.5.0.Beta1
>
>
> Placeholder selector set to empty string ({{selector=""}}) does not work when nested inside richCollapsibleSubTable template. The expected result is that all inputs will contains the placeholder text, however none of them does. If you set selector to a specific ID, the test succeeds.
> This only happens when you attach the placeholder to {{<textarea>}} or {{<input>}}.
> For both cases we have facelets and tests in Metamer and [Jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/...] which runs the tests.
> Link to [facelet|https://github.com/richfaces/richfaces-qa/blob/master/metamer/app...] and [test|https://github.com/richfaces/richfaces-qa/blob/master/metamer/ftest/...] for textarea.
> Link to [facelet|https://github.com/richfaces/richfaces-qa/blob/master/metamer/app...] and [test|https://github.com/richfaces/richfaces-qa/blob/master/metamer/ftest/...] for input.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months