[JBoss JIRA] (RF-13444) r:fileUpload throws IOException "Request prolog cannot be read"
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13444?page=com.atlassian.jira.plugin.s... ]
Matej Novotny commented on RF-13444:
------------------------------------
Confirming this bug. It can be reproduced with our Showcase for RF 5.
Added steps to reproduce.
> r:fileUpload throws IOException "Request prolog cannot be read"
> ---------------------------------------------------------------
>
> Key: RF-13444
> URL: https://issues.jboss.org/browse/RF-13444
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha2
> Environment: WildFly CR1
> JSF 2.2
> Reporter: Juergen Zimmermann
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
>
> I tried f:fileUpload with the latest WildFly snapshot. When uploading a jpeg file I get this stacktrace. Maybe, RF-13061 is back in town...
> {code}
> SEVERE [org.richfaces.log.Application] (default task-6) Exception parsing multipart request: Request prolog cannot be read: org.richfaces.exception.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:75) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:56) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at java.util.Collections$UnmodifiableMap.get(Collections.java:1339) [rt.jar:1.7.0_45]
> at com.sun.faces.application.view.MultiViewHandler.calculateRenderKitId(MultiViewHandler.java:220) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at com.sun.faces.context.FacesContextImpl.isPostback(FacesContextImpl.java:212) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.context.FacesContextWrapper.isPostback(FacesContextWrapper.java:461) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:193) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> 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.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> ... 43 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, 5 months
[JBoss JIRA] (RF-13444) r:fileUpload throws IOException "Request prolog cannot be read"
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13444?page=com.atlassian.jira.plugin.s... ]
Matej Novotny updated RF-13444:
-------------------------------
Steps to Reproduce:
* Start a WildFly CR1 server with JFS 2.2 (that is default)
* Build and deploy Showcase application for RF 5
* Go to [file upload page|http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=fileUpload&skin=blueSky] and try to upload a _valid file_ (that is up to 100kb and png or jpeg)
* See server console for error
Environment:
WildFly CR1
JSF 2.2
> r:fileUpload throws IOException "Request prolog cannot be read"
> ---------------------------------------------------------------
>
> Key: RF-13444
> URL: https://issues.jboss.org/browse/RF-13444
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha2
> Environment: WildFly CR1
> JSF 2.2
> Reporter: Juergen Zimmermann
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
>
> I tried f:fileUpload with the latest WildFly snapshot. When uploading a jpeg file I get this stacktrace. Maybe, RF-13061 is back in town...
> {code}
> SEVERE [org.richfaces.log.Application] (default task-6) Exception parsing multipart request: Request prolog cannot be read: org.richfaces.exception.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:75) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:56) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at java.util.Collections$UnmodifiableMap.get(Collections.java:1339) [rt.jar:1.7.0_45]
> at com.sun.faces.application.view.MultiViewHandler.calculateRenderKitId(MultiViewHandler.java:220) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.application.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:157) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at com.sun.faces.context.FacesContextImpl.isPostback(FacesContextImpl.java:212) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.context.FacesContextWrapper.isPostback(FacesContextWrapper.java:461) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:193) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.4-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> 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.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta28.jar:1.0.0.Beta28]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) [richfaces-5.0.0.Alpha2.jar:5.0.0.Alpha2]
> ... 43 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, 5 months
[JBoss JIRA] (RF-13307) Support java.util.Set in iteration components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13307?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč reassigned RF-13307:
-------------------------------
Assignee: Lukáš Fryč
> Support java.util.Set in iteration components
> ---------------------------------------------
>
> Key: RF-13307
> URL: https://issues.jboss.org/browse/RF-13307
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.4, 5.0.0.Alpha1
> Environment: Wildfly-8.0.0.Beta1
> Reporter: Matti Bickel
> Assignee: Lukáš Fryč
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> JSF-2.2 now supports iteration over sets as in
> {code:xml}
> <h:dataTable value="#{myBean.mySet}" var="elem">
> <h:column>#{elem.name}</h:column>
> </h:dataTable>
> {code}
> Using RF iteration components this is currently not possible as UISequence.java doesn't detect Sets and treats them as scalar values.
> Would be nice if RF catches up with JSF here.
--
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, 5 months
[JBoss JIRA] (RF-13093) EPVC: ViewState must be written even for transient (stateless) views
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13093?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved RF-13093.
-----------------------------
Resolution: Done
{{ExtendedPartialViewContext#renderState()}} was skipping a step of writing a state into partial-response when view was transient.
In this case, Mojarra writes the state, but it simply contains string "stateless".
> EPVC: ViewState must be written even for transient (stateless) views
> --------------------------------------------------------------------
>
> Key: RF-13093
> URL: https://issues.jboss.org/browse/RF-13093
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23
> Reporter: Salvo Isaja
> Assignee: Lukáš Fryč
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Original summary: *extendedDataTable column resizing and reordering not working on transient (stateless) views*
> When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
> {code:xml}
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response></partial-response>
> {code}
> This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
> Other features seem to work pretty well in stateless mode, by the way.
> Thanks
--
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, 5 months
[JBoss JIRA] (RF-13093) EPVC: ViewState must be written even for transient (stateless) views
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13093?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13093:
----------------------------
Summary: EPVC: ViewState must be written even for transient (stateless) views (was: extendedDataTable column resizing and reordering not working on transient (stateless) views)
> EPVC: ViewState must be written even for transient (stateless) views
> --------------------------------------------------------------------
>
> Key: RF-13093
> URL: https://issues.jboss.org/browse/RF-13093
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23
> Reporter: Salvo Isaja
> Assignee: Lukáš Fryč
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Original summary: *extendedDataTable column resizing and reordering not working on transient (stateless) views*
> When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
> {code:xml}
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response></partial-response>
> {code}
> This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
> Other features seem to work pretty well in stateless mode, by the way.
> Thanks
--
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, 5 months
[JBoss JIRA] (RF-13093) extendedDataTable column resizing and reordering not working on transient (stateless) views
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13093?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13093:
----------------------------
Description:
Original summary: *extendedDataTable column resizing and reordering not working on transient (stateless) views*
When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
{code:xml}
<?xml version='1.0' encoding='UTF-8'?>
<partial-response></partial-response>
{code}
This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
Other features seem to work pretty well in stateless mode, by the way.
Thanks
was:
When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
{code:xml}
<?xml version='1.0' encoding='UTF-8'?>
<partial-response></partial-response>
{code}
This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
Other features seem to work pretty well in stateless mode, by the way.
Thanks
> extendedDataTable column resizing and reordering not working on transient (stateless) views
> -------------------------------------------------------------------------------------------
>
> Key: RF-13093
> URL: https://issues.jboss.org/browse/RF-13093
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23
> Reporter: Salvo Isaja
> Assignee: Lukáš Fryč
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Original summary: *extendedDataTable column resizing and reordering not working on transient (stateless) views*
> When turning on transient (stateless) views in recent Mojarra versions (as per JSF 2.2 specification, to my best understanding), using request scoped backing beans, javax.faces.ViewState becomes the constant "stateless". Column resizing and reordering in extendedDataTable causes an Ajax request to the server, but in this case an invalid response is sent, containing only:
> {code:xml}
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response></partial-response>
> {code}
> This causes an exception in {{jsf.js}} because the partial-response element has no children and no further JavaScript processing happens in the view until the page is reloaded. In the non-transient view case, I see a {{change}} element updating only the ViewState is returned, instead.
> Other features seem to work pretty well in stateless mode, by the way.
> Thanks
--
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, 5 months
[JBoss JIRA] (RF-13314) Deprecate reslib resource files
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13314?page=com.atlassian.jira.plugin.s... ]
Matej Novotny commented on RF-13314:
------------------------------------
Lukas, thanks for info, I re-checked it and there is still one component with stack overflow exception - *r:chart*.
The other errors I found are still present though, is there anything else I can do about those?
> Deprecate reslib resource files
> -------------------------------
>
> Key: RF-13314
> URL: https://issues.jboss.org/browse/RF-13314
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 5-Tracking
> Reporter: Michal Petrov
> Assignee: Lukáš Fryč
> Labels: needs-qe
> Fix For: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
>
>
--
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, 5 months