[JBoss JIRA] (RF-13444) r:fileUpload throws IOException "Request prolog cannot be read"
by H G (JIRA)
[ https://issues.jboss.org/browse/RF-13444?page=com.atlassian.jira.plugin.s... ]
H G commented on RF-13444:
--------------------------
I have the same problem. RF 5 Aplha2, JSF 2.2.4, WF 8 CR1 (undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30)
> 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
> 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
12 years, 3 months
[JBoss JIRA] (RF-13480) Java package re-structure for the photoalbum demo
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13480?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13480:
-------------------------------
Summary: Java package re-structure for the photoalbum demo (was: Java Package re-structuring)
> Java package re-structure for the photoalbum demo
> -------------------------------------------------
>
> Key: RF-13480
> URL: https://issues.jboss.org/browse/RF-13480
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: examples
> Reporter: Brian Leathem
> Assignee: Michal Petrov
> Labels: photoalbum
> Fix For: 4.3.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> This issue addresses the cleanup of the java package namespace of the demo.
> 1) The package _org.richfaces.photoalbum.bean_ contains the single class _UserBean_. Let's rename the package to something less generic like _user_ or consider merging it into another pre-existing package like _ui_.
> 2) The _event_ package is separate from the _domain_ package. Let's consider moving the _event_ package to be a sub-package of _domain_. While we are at it, I find the package name _model_ to be more descriptive than _domain_.
> 3) The _services_ package may be better described as an _actions_ package.
> 4) The _util_ package is too generic. Consider creating _converters_ and _validators_ packages to hold the bulk of these classes. Additionally the classnames _*Stuff_ and _Utils_ could be named less generically.
> 5) having the two top-level classes _search_ and _ejbsearch_ is confusing. Can one package be a sub-folder of the other? Alternatively could one be in the _ui_ folder, or the other in a _model_ folder?
--
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
12 years, 3 months
[JBoss JIRA] (RF-13172) rich:toolbarGroup location="right" doesn't work if toolbarGroup location="left" contains not rendered values
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13172?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak closed RF-13172.
------------------------------
Verified in 4.3.5
> rich:toolbarGroup location="right" doesn't work if toolbarGroup location="left" contains not rendered values
> ------------------------------------------------------------------------------------------------------------
>
> Key: RF-13172
> URL: https://issues.jboss.org/browse/RF-13172
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.3
> Reporter: Sergey Zubarev
> Assignee: Pavel Slegr
> Labels: low_hanging_fruit
> Fix For: 4.3.5
>
>
> {code}
> <rich:toolbar itemSeparator="line" id="repairWorkToolbar">
> <rich:toolbarGroup>
> <a4j:commandLink value="btn1"/>
> <a4j:commandLink value="btn2"/>
> <a4j:commandLink value="btn3" *rendered="false"*/>
> </rich:toolbarGroup>
> <rich:toolbarGroup location="right">
> <a4j:commandLink value="btn_right"/>
> </rich:toolbarGroup>
> ...
> {code}
> In this case location="right" doesn't work : it displayed left. When I remove rendered="false" from btn3 all works fine.
> Html debug shows, that code produced one extra element in colgroup tag when using rendered="false".
--
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
12 years, 3 months
[JBoss JIRA] (RF-13172) rich:toolbarGroup location="right" doesn't work if toolbarGroup location="left" contains not rendered values
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13172?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13172:
-------------------------------
Labels: low_hanging_fruit (was: low_hanging_fruit needs-qe)
> rich:toolbarGroup location="right" doesn't work if toolbarGroup location="left" contains not rendered values
> ------------------------------------------------------------------------------------------------------------
>
> Key: RF-13172
> URL: https://issues.jboss.org/browse/RF-13172
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.3
> Reporter: Sergey Zubarev
> Assignee: Pavel Slegr
> Labels: low_hanging_fruit
> Fix For: 4.3.5
>
>
> {code}
> <rich:toolbar itemSeparator="line" id="repairWorkToolbar">
> <rich:toolbarGroup>
> <a4j:commandLink value="btn1"/>
> <a4j:commandLink value="btn2"/>
> <a4j:commandLink value="btn3" *rendered="false"*/>
> </rich:toolbarGroup>
> <rich:toolbarGroup location="right">
> <a4j:commandLink value="btn_right"/>
> </rich:toolbarGroup>
> ...
> {code}
> In this case location="right" doesn't work : it displayed left. When I remove rendered="false" from btn3 all works fine.
> Html debug shows, that code produced one extra element in colgroup tag when using rendered="false".
--
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
12 years, 3 months
[JBoss JIRA] (RF-13247) Upgrade the RichFaces guava dependency to version 15.0
by Moritz Hanke (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Moritz Hanke commented on RF-13247:
-----------------------------------
I have the same problem.
> Upgrade the RichFaces guava dependency to version 15.0
> ------------------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Brian Leathem
> Priority: Minor
> Fix For: 5-Tracking
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
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
12 years, 3 months
[JBoss JIRA] (RF-13247) Upgrade the RichFaces guava dependency to version 15.0
by Thorsten Richter (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Thorsten Richter commented on RF-13247:
---------------------------------------
This issue blocks us to test and use Wildfly.
> Upgrade the RichFaces guava dependency to version 15.0
> ------------------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Brian Leathem
> Priority: Minor
> Fix For: 5-Tracking
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
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
12 years, 3 months
[JBoss JIRA] (RF-13463) Photoalbum: improvements for adding images
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13463?page=com.atlassian.jira.plugin.s... ]
Michal Petrov resolved RF-13463.
--------------------------------
Resolution: Done
> Photoalbum: improvements for adding images
> ------------------------------------------
>
> Key: RF-13463
> URL: https://issues.jboss.org/browse/RF-13463
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: examples
> Affects Versions: 4.3.4
> Reporter: Jiří Štefek
> Assignee: Michal Petrov
> Priority: Trivial
> Fix For: 4.3.5
>
>
> On the 'add images' page/view:
> * there is a r:select where you can specify to which album the images will be uploaded, but you have to blur the input after such selection to reset the previously uploaded data, it would be more comfortable if it is done immediately after the selection
> * when you upload some images there is a message on the bottom saying "Successfully downloaded images:", shouldn't there be 'uploaded' ?
> * the upload result should be reset after page/view revisit. Now you can upload image, then e.g. browse to that uploaded image and return back to 'add images' view and the state of previous upload is still there.
> * there should be a message, when trying to add an unacceptable type of image (others than jpg)
--
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
12 years, 3 months
[JBoss JIRA] (RF-13481) Upgrade to Warp 1.0.0.Alpha6
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13481?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13481:
---------------------------------
Warp was upgrade to 1.0.0.Beta1-SNAPSHOT (latest snapshot for Alpha6 development).
> Upgrade to Warp 1.0.0.Alpha6
> ----------------------------
>
> Key: RF-13481
> URL: https://issues.jboss.org/browse/RF-13481
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 5.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.Alpha3
>
>
> It seems Warp Alpha6 doesn't suffer from intermittent test issues as much as Alpha5 did (or it can recover).
> My impression comes from running whole test suite without getting stuck on EAP 6.1 and WildFly CR1.
> I will bump to snapshot and we will release as necessary.
--
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
12 years, 3 months