[JBoss JIRA] (RF-13061) r:fileUpload stops working: "Request prolog cannot be read"
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13061?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13061:
------------------------------------
[~Trims] The RichFaces 5.0.0.Alpha3 fileupload works on WildFly 8.0.0.Final. There is still an outstanding issue with the progress bar that we are working on resolving.
> r:fileUpload stops working: "Request prolog cannot be read"
> -----------------------------------------------------------
>
> Key: RF-13061
> URL: https://issues.jboss.org/browse/RF-13061
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juergen Zimmermann
>
> I just tried r:fileUpload with the current snapshot for WildFly 8.0.0.Alpha2 (changed Mojarra 2.2.0 to 2.1.23). It actually looks pretty good. However, I'm getting this stacktrace for fileUpload:
> {code}
> 16:33:44,571 SEVERE [org.richfaces.log.Application] Exception parsing multipart request: Request prolog cannot be read: org.richfaces.ui.input.fileUpload.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:75) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:56) [jsf-impl-2.1.23.jar:2.1.23]
> at java.util.Collections$UnmodifiableMap.get(Collections.java:1339) [rt.jar:1.7.0_21]
> at com.sun.faces.facelets.tag.ui.UIDebug.debugRequest(UIDebug.java:168) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash$PreviousNextFlashInfoManager.decode(ELFlash.java:1225) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.getCurrentFlashManager(ELFlash.java:1059) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.doPrePhaseActions(ELFlash.java:557) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:215) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.23.jar:2.1.23]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.23.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:127) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> ... 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, 2 months
[JBoss JIRA] (RF-12199) rich:tooltip does not work inside h:graphicImage
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12199?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12199:
------------------------------------
Sounds like if this is still an issue it's with a slightly different use case. Please open a new issue attaching sample code required to reproduce.
> rich:tooltip does not work inside h:graphicImage
> ------------------------------------------------
>
> Key: RF-12199
> URL: https://issues.jboss.org/browse/RF-12199
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.1.Final
> Environment: RF 4.2.1.Final, GF 3.1.1
> Reporter: Bernhard Thalmayr
> Assignee: Luca Nardelli
> Fix For: 4.2.2.Final
>
>
> I created a simple richfaces app using maven archetype 'richfaces-archetype-simpleapp'
> Nesting rich:tooltip within h:graphicImage does not work; used mark up
> {code}
> <h:graphicImage id="img1" name="projectavatar.png" library="images">
> <rich:tooltip>
> <span>tooltip1</span>
> </rich:tooltip>
> </h:graphicImage>
> {code}
> wrapping h:graphicImage within a4j:outputPanel is no workaround
> {code}
> <a4j:outputPanel>
> <h:graphicImage id="img2" name="projectavatar.png" library="images">
> <rich:tooltip>
> <span>tooltip2</span>
> </rich:tooltip>
> </h:graphicImage>
> </a4j:outputPanel>
> {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, 2 months
[JBoss JIRA] (RF-12289) rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
by Jonáš Trantina (JIRA)
[ https://issues.jboss.org/browse/RF-12289?page=com.atlassian.jira.plugin.s... ]
Jonáš Trantina updated RF-12289:
--------------------------------
Attachment: another-reproducer.zip
Added another reproducer with lates RF 4.x version. Issue still persists.
> rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12289
> URL: https://issues.jboss.org/browse/RF-12289
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.2.1.Final, 4.2.2.Final, 4.3.5
> Reporter: Nicolas Daniels
> Fix For: 5-Tracking
>
> Attachments: another-reproducer.zip, richfaces-sandbox.zip, rich_dataTable-rows.png, test.jspx, TestFace.java
>
>
> Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
> Basically, what I have is:
> <h:selectOneMenu value="#{myBean.batchRows}">
> <f:selectItem itemLabel="10" itemValue="10"/>
> <f:selectItem itemLabel="20" itemValue="20"/>
> <f:ajax render="table table-ds" />
> </h:selectOneMenu>
> ...
> <h:panelGroup>
> <rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
> ...
> </rich:dataTable>
> </h:panelGroup>
> <rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
> ...
> </rich:dataScroller>
>
> And the behaviour with 21 elements:
> - on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
>
> If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
>
> Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
> - rows: 10 (correct)
> - first: 20 (weird)
>
> Following calls to this method is setting those properties to:
> - rows: 10 (correct)
> - first: 10 (correct)
>
--
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, 2 months
[JBoss JIRA] (RF-12289) rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
by Jonáš Trantina (JIRA)
[ https://issues.jboss.org/browse/RF-12289?page=com.atlassian.jira.plugin.s... ]
Jonáš Trantina updated RF-12289:
--------------------------------
Affects Version/s: 4.3.5
> rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12289
> URL: https://issues.jboss.org/browse/RF-12289
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.2.1.Final, 4.2.2.Final, 4.3.5
> Reporter: Nicolas Daniels
> Fix For: 5-Tracking
>
> Attachments: another-reproducer.zip, richfaces-sandbox.zip, rich_dataTable-rows.png, test.jspx, TestFace.java
>
>
> Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
> Basically, what I have is:
> <h:selectOneMenu value="#{myBean.batchRows}">
> <f:selectItem itemLabel="10" itemValue="10"/>
> <f:selectItem itemLabel="20" itemValue="20"/>
> <f:ajax render="table table-ds" />
> </h:selectOneMenu>
> ...
> <h:panelGroup>
> <rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
> ...
> </rich:dataTable>
> </h:panelGroup>
> <rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
> ...
> </rich:dataScroller>
>
> And the behaviour with 21 elements:
> - on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
>
> If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
>
> Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
> - rows: 10 (correct)
> - first: 20 (weird)
>
> Following calls to this method is setting those properties to:
> - rows: 10 (correct)
> - first: 10 (correct)
>
--
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, 2 months
[JBoss JIRA] (RF-12289) rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
by Jonáš Trantina (JIRA)
[ https://issues.jboss.org/browse/RF-12289?page=com.atlassian.jira.plugin.s... ]
Jonáš Trantina updated RF-12289:
--------------------------------
Summary: rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated (was: rich:dataTable and rich:dataScroller inside rich:panelGroup - doesn't display the correct number of rows when number of rows is updated)
> rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12289
> URL: https://issues.jboss.org/browse/RF-12289
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.2.1.Final, 4.2.2.Final
> Reporter: Nicolas Daniels
> Fix For: 5-Tracking
>
> Attachments: richfaces-sandbox.zip, rich_dataTable-rows.png, test.jspx, TestFace.java
>
>
> Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
> Basically, what I have is:
> <h:selectOneMenu value="#{myBean.batchRows}">
> <f:selectItem itemLabel="10" itemValue="10"/>
> <f:selectItem itemLabel="20" itemValue="20"/>
> <f:ajax render="table table-ds" />
> </h:selectOneMenu>
> ...
> <h:panelGroup>
> <rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
> ...
> </rich:dataTable>
> </h:panelGroup>
> <rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
> ...
> </rich:dataScroller>
>
> And the behaviour with 21 elements:
> - on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
>
> If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
>
> Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
> - rows: 10 (correct)
> - first: 20 (weird)
>
> Following calls to this method is setting those properties to:
> - rows: 10 (correct)
> - first: 10 (correct)
>
--
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, 2 months
[JBoss JIRA] (RF-11418) rich:tabPanel cuts off the tabs on the right
by Lucas Ventura Carro (JIRA)
[ https://issues.jboss.org/browse/RF-11418?page=com.atlassian.jira.plugin.s... ]
Lucas Ventura Carro commented on RF-11418:
------------------------------------------
I got it working with only this JS:
{code}
<h:outputScript library="javascript" target="head">
// <![CDATA[
jQuery(document).ready(function() {
jQuery("td.rf-tab-hdr-spcr").width("auto");
jQuery(".rf-tab-lbl").css("white-space", "normal");
});
// ]]>
</h:outputScript>
{code}
> rich:tabPanel cuts off the tabs on the right
> --------------------------------------------
>
> Key: RF-11418
> URL: https://issues.jboss.org/browse/RF-11418
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.0.0.Final
> Reporter: Val Blant
> Labels: tabPanel
> Fix For: 5-Tracking
>
> Attachments: tabs_cut_off.png, tabs_properly_wrapped.png
>
>
> Tabs are cut off on the right, if there are too many of them. Instead of starting to wrap on the white spaces and growing vertically, the _tabPanel_ simply cuts off the tabs that don't fit, as shown in the attached picture.
--
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, 2 months
[JBoss JIRA] (RF-13061) r:fileUpload stops working: "Request prolog cannot be read"
by Valiantsin Shukaila (JIRA)
[ https://issues.jboss.org/browse/RF-13061?page=com.atlassian.jira.plugin.s... ]
Valiantsin Shukaila commented on RF-13061:
------------------------------------------
WildFly should fix Richfaces issue? And it will start working on tomcat?
> r:fileUpload stops working: "Request prolog cannot be read"
> -----------------------------------------------------------
>
> Key: RF-13061
> URL: https://issues.jboss.org/browse/RF-13061
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juergen Zimmermann
>
> I just tried r:fileUpload with the current snapshot for WildFly 8.0.0.Alpha2 (changed Mojarra 2.2.0 to 2.1.23). It actually looks pretty good. However, I'm getting this stacktrace for fileUpload:
> {code}
> 16:33:44,571 SEVERE [org.richfaces.log.Application] Exception parsing multipart request: Request prolog cannot be read: org.richfaces.ui.input.fileUpload.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:75) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:56) [jsf-impl-2.1.23.jar:2.1.23]
> at java.util.Collections$UnmodifiableMap.get(Collections.java:1339) [rt.jar:1.7.0_21]
> at com.sun.faces.facelets.tag.ui.UIDebug.debugRequest(UIDebug.java:168) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash$PreviousNextFlashInfoManager.decode(ELFlash.java:1225) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.getCurrentFlashManager(ELFlash.java:1059) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.doPrePhaseActions(ELFlash.java:557) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:215) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.23.jar:2.1.23]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.23.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:127) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> ... 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, 2 months
[JBoss JIRA] (RF-11417) Tab: investigate why @action does not work
by Valiantsin Shukaila (JIRA)
[ https://issues.jboss.org/browse/RF-11417?page=com.atlassian.jira.plugin.s... ]
Valiantsin Shukaila commented on RF-11417:
------------------------------------------
Guys, I do not understand why you can not just make it working? I have made it working by changing the Richfaces code. I spent just half an hour for that.
If you guide me how I can contribute this changes to Richfaces I can do this. But this looks really wierd that it could not be solved for so much time because such finctionality in rich:tabPanel is really important.
> Tab: investigate why @action does not work
> ------------------------------------------
>
> Key: RF-11417
> URL: https://issues.jboss.org/browse/RF-11417
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.1.0.CR1
> Reporter: Lukáš Fryč
> Fix For: 5-Tracking
>
>
> Determine why rich:tab @action has not been implemented.
> Verify that its implementation can't affect current applications (and try to find possible workaround).
> Implement @action and @actionListener.
--
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, 2 months
[JBoss JIRA] (RF-12199) rich:tooltip does not work inside h:graphicImage
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-12199?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek commented on RF-12199:
----------------------------------
I can't reproduce the bug neither with 4.2.3 nor with 4.3.5.
Verified with:
* Metamer reproducer (http://localhost:8080/metamer/faces/components/richTooltip/rf-12199.xhtml).
* Firefox 27, IE 11, Chrome 33.
* EAP 6.2, Glassfish 3.1.2.2.
> rich:tooltip does not work inside h:graphicImage
> ------------------------------------------------
>
> Key: RF-12199
> URL: https://issues.jboss.org/browse/RF-12199
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.2.1.Final
> Environment: RF 4.2.1.Final, GF 3.1.1
> Reporter: Bernhard Thalmayr
> Assignee: Luca Nardelli
> Fix For: 4.2.2.Final
>
>
> I created a simple richfaces app using maven archetype 'richfaces-archetype-simpleapp'
> Nesting rich:tooltip within h:graphicImage does not work; used mark up
> {code}
> <h:graphicImage id="img1" name="projectavatar.png" library="images">
> <rich:tooltip>
> <span>tooltip1</span>
> </rich:tooltip>
> </h:graphicImage>
> {code}
> wrapping h:graphicImage within a4j:outputPanel is no workaround
> {code}
> <a4j:outputPanel>
> <h:graphicImage id="img2" name="projectavatar.png" library="images">
> <rich:tooltip>
> <span>tooltip2</span>
> </rich:tooltip>
> </h:graphicImage>
> </a4j:outputPanel>
> {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, 2 months