[JBoss JIRA] (RF-12978) collapsibleSubTable ignores rowClasses
by Edward I (JIRA)
[ https://issues.jboss.org/browse/RF-12978?page=com.atlassian.jira.plugin.s... ]
Edward I commented on RF-12978:
-------------------------------
Ok, I'd like to try that - some questions:
- Where do I put the h:outputStyleSheet - just before </html> or </h:body> or </f:view> or somewhere else?
- Can I put the <link ... /> tag there instead of using h:outputStyleSheet ?
- I thought <link> and <h:outputStyleSheet> had to be within the <head> tag - is that not that case?
Thanks for your help.
> collapsibleSubTable ignores rowClasses
> --------------------------------------
>
> Key: RF-12978
> URL: https://issues.jboss.org/browse/RF-12978
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.1
> Environment: Firefox 20.0, Linux
> Reporter: Edward I
> Labels: waiting_on_user
> Attachments: rf-12978.zip
>
>
> The rowClasses is ignored in the following:
> {code:xml}
> <rich:collapsibleSubTable value="#{item.items}" var="comp" rowClasses="oddRow, evenRow">
> {code}
> DataTable works correctly with the same rowClasses.
--
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-12349) Calendar component hidden behind rich:accordian component
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12349?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12349:
-------------------------------
Component/s: component-panels-layout-themes
(was: component-input)
> Calendar component hidden behind rich:accordian component
> ---------------------------------------------------------
>
> Key: RF-12349
> URL: https://issues.jboss.org/browse/RF-12349
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.2.2.Final, 5.0.0.Alpha1
> Environment: OS:- Windows XP, Fedora
> JDK:-JDK 1.6.0_20, JDK 7
> browsers: Chrome, Firefox
> Reporter: Nikhil Hukkerikar
> Fix For: 5-Tracking
>
>
> The calendar component <rich:calendar> is hidden behind the <rich:accordionitem>, wherein the calendar component is included inside one of the accordion Items of the <rich:accordion> component.
--
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-12349) Calendar component hidden behind rich:accordian component
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12349?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12349:
------------------------------------
Nice job with the investigations [~jhuska]! And thanks for providing the workaround.
> Calendar component hidden behind rich:accordian component
> ---------------------------------------------------------
>
> Key: RF-12349
> URL: https://issues.jboss.org/browse/RF-12349
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.2.2.Final, 5.0.0.Alpha1
> Environment: OS:- Windows XP, Fedora
> JDK:-JDK 1.6.0_20, JDK 7
> browsers: Chrome, Firefox
> Reporter: Nikhil Hukkerikar
> Fix For: 5-Tracking
>
>
> The calendar component <rich:calendar> is hidden behind the <rich:accordionitem>, wherein the calendar component is included inside one of the accordion Items of the <rich:accordion> component.
--
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-12978) collapsibleSubTable ignores rowClasses
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12978?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12978:
------------------------------------
Thanks for the investigation [~jstefek].
To get the User defined styles to show up last in the html head, you have to put your _h:outputStyleSheet_ at the end of your facelet file, after all component references have been made. This is typically done by placing your stylesheet at the bottom of your facelet template file.
The reason for this comes from the JSF 2 resource loading mechanism, it includes files in the _head_ as they are referenced in rendering the component tree. So to include yours last, you need to make sure it's referenced last.
> collapsibleSubTable ignores rowClasses
> --------------------------------------
>
> Key: RF-12978
> URL: https://issues.jboss.org/browse/RF-12978
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.1
> Environment: Firefox 20.0, Linux
> Reporter: Edward I
> Assignee: Brian Leathem
> Attachments: rf-12978.zip
>
>
> The rowClasses is ignored in the following:
> {code:xml}
> <rich:collapsibleSubTable value="#{item.items}" var="comp" rowClasses="oddRow, evenRow">
> {code}
> DataTable works correctly with the same rowClasses.
--
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-12978) collapsibleSubTable ignores rowClasses
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12978?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12978:
-------------------------------
Labels: waiting_on_user (was: )
> collapsibleSubTable ignores rowClasses
> --------------------------------------
>
> Key: RF-12978
> URL: https://issues.jboss.org/browse/RF-12978
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.1
> Environment: Firefox 20.0, Linux
> Reporter: Edward I
> Assignee: Brian Leathem
> Labels: waiting_on_user
> Attachments: rf-12978.zip
>
>
> The rowClasses is ignored in the following:
> {code:xml}
> <rich:collapsibleSubTable value="#{item.items}" var="comp" rowClasses="oddRow, evenRow">
> {code}
> DataTable works correctly with the same rowClasses.
--
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-12916) a4j:push doesn't work in cluster and doesn't have an asynchronous way to notify all Topics (e.g. JMS)
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12916?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-12916 at 6/20/13 1:29 PM:
-------------------------------------------------------------
Hi Lukáš,
I created a project (already attached) to exemplify the scenario. Let me first say the configuration of the enviroment. I'm using EAP 6.1.0 (the customer tested something similar with 6.0.0). Below some commands and configurations:
#start command:
{code}
/usr/local/EAP-6.1.0/jboss-eap-6.1/bin/domain.sh -b 10.96.36.155 -Djboss.bind.address.management=10.96.36.155 -Djboss.bind.address.unsecure=10.96.36.155
{code}
domain.xml modifications:
{code}
<subsystem xmlns="urn:jboss:domain:messaging:1.3">
<hornetq-server>
<clustered>true</clustered>
<persistence-enabled>true</persistence-enabled>
<cluster-user>admin</cluster-user>
<cluster-password>admin1</cluster-password>
<journal-type>NIO</journal-type>
<journal-min-files>2</journal-min-files>
....
{code}
host.xml modifications:
{code}
<servers>
<server name="server1" group="ha_profile" auto-start="true">
<socket-bindings socket-binding-group="full-ha-sockets" port-offset="0"/>
</server>
<server name="server2" group="ha_profile" auto-start="true">
<socket-bindings socket-binding-group="full-ha-sockets" port-offset="100"/>
</server>
</servers>
...
{code}
#the application uses maven, so a simple mvn clean install will generate the WAR in the target folder
#after the deploy of the application the following URLs will be available (to test it, I would recommend using different browsers to simulate different concurrent users):
http://10.96.36.155:8180/jmswithrichfaces/MDBServlet
http://10.96.36.155:8180/jmswithrichfaces/ -> Open in two tabs
http://10.96.36.155:8080/jmswithrichfaces/MDBServlet
http://10.96.36.155:8080/jmswithrichfaces/ -> Open in two tabs
Expected:
A push made by the application would be propagated to all browser/users even in different servers due it is a distributed WAR. In a less technical overview, the server should communicate to all the clients browser.
Overview of the project:
MDBServlet send a JMS message that can will be consumed and will use the Richfaces's push API to call all the web clients connected (http://10.96.36.155:8180/jmswithrichfaces/). This would update the date of everyone.
Let me know if you need any help =)
Regards,
Luan
was (Author: luan.cestari):
Hi Lukáš,
I created a project (already attached) to exemplify the scenario. Let me first say the configuration of the enviroment. I'm using EAP 6.1.0 (the customer tested something similar with 6.0.0). Below some commands and configurations:
#start command:
/usr/local/EAP-6.1.0/jboss-eap-6.1/bin/domain.sh -b 10.96.36.155 -Djboss.bind.address.management=10.96.36.155 -Djboss.bind.address.unsecure=10.96.36.155
domain.xml modifications:
<subsystem xmlns="urn:jboss:domain:messaging:1.3">
<hornetq-server>
<clustered>true</clustered>
<persistence-enabled>true</persistence-enabled>
<cluster-user>admin</cluster-user>
<cluster-password>admin1</cluster-password>
<journal-type>NIO</journal-type>
<journal-min-files>2</journal-min-files>
....
host.xml modifications:
<servers>
<server name="server1" group="ha_profile" auto-start="true">
<socket-bindings socket-binding-group="full-ha-sockets" port-offset="0"/>
</server>
<server name="server2" group="ha_profile" auto-start="true">
<socket-bindings socket-binding-group="full-ha-sockets" port-offset="100"/>
</server>
</servers>
...
#the application uses maven, so a simple mvn clean install will generate the WAR in the target folder
#after the deploy of the application the following URLs will be available (to test it, I would recommend using different browsers to simulate different concurrent users):
http://10.96.36.155:8180/jmswithrichfaces/MDBServlet
http://10.96.36.155:8180/jmswithrichfaces/ -> Open in two tabs
http://10.96.36.155:8080/jmswithrichfaces/MDBServlet
http://10.96.36.155:8080/jmswithrichfaces/ -> Open in two tabs
Expected:
A push made by the application would be propagated to all browser/users even in different servers due it is a distributed WAR. In a less technical overview, the server should communicate to all the clients browser.
Overview of the project:
MDBServlet send a JMS message that can will be consumed and will use the Richfaces's push API to call all the web clients connected (http://10.96.36.155:8180/jmswithrichfaces/). This would update the date of everyone.
Let me know if you need any help =)
Regards,
Luan
> a4j:push doesn't work in cluster and doesn't have an asynchronous way to notify all Topics (e.g. JMS)
> ------------------------------------------------------------------------------------------------------
>
> Key: RF-12916
> URL: https://issues.jboss.org/browse/RF-12916
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.0.Final
> Reporter: Luan Cestari
> Assignee: Lukáš Fryč
> Attachments: proj_jms_rich.zip
>
>
> The customer is using JBoss in cluster and he have a Richfaces 4. The web client is using websocket using Richfaces/Atmosphere. The problem is that the customer have heavy asynchronous process that need to notify all websockets from all users (using a JMS, for example)
--
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-13044) Inplace select: JS error inside extended data table
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13044?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13044:
-------------------------------
Assignee: (was: Pavol Pitonak)
> Inplace select: JS error inside extended data table
> ---------------------------------------------------
>
> Key: RF-13044
> URL: https://issues.jboss.org/browse/RF-13044
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input, component-tables
> Affects Versions: 4.3.2, 5.0.0.Alpha1
> Environment: RichFaces 5.0.0-SNAPSHOT
> Metamer 5.0.0-SNAPSHOT
> Mojarra 2.1.13
> EAP 6.0.1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 27.0.1453.93 @ Linux x86_64
> Reporter: Pavol Pitonak
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richInplaceSelect/csv.xhtm...
> # open browser console
> # click "set wrong value" button next to "custom" inplace input
> result:
> * value "rich faces" is set as expected but it is not submitted like in used case without EDT and inplace select stays open
> * works fine in all other templates
> * browser console contains this error:
> {code}
> Uncaught TypeError: Cannot read property '0' of undefined extendedDataTable.js?ln=org.richfaces:706
> richfaces.ui.ExtendedDataTable.richfaces.BaseComponent.extendClass.selectRows extendedDataTable.js?ln=org.richfaces:706
> richfaces.ui.ExtendedDataTable.richfaces.BaseComponent.extendClass.selectionClickListener extendedDataTable.js?ln=org.richfaces:784
> proxy jquery.js:775
> jQuery.event.dispatch jquery.js:3058
> elemData.handle.eventHandle jquery.js:2676
> jQuery.event.trigger jquery.js:2941
> (anonymous function) jquery.js:3599
> jQuery.extend.each jquery.js:611
> jQuery.fn.jQuery.each jquery.js:241
> jQuery.fn.extend.trigger jquery.js:3598
> jQuery.fn.(anonymous function) jquery.js:3652
> setValue csv.xhtml?templates=richExtendedDataTable:338
> setWrongValues csv.xhtml?templates=richExtendedDataTable:323
> onclick csv.xhtml?templates=richExtendedDataTable:394
> {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-13044) Inplace select: JS error inside extended data table
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13044?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13044:
-------------------------------
Fix Version/s: 5-Tracking
> Inplace select: JS error inside extended data table
> ---------------------------------------------------
>
> Key: RF-13044
> URL: https://issues.jboss.org/browse/RF-13044
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input, component-tables
> Affects Versions: 4.3.2, 5.0.0.Alpha1
> Environment: RichFaces 5.0.0-SNAPSHOT
> Metamer 5.0.0-SNAPSHOT
> Mojarra 2.1.13
> EAP 6.0.1
> Java(TM) SE Runtime Environment 1.6.0_32-b05 @ Linux
> Chrome 27.0.1453.93 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 5-Tracking
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richInplaceSelect/csv.xhtm...
> # open browser console
> # click "set wrong value" button next to "custom" inplace input
> result:
> * value "rich faces" is set as expected but it is not submitted like in used case without EDT and inplace select stays open
> * works fine in all other templates
> * browser console contains this error:
> {code}
> Uncaught TypeError: Cannot read property '0' of undefined extendedDataTable.js?ln=org.richfaces:706
> richfaces.ui.ExtendedDataTable.richfaces.BaseComponent.extendClass.selectRows extendedDataTable.js?ln=org.richfaces:706
> richfaces.ui.ExtendedDataTable.richfaces.BaseComponent.extendClass.selectionClickListener extendedDataTable.js?ln=org.richfaces:784
> proxy jquery.js:775
> jQuery.event.dispatch jquery.js:3058
> elemData.handle.eventHandle jquery.js:2676
> jQuery.event.trigger jquery.js:2941
> (anonymous function) jquery.js:3599
> jQuery.extend.each jquery.js:611
> jQuery.fn.jQuery.each jquery.js:241
> jQuery.fn.extend.trigger jquery.js:3598
> jQuery.fn.(anonymous function) jquery.js:3652
> setValue csv.xhtml?templates=richExtendedDataTable:338
> setWrongValues csv.xhtml?templates=richExtendedDataTable:323
> onclick csv.xhtml?templates=richExtendedDataTable:394
> {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-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 updated RF-13061:
-------------------------------
Fix Version/s: 5.0.0.Alpha2
> 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
> Assignee: Stuart Douglas
> Fix For: 5.0.0.Alpha2
>
>
> 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, 11 months