[JBoss JIRA] (RF-13499) Scale aggressiveness of the workaround for WildFly/Push interoperability back
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13499?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13499:
------------------------------------
It looks like UNDERTOW-171 has been marked as resolved. [~stuartdouglas] do you know when this fix will make it into WildFly (if it hasn't already)?
> Scale aggressiveness of the workaround for WildFly/Push interoperability back
> -----------------------------------------------------------------------------
>
> Key: RF-13499
> URL: https://issues.jboss.org/browse/RF-13499
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Fix For: 5.0.0.Alpha4
>
>
> In RF-13179 we have implemented a workaround by leveraging @WebFilter annotation. This may be potentially an interoperability issue on non-JBoss containers.
> I suggest to target WildFly support at the moment and scale the aggresiveness of the fix later once WildFly fixes the issue.
> Once ready, it's enough to remove annotations added in RF-13179
--
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, 8 months
[JBoss JIRA] (RF-13478) VDL documentation typos
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13478?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13478:
-------------------------------
Fix Version/s: 4.3.6
> VDL documentation typos
> -----------------------
>
> Key: RF-13478
> URL: https://issues.jboss.org/browse/RF-13478
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: doc
> Affects Versions: 4.3.3, 4.3.4
> Reporter: Vasil Lukach
> Priority: Trivial
> Fix For: 4.3.6
>
>
> RichFaces VDL documentation typos:
> 1) rich:fileUpload
> - uploadLabel attribute : Add -> Upload
> - execute attribute (proposal): remove "Some components make use of additional keywords"
> 2) a4j:mediaOutput
> element attribute: imj -> img
> 3) accordion: epand -> expand
--
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, 8 months
[JBoss JIRA] (RF-13444) r:fileUpload throws IOException "Request prolog cannot be read"
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13444?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13444:
------------------------------------
Thanks for the analysis. We will be addressing JSF 2.2 compatibility in our next Alpha release of RichFaces 5.
> 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
10 years, 8 months
[JBoss JIRA] (RF-13378) extendedDataTable not shown inside Bootstrap tab panel
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13378?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13378:
-------------------------------
Labels: extendedDataTable (was: )
> extendedDataTable not shown inside Bootstrap tab panel
> ------------------------------------------------------
>
> Key: RF-13378
> URL: https://issues.jboss.org/browse/RF-13378
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.4
> Environment: Tested on Ubuntu 12.04, Firefox 25, JDK 7u45, GlassFish 3.1.2.2
> Reporter: Salvo Isaja
> Labels: extendedDataTable
> Fix For: 5-Tracking
>
> Attachments: ExtendedDataTableTest.7z
>
>
> As described in RF-12682, when an extendedDataTable is placed in a parent which is not displayed by default, showing the parent causes the table to be invisible. This was reported to be solved on 4.3.2 for tables inside rich:tabPanel, while this issue is on 4.3.4 for tables inside a tab panel from Bootstrap 3.
> Attached a minimal project which demonstrates the issue.
> Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (RF-13378) extendedDataTable not shown inside Bootstrap tab panel
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13378?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13378:
-------------------------------
Fix Version/s: 5-Tracking
> extendedDataTable not shown inside Bootstrap tab panel
> ------------------------------------------------------
>
> Key: RF-13378
> URL: https://issues.jboss.org/browse/RF-13378
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.4
> Environment: Tested on Ubuntu 12.04, Firefox 25, JDK 7u45, GlassFish 3.1.2.2
> Reporter: Salvo Isaja
> Fix For: 5-Tracking
>
> Attachments: ExtendedDataTableTest.7z
>
>
> As described in RF-12682, when an extendedDataTable is placed in a parent which is not displayed by default, showing the parent causes the table to be invisible. This was reported to be solved on 4.3.2 for tables inside rich:tabPanel, while this issue is on 4.3.4 for tables inside a tab panel from Bootstrap 3.
> Attached a minimal project which demonstrates the issue.
> Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (RF-13317) ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13317?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13317:
------------------------------------
Could we instead inspect the JSF version server-side with a classpath scan looking for some class that is only present in JSF 2.2? A number of new classes were added to the spec, so this should be a robust (and cache-able) lookup.
> ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
> -----------------------------------------------------------------------------------------------
>
> Key: RF-13317
> URL: https://issues.jboss.org/browse/RF-13317
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Wildfly-8.0.0.Beta1, jsf-impl-2.2.3-jbossorg-1
> Reporter: Matti Bickel
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
>
> I'm using several {{<rich:autocomplete>}} fields in a {{<h:form>}}, but have noticed the issue with several other AJAX requests:
> When the response comes back, the data is fine but I get a JSF error saying
> bq. During update: javax.faces.ViewState not found
> Following that, no componentData is available to the Autocomplete component and no suggestions get displayed.
> For reference the [javadoc for ResponseStateManager.VIEW_STATE_PARAM|https://javaserverfaces.java.net/no...] says:
> {quote}
> Implementations must use this constant field value as the name of the client parameter in which to save the state between requests. The id attribute must be a concatenation of the return from UIComponent.getContainerClientId(javax.faces.context.FacesContext), the return from UINamingContainer.getSeparatorChar(javax.faces.context.FacesContext), this constant field value, the separator char, and a number that is guaranteed to be unique with respect to all the other instances of this kind of client parameter in the view.
> {quote}
--
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, 8 months
[JBoss JIRA] (RF-13495) Compilation error in RichFaces 4.5
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13495?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13495:
-------------------------------
Fix Version/s: 4.5.0.Alpha2
(was: 5.0.0.Alpha3)
> Compilation error in RichFaces 4.5
> ----------------------------------
>
> Key: RF-13495
> URL: https://issues.jboss.org/browse/RF-13495
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 4.5.0.Alpha1
> Environment: RichFaces 4.5.0-SNAPSHOT
> all environments (OS/JDK/Maven)
> Reporter: Pavol Pitonak
> Assignee: Lukáš Fryč
> Priority: Blocker
> Fix For: 4.5.0.Alpha2
>
>
> # git clone https://github.com/richfaces4/components.git
> # git checkout 4.5.x
> # mvn clean install
> result:
> {code}
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /mnt/hudson_workspace/workspace/richfaces-4.5-components/components/a4j/src/main/java/org/richfaces/renderkit/html/AjaxStatusRenderer.java:[166,16] error: encodeEnd(FacesContext,UIComponent) in AjaxStatusRenderer cannot override encodeEnd(FacesContext,UIComponent) in RendererBase
> [ERROR] /mnt/hudson_workspace/workspace/richfaces-4.5-components/components/a4j/src/main/java/org/richfaces/renderkit/html/AjaxOutputPanelRenderer.java:[55,16] error: encodeChildren(FacesContext,UIComponent) in AjaxOutputPanelRenderer cannot override encodeChildren(FacesContext,UIComponent) in RendererBase
> [INFO] 2 errors
> {code}
> * see also https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view/4.5/...
> * it seems to be cause by a change in 5.0, not 4.5
--
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, 8 months
[JBoss JIRA] (RF-12865) Correct deferred partial response ending by leveraging PVC wrapper chain
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-12865 at 1/20/14 9:07 PM:
-------------------------------------------------------------
We have addresses the concerns there and make the EPVC extend PartialViewContextWrapper and additionally we use PartialResponseWriterWrapper for rendering our extensions, which is library-compatibility friendly approiach.
On the other way, we haven't get rid of DIRECT/WRAPPER mode yet as mentioned here:
{quote}
--I recommend to get rid of `finallyEndDocument()` and perform the job in `endDocument()`. I also recommend to let your partial view context impl extend from javax.faces.context.PartialViewContextWrapper to keep RichFaces friendly towards other JSF libraries which also offer a PVC wrapper.-- This should also eliminate verbose/strange ContextMode.DIRECT/WRAPPED boilerplate. As to "encoding issues" which the class' javadoc is talking about, I'm not sure what exactly you mean there, but I believe that it has the same grounds as this PrimeFaces problem: http://stackoverflow.com/a/9839362/157882 If this is true, just don't do that and clearly document to the enduser that it's his responsibility to explicitly configure the webapp and/or the server to use UTF-8 as request parameter/body encoding, which is at most a matter of a servlet fitler with an oneliner. This way you do not need to introduce wrapper modes in your partial view context (at least, I did not see a clear reason why you are doing that, other than the comment on top of the class).
{quote}
This approach makes sure that when some library renders own components, their approach for PVC (or default JSF impl one) will be used, instead of the approach that RichFaces takes. This is silly, but our approach (rewriting processPartial() method) is required in order to support meta-component and AjaxOutput rendering as discussed in RF-13317.
was (Author: lfryc):
We have addresses the concerns there and make the EPVC extend PartialViewContextWrapper and additionally we use PartialResponseWriterWrapper for rendering our extensions, which is library-compatibility friendly approiach.
On the other way, we haven't get rid of DIRECT/WRAPPER mode yet as mentioned here:
{quote}
--I recommend to get rid of `finallyEndDocument()` and perform the job in `endDocument()`. I also recommend to let your partial view context impl extend from javax.faces.context.PartialViewContextWrapper to keep RichFaces friendly towards other JSF libraries which also offer a PVC wrapper.-- This should also eliminate verbose/strange ContextMode.DIRECT/WRAPPED boilerplate. As to "encoding issues" which the class' javadoc is talking about, I'm not sure what exactly you mean there, but I believe that it has the same grounds as this PrimeFaces problem: http://stackoverflow.com/a/9839362/157882 If this is true, just don't do that and clearly document to the enduser that it's his responsibility to explicitly configure the webapp and/or the server to use UTF-8 as request parameter/body encoding, which is at most a matter of a servlet fitler with an oneliner. This way you do not need to introduce wrapper modes in your partial view context (at least, I did not see a clear reason why you are doing that, other than the comment on top of the class).
{quote}
This approach makes sure that when some library renders own components, their approach for PVC (or default JSF impl one) will be used, instead of the approach that RichFaces takes. This is silly, but out approach (rewriting processPartial() method) is required in order to support meta-component and AjaxOutput rendering as discussed in RF-13317.
> Correct deferred partial response ending by leveraging PVC wrapper chain
> ------------------------------------------------------------------------
>
> Key: RF-12865
> URL: https://issues.jboss.org/browse/RF-12865
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: third-party
> Affects Versions: 4.3.1
> Environment: weblogic 10.3.4, Myfaces 2.1.10, Richfaces 4.3.1, OmniFaces1.3
> Reporter: blam lam
> Assignee: Lukáš Fryč
> Labels: jsf, needs-qe
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> After submit from a a4j:commandButton, it fail to re-render / update other component on the page.
> This problem only appear in MyFaces. It does not happens in Mojarra.
--
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, 8 months