[JBoss JIRA] (RF-13266) mediaOutput not working anymore on Glassfish3 and EAP6.1
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13266?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13266:
-------------------------------
Labels: regression (was: needs-qe regression)
> mediaOutput not working anymore on Glassfish3 and EAP6.1
> --------------------------------------------------------
>
> Key: RF-13266
> URL: https://issues.jboss.org/browse/RF-13266
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.4
> Environment: Glassfish 3.1.2.2 patched with Weld 1.1.14 (the problem appears also on earlier Weld builds) and JSF 2.1.26 and JDK 1.7.0_45
> Reporter: Fab Mars
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> This is a followup to https://issues.jboss.org/browse/RF-13098 focusing on Glassfish3.
> I have 2 mediaOutput in my code, none works.
> The first one passes a Long as the value to the createContent method and the expected output is a PDF. I get
> SEVERE: Input error for deserialize data java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.util.el.ForwardingMethodExpression
> The second one passes an array of 3 bytes (a color code) and the expected result is an image. I get
> SEVERE: Input error for deserialize data java.io.InvalidClassException: Unauthorized deserialization attempt; [B
> I'm preparing a reproducer on github and will share the url in the next comment.
--
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, 11 months
[JBoss JIRA] (RF-13278) rich:tab : label, placed in header-facet, can not be refreshed per ajax
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13278?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13278 at 12/20/13 1:19 AM:
--------------------------------------------------------------
To recap:
The component with id _label_ is rendered during a component tree walk when the visited component has a matching id. If the component is never visited in the tree walk, it is never rendered. There are two means the _label_ component will be visited/rendered in a tree walk:
# when the tabPanel is rendered, and the tab headers are rendered
# when the tabPanel children/facets are visited
Prior to RichFaces 4.3.4, 2) was the case. With every component tree walk, every child of every tab was visited, including those that were not visible. This incurred a significant performance overhead. With the resolution of RF-13107 the visit was prevented for all non-active tabs. This is why the _label_ component is no longer visited unless the tabPanel is an explicit render target.
Let's take a look at the performance overhead incurred when tabPanel is a render target. When a tab header is clicked, the active tab (_tabPanel@ActiveItem_) is rendered regardless of the render target. Then the tabPanel is the render target, the active tab panel, and the tab headers are rendered. So the only additional overhead incurred is in the rendering of the tab headers.
[~alsha] are you sure you are incurring _ much more performance overhead_ ? Do you have any numbers to back this up? I would presume that you would in fact see a performance increase with 4.3.4 given that the inactive tabs are no longer updated.
was (Author: bleathem):
To recap:
The component with id _label_ is rendered during a component tree walk when the visited component has a matching id. If the component is never visited in the tree walk, it is never rendered. There are two means the _label_ component will be visited/rendered in a tree walk:
# when the tabPanel is rendered, and the tab headers are rendered
# when the tabPanel children/facets are visited
Prior to RichFaces 4.3.4, 2) was the case. With every component tree walk, every child of every tab was visited, including those that were not visible. This incurred a significant performance overhead. With the resolution of RF-13107 the visit was prevented for all non-active tabs. This is why the _label_ component is no longer visited unless the tabPanel is an explicit render target.
Let's take a look at the performance overhead incurred when tabPanel is a render target. When a tab header is clicked, the active tab (_tabPanel@ActiveItem_) is rendered regardless of the render target. Then the tabPanel is the render target, the active tab panel, and the tab headers are rendered. So the only additional overhead incurred is in the rendering of the tab headers.
[~alsha] are you sure you are incurring _ much more performance overhead_? Do you have any numbers to back this up? I would presume that you would in fact see a performance increase with 4.3.4 given that the inactive tabs are no longer updated.
> rich:tab : label, placed in header-facet, can not be refreshed per ajax
> -----------------------------------------------------------------------
>
> Key: RF-13278
> URL: https://issues.jboss.org/browse/RF-13278
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.4
> Environment: java 7,
> tomcat 7, JBoss AS,
> mojarra, myfaces
> chrome, firefox
> Reporter: Alexey Shakov
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> I use ajax to update the header label of rich:tab. That is why label is placed in a header-facet. Since RF 4.3.4 this does not work:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"
> xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j"
> xmlns:f="http://java.sun.com/jsf/core" xml:lang="en" lang="en">
> <h:head>
> </h:head>
> <h:body>
>
> <a4j:log hotkey="M" mode="popup" />
> <h:form id="form" prependId="false">
> <rich:tabPanel id="tabPanel">
> <rich:tab header="tab 1">
> <a4j:commandLink value="click me" action="#{testBean.put('clicks',testBean.clicks + 1)}" render="label" execute="@this" />
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> <h:outputText id="label" value="#{testBean.clicks} clicks" />
> </f:facet>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> testBean is a simple session-scoped HashMap.
--
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, 11 months
[JBoss JIRA] (RF-13278) rich:tab : label, placed in header-facet, can not be refreshed per ajax
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13278?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13278:
-------------------------------
Workaround Description: Specify the parent _tabPanel_ component as a render target. (was: refresh enclosing rich:tabPanel component)
> rich:tab : label, placed in header-facet, can not be refreshed per ajax
> -----------------------------------------------------------------------
>
> Key: RF-13278
> URL: https://issues.jboss.org/browse/RF-13278
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.4
> Environment: java 7,
> tomcat 7, JBoss AS,
> mojarra, myfaces
> chrome, firefox
> Reporter: Alexey Shakov
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> I use ajax to update the header label of rich:tab. That is why label is placed in a header-facet. Since RF 4.3.4 this does not work:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"
> xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j"
> xmlns:f="http://java.sun.com/jsf/core" xml:lang="en" lang="en">
> <h:head>
> </h:head>
> <h:body>
>
> <a4j:log hotkey="M" mode="popup" />
> <h:form id="form" prependId="false">
> <rich:tabPanel id="tabPanel">
> <rich:tab header="tab 1">
> <a4j:commandLink value="click me" action="#{testBean.put('clicks',testBean.clicks + 1)}" render="label" execute="@this" />
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> <h:outputText id="label" value="#{testBean.clicks} clicks" />
> </f:facet>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> testBean is a simple session-scoped HashMap.
--
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, 11 months
[JBoss JIRA] (RF-13278) rich:tab : label, placed in header-facet, can not be refreshed per ajax
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13278?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13278 at 12/20/13 1:19 AM:
--------------------------------------------------------------
To recap:
The component with id _label_ is rendered during a component tree walk when the visited component has a matching id. If the component is never visited in the tree walk, it is never rendered. There are two means the _label_ component will be visited/rendered in a tree walk:
# when the tabPanel is rendered, and the tab headers are rendered
# when the tabPanel children/facets are visited
Prior to RichFaces 4.3.4, 2) was the case. With every component tree walk, every child of every tab was visited, including those that were not visible. This incurred a significant performance overhead. With the resolution of RF-13107 the visit was prevented for all non-active tabs. This is why the _label_ component is no longer visited unless the tabPanel is an explicit render target.
Let's take a look at the performance overhead incurred when tabPanel is a render target. When a tab header is clicked, the active tab (_tabPanel@ActiveItem_) is rendered regardless of the render target. Then the tabPanel is the render target, the active tab panel, and the tab headers are rendered. So the only additional overhead incurred is in the rendering of the tab headers.
[~alsha] are you sure you are incurring _much more performance overhead_? Do you have any numbers to back this up? I would presume that you would in fact see a performance increase with 4.3.4 given that the inactive tabs are no longer updated.
was (Author: bleathem):
To recap:
The component with id _label_ is rendered during a component tree walk when the visited component has a matching id. If the component is never visited in the tree walk, it is never rendered. There are two means the _label_ component will be visited/rendered in a tree walk:
# when the tabPanel is rendered, and the tab headers are rendered
# when the tabPanel children/facets are visited
Prior to RichFaces 4.3.4, 2) was the case. With every component tree walk, every child of every tab was visited, including those that were not visible. This incurred a significant performance overhead. With the resolution of RF-13107 the visit was prevented for all non-active tabs. This is why the _label_ component is no longer visited unless the tabPanel is an explicit render target.
Let's take a look at the performance overhead incurred when tabPanel is a render target. When a tab header is clicked, the active tab (_tabPanel@ActiveItem_) is rendered regardless of the render target. Then the tabPanel is the render target, the active tab panel, and the tab headers are rendered. So the only additional overhead incurred is in the rendering of the tab headers.
[~alsha] are you sure you are incurring _ much more performance overhead_ ? Do you have any numbers to back this up? I would presume that you would in fact see a performance increase with 4.3.4 given that the inactive tabs are no longer updated.
> rich:tab : label, placed in header-facet, can not be refreshed per ajax
> -----------------------------------------------------------------------
>
> Key: RF-13278
> URL: https://issues.jboss.org/browse/RF-13278
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.4
> Environment: java 7,
> tomcat 7, JBoss AS,
> mojarra, myfaces
> chrome, firefox
> Reporter: Alexey Shakov
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> I use ajax to update the header label of rich:tab. That is why label is placed in a header-facet. Since RF 4.3.4 this does not work:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"
> xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j"
> xmlns:f="http://java.sun.com/jsf/core" xml:lang="en" lang="en">
> <h:head>
> </h:head>
> <h:body>
>
> <a4j:log hotkey="M" mode="popup" />
> <h:form id="form" prependId="false">
> <rich:tabPanel id="tabPanel">
> <rich:tab header="tab 1">
> <a4j:commandLink value="click me" action="#{testBean.put('clicks',testBean.clicks + 1)}" render="label" execute="@this" />
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> <h:outputText id="label" value="#{testBean.clicks} clicks" />
> </f:facet>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> testBean is a simple session-scoped HashMap.
--
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, 11 months
[JBoss JIRA] (RF-13278) rich:tab : label, placed in header-facet, can not be refreshed per ajax
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13278?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13278:
------------------------------------
To recap:
The component with id _label_ is rendered during a component tree walk when the visited component has a matching id. If the component is never visited in the tree walk, it is never rendered. There are two means the _label_ component will be visited/rendered in a tree walk:
# when the tabPanel is rendered, and the tab headers are rendered
# when the tabPanel children/facets are visited
Prior to RichFaces 4.3.4, 2) was the case. With every component tree walk, every child of every tab was visited, including those that were not visible. This incurred a significant performance overhead. With the resolution of RF-13107 the visit was prevented for all non-active tabs. This is why the _label_ component is no longer visited unless the tabPanel is an explicit render target.
Let's take a look at the performance overhead incurred when tabPanel is a render target. When a tab header is clicked, the active tab (_tabPanel@ActiveItem_) is rendered regardless of the render target. Then the tabPanel is the render target, the active tab panel, and the tab headers are rendered. So the only additional overhead incurred is in the rendering of the tab headers.
[~alsha] are you sure you are incurring _ much more performance overhead_? Do you have any numbers to back this up? I would presume that you would in fact see a performance increase with 4.3.4 given that the inactive tabs are no longer updated.
> rich:tab : label, placed in header-facet, can not be refreshed per ajax
> -----------------------------------------------------------------------
>
> Key: RF-13278
> URL: https://issues.jboss.org/browse/RF-13278
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.4
> Environment: java 7,
> tomcat 7, JBoss AS,
> mojarra, myfaces
> chrome, firefox
> Reporter: Alexey Shakov
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> I use ajax to update the header label of rich:tab. That is why label is placed in a header-facet. Since RF 4.3.4 this does not work:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"
> xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j"
> xmlns:f="http://java.sun.com/jsf/core" xml:lang="en" lang="en">
> <h:head>
> </h:head>
> <h:body>
>
> <a4j:log hotkey="M" mode="popup" />
> <h:form id="form" prependId="false">
> <rich:tabPanel id="tabPanel">
> <rich:tab header="tab 1">
> <a4j:commandLink value="click me" action="#{testBean.put('clicks',testBean.clicks + 1)}" render="label" execute="@this" />
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> <h:outputText id="label" value="#{testBean.clicks} clicks" />
> </f:facet>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> testBean is a simple session-scoped HashMap.
--
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, 11 months
[JBoss JIRA] (RF-13278) rich:tab : label, placed in header-facet, can not be refreshed per ajax
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13278?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13278:
----------------------------------
[~bleathem] : Yes, you are right. I can confirm that it is broken in RF 5-SNAPSHOT as well.
> rich:tab : label, placed in header-facet, can not be refreshed per ajax
> -----------------------------------------------------------------------
>
> Key: RF-13278
> URL: https://issues.jboss.org/browse/RF-13278
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.3.4
> Environment: java 7,
> tomcat 7, JBoss AS,
> mojarra, myfaces
> chrome, firefox
> Reporter: Alexey Shakov
> Labels: regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> I use ajax to update the header label of rich:tab. That is why label is placed in a header-facet. Since RF 4.3.4 this does not work:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"
> xmlns:c="http://java.sun.com/jsp/jstl/core" xmlns:rich="http://richfaces.org/rich" xmlns:a4j="http://richfaces.org/a4j"
> xmlns:f="http://java.sun.com/jsf/core" xml:lang="en" lang="en">
> <h:head>
> </h:head>
> <h:body>
>
> <a4j:log hotkey="M" mode="popup" />
> <h:form id="form" prependId="false">
> <rich:tabPanel id="tabPanel">
> <rich:tab header="tab 1">
> <a4j:commandLink value="click me" action="#{testBean.put('clicks',testBean.clicks + 1)}" render="label" execute="@this" />
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> <h:outputText id="label" value="#{testBean.clicks} clicks" />
> </f:facet>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
> testBean is a simple session-scoped HashMap.
--
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, 11 months
[JBoss JIRA] (RF-13266) mediaOutput not working anymore on Glassfish3 and EAP6.1
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/RF-13266?page=com.atlassian.jira.plugin.s... ]
Matej Novotny commented on RF-13266:
------------------------------------
For verification I used EAP 6.1.1 and refactored the example to use RF 4.3.5.Snapshot (all I needed to alter was version and repository URL).
Both demos are now working properly, the first one showing a functional link to a PDF file, the other displaying an image.
> mediaOutput not working anymore on Glassfish3 and EAP6.1
> --------------------------------------------------------
>
> Key: RF-13266
> URL: https://issues.jboss.org/browse/RF-13266
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.4
> Environment: Glassfish 3.1.2.2 patched with Weld 1.1.14 (the problem appears also on earlier Weld builds) and JSF 2.1.26 and JDK 1.7.0_45
> Reporter: Fab Mars
> Assignee: Brian Leathem
> Labels: needs-qe, regression
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> This is a followup to https://issues.jboss.org/browse/RF-13098 focusing on Glassfish3.
> I have 2 mediaOutput in my code, none works.
> The first one passes a Long as the value to the createContent method and the expected output is a PDF. I get
> SEVERE: Input error for deserialize data java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.util.el.ForwardingMethodExpression
> The second one passes an array of 3 bytes (a color code) and the expected result is an image. I get
> SEVERE: Input error for deserialize data java.io.InvalidClassException: Unauthorized deserialization attempt; [B
> I'm preparing a reproducer on github and will share the url in the next comment.
--
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, 11 months
[JBoss JIRA] (RF-13444) r:fileUpload throws IOException "Request prolog cannot be read"
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created RF-13444:
---------------------------------------
Summary: 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
Reporter: Juergen Zimmermann
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, 11 months
[JBoss JIRA] (RF-13442) iterationStatusVar not working in header/footer of extendedDataTable
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13442?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak reassigned RF-13442:
----------------------------------
Assignee: Brian Leathem (was: Pavol Pitonak)
I could reproduce in Metamer. There is the same problem in r:dataGrid and r:dataTable.
> iterationStatusVar not working in header/footer of extendedDataTable
> --------------------------------------------------------------------
>
> Key: RF-13442
> URL: https://issues.jboss.org/browse/RF-13442
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha2
> Reporter: Michael Abele
> Assignee: Brian Leathem
>
> interationStatusVar attribute is available in columns of r:extendedDataTable but not in footer or header part of the table. This would be very useful to display messages like "15 rows loaded" in a table footer.
> Example code:
> {code}
> <r:extendedDataTable values="#{testBean.rows}" interationStatusVar="iter">
> <r:column>#{iter.index}</r:column
> <f:facet name="footer">
> <h:outputText value="#{iter.rowCount} rows loaded." />
> </f:facet>
> </r:extendedDataTable>
> {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, 11 months