[JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.s... ]
Juergen Zimmermann commented on RF-13568:
-----------------------------------------
No, with WildFly 8.0.0.Final I got the same stacktraces. Therefore, I tried to latest snapshot containing a newer Undertow.
> IllegalArgumentException for PushResource.jsf
> ---------------------------------------------
>
> Key: RF-13568
> URL: https://issues.jboss.org/browse/RF-13568
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Environment: WildFly snapshot with Undertow 1.0.1
> Reporter: Juergen Zimmermann
>
> Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following:
> {code}
> [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present
> at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {code}
--
This message 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, 3 months
[JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13568:
---------------------------------
[~juergen.zimmermann] I guess everything is okay with WildFly 8 Final?
Hey [~swd847], anything changed with respect to request parameter handling in Undertow 1.0.1?
> IllegalArgumentException for PushResource.jsf
> ---------------------------------------------
>
> Key: RF-13568
> URL: https://issues.jboss.org/browse/RF-13568
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Environment: WildFly snapshot with Undertow 1.0.1
> Reporter: Juergen Zimmermann
>
> Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following:
> {code}
> [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present
> at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {code}
--
This message 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, 3 months
[JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created RF-13568:
---------------------------------------
Summary: IllegalArgumentException for PushResource.jsf
Key: RF-13568
URL: https://issues.jboss.org/browse/RF-13568
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-push/poll
Affects Versions: 5.0.0.Alpha3
Environment: WildFly snapshot with Undertow 1.0.1
Reporter: Juergen Zimmermann
Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following:
{code}
[io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present
at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
{code}
--
This message 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, 3 months
[JBoss JIRA] (RF-13168) 3rd party JSF component disappears on RichFaces ajax refresh
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/RF-13168?page=com.atlassian.jira.plugin.s... ]
Frank Langelage commented on RF-13168:
--------------------------------------
Thank you very much for spending the time to drill down into this problem.
The version I was using is a nightly build of 3.1. But this was not updated since Nov 22.
Sources are available at https://github.com/openfaces/OpenFaces, but there the method looks like the on as of version 3.0.
And there are recent commits on github.
I'll try to make a build from github sources and see if this solves the problem or otherwise create an issue for openfaces.org.
> 3rd party JSF component disappears on RichFaces ajax refresh
> ------------------------------------------------------------
>
> Key: RF-13168
> URL: https://issues.jboss.org/browse/RF-13168
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility, component-a4j-core
> Reporter: Frank Langelage
> Assignee: Lukáš Fryč
> Labels: interop, jsf22
> Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, Jira-WFLY-UT.tar, xaa, xaa, xab, xab, xac, xac
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 3 months
[JBoss JIRA] (RF-13168) 3rd party JSF component disappears on RichFaces ajax refresh
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13168?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13168:
---------------------------------
After decompiling TableBody, I got following source for createRows method where the request fails:
{code}
protected List<BodyRow> createRows(FacesContext context, int firstRowIndex, int rowCount, List<BaseColumn> columns)
throws IOException
{
ResponseWriter writer = context.getResponseWriter();
StringWriter stringWriter = new StringWriter();
List<BodyRow> rows = new ArrayList();
ResponseWriter responseWriter = writer.cloneWithWriter(stringWriter);
if (AjaxUtil.isAjaxRequest(context)) {
responseWriter.startCDATA();
}
stringWriter.getBuffer().setLength(0);
context.setResponseWriter(responseWriter);
try
{
if (this.tableStructure.getScrolling() == null) {
rows = createNonScrollableRows(context, stringWriter, firstRowIndex, rowCount, columns);
} else {
rows = createScrollableRows(context, stringWriter, firstRowIndex, rowCount, columns);
}
}
finally
{
if (AjaxUtil.isAjaxRequest(context)) {
responseWriter.endCDATA();
}
context.setResponseWriter(writer);
}
return rows;
}
{code}
Note {{responseWriter.startCDATA();}} line.
The OpenFaces 3.0 (from downloads page):
{code}
protected List<BodyRow> createRows(
FacesContext context,
int firstRowIndex,
int rowCount,
List<BaseColumn> columns
) throws IOException {
ResponseWriter writer = context.getResponseWriter();
StringWriter stringWriter = new StringWriter();
List<BodyRow> rows = new ArrayList<BodyRow>();
context.setResponseWriter(writer.cloneWithWriter(stringWriter));
try {
if (tableStructure.getScrolling() == null)
rows = createNonScrollableRows(context, stringWriter, firstRowIndex, rowCount, columns);
else
rows = createScrollableRows(context, stringWriter, firstRowIndex, rowCount, columns);
} finally {
context.setResponseWriter(writer);
}
return rows;
}
{code}
Could you hand this issue over to OpenFaces guys?
> 3rd party JSF component disappears on RichFaces ajax refresh
> ------------------------------------------------------------
>
> Key: RF-13168
> URL: https://issues.jboss.org/browse/RF-13168
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility, component-a4j-core
> Reporter: Frank Langelage
> Assignee: Lukáš Fryč
> Labels: interop, jsf22
> Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, Jira-WFLY-UT.tar, xaa, xaa, xab, xab, xac, xac
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 3 months
[JBoss JIRA] (RF-13168) 3rd party JSF component disappears on RichFaces ajax refresh
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13168?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13168:
---------------------------------
Hey Frank,
your sample really reproduces the issue, however when I have tried with OpenFaces available on http://openfaces.org/downloads/ it works just fine.
So this issue really isn't in RichFaces. Unfortunatelly I can't look into source what's happenning, because I doin't have source for the OpenFaces version you have attached.
The last stacktrace you provided also suggest the problem comes from OpenFaces data table rendering logic.
I start to think OpenFaces renderer fails but JSF hides some issue behind another issue (CDATA may not nest).
But as you pointed out, the sample works just fine with WildFly CR1. So I wonder what could be changed in JSF impl between 2.2.4-jbossorg-1 and 2.2.5-jbossorg-3 that would make this stop to work.
> 3rd party JSF component disappears on RichFaces ajax refresh
> ------------------------------------------------------------
>
> Key: RF-13168
> URL: https://issues.jboss.org/browse/RF-13168
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility, component-a4j-core
> Reporter: Frank Langelage
> Assignee: Lukáš Fryč
> Labels: interop, jsf22
> Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, Jira-WFLY-UT.tar, xaa, xaa, xab, xab, xac, xac
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 3 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12897:
---------------------------------
[~ccerb] does this ^ address your concerns?
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {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, 3 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12897 at 3/6/14 6:42 AM:
---------------------------------------------------------
The big part is addressed by RF-13505, the only remaining logic where RichFaces could swallow exceptions is {{MetaComponentEncodingVisitCallback}}.
In other words: refactored EPVC won't swallow exceptions as the partial processing logic is performed by JSF implementation (Mojarra).
was (Author: lfryc):
The big part is addressed by RF-13505, the only remaining logic where RichFaces could swallow exceptions is {{MetaComponentEncodingVisitCallback}}.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {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, 3 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12897:
----------------------------
Fix Version/s: 5.0.0.Alpha4
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {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, 3 months