[jira] [Created] (MYFACES-4692) Signature Test Failure for jakarta.faces.component.ActionSource
Volodymyr Siedlecki created MYFACES-4692:
Summary: Signature Test Failure for
jakarta.faces.component.ActionSource
Key: MYFACES-4692
URL: https://issues.apache.org/jira/browse/MYFACES-4692
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC3
Reporter: Volodymyr Siedlecki
TCK identified the following issue:
{color:#1d1c1d}Missing Methods ---
jakarta.faces.component.ActionSource: method public
jakarta.{color}{color:#1d1c1d}el{color}{color:#1d1c1d}.MethodExpression
jakarta.faces.component.ActionSource.getActionExpression()
jakarta.faces.component.ActionSource: method public void
jakarta.faces.component.ActionSource.setActionExpression(jakarta.{color}{color:#1d1c1d}el{color}{color:#1d1c1d}.MethodExpression)
Added Methods - jakarta.faces.component.ActionSource: method
public abstract
jakarta.{color}{color:#1d1c1d}el{color}{color:#1d1c1d}.MethodExpression
jakarta.faces.component.ActionSource.getActionExpression()
jakarta.faces.component.ActionSource: method public abstract void
jakarta.faces.component.ActionSource.setActionExpression(jakarta.{color}{color:#1d1c1d}el{color}{color:#1d1c1d}.MethodExpression){color}
MyFaces provides an abstract method, while the official API provides a default
implementation (which is not abstract).
To comply with TCK and the javadoc (since it explicitly states a default
implementation throws UnsupportedOperationException)
See:
[https://jakarta.ee/specifications/faces/4.1/apidocs/jakarta.faces/jakarta/faces/component/actionsource#setActionExpression(jakarta.el.MethodExpression)]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894280#comment-17894280
]
Volodymyr Siedlecki commented on MYFACES-4671:
--
5.0 (main): [https://github.com/apache/myfaces/pull/721]
4.1: [https://github.com/apache/myfaces/pull/723]
4.0: [https://github.com/apache/myfaces/pull/722]
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4675) Faces #1936: resetValues() visit clientIds if not EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894277#comment-17894277 ] Volodymyr Siedlecki commented on MYFACES-4675: -- Merged PRs: 4.0: [https://github.com/apache/myfaces/pull/734] 4.1: [https://github.com/apache/myfaces/pull/735] 5.0 (main) Commit: [https://github.com/apache/myfaces/commit/ceb6509cadbb35e5d6bdb2c5d7a25266a15f7b6e] > Faces #1936: resetValues() visit clientIds if not EditableValueHolder > - > > Key: MYFACES-4675 > URL: https://issues.apache.org/jira/browse/MYFACES-4675 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.2, 4.1.0-RC2 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > See Faces issue: https://github.com/jakartaee/faces/issues/1936 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4673) Quarkus: Update to 3.8 LTS
[
https://issues.apache.org/jira/browse/MYFACES-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894275#comment-17894275
]
Volodymyr Siedlecki edited comment on MYFACES-4673 at 10/30/24 3:59 PM:
Pull Requests:
h3. [{_}MYFACES{_}-{_}4673{_}: 4.1 Quarkus 3.8
LTS|https://github.com/apache/myfaces/pull/727]
[MYFACES-4673: 4.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/726]
[MYFACES-4673: 5.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/725]
h3.
was (Author: volosied):
Pull Requests:
[
MYFACES-4673: 4.1 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/727]
[MYFACES-4673: 4.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/726]
[MYFACES-4673: 5.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/725]
h3.
> Quarkus: Update to 3.8 LTS
> --
>
> Key: MYFACES-4673
> URL: https://issues.apache.org/jira/browse/MYFACES-4673
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC2
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
>
> Update to the Quarkus LTS 3.8.5 and change the dev card name to Apache
> MyFaces.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4673) Quarkus: Update to 3.8 LTS
[ https://issues.apache.org/jira/browse/MYFACES-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894275#comment-17894275 ] Volodymyr Siedlecki commented on MYFACES-4673: -- Pull Requests: [ MYFACES-4673: 4.1 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/727] [MYFACES-4673: 4.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/726] [MYFACES-4673: 5.0 Quarkus 3.8 LTS|https://github.com/apache/myfaces/pull/725] h3. > Quarkus: Update to 3.8 LTS > -- > > Key: MYFACES-4673 > URL: https://issues.apache.org/jira/browse/MYFACES-4673 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC2 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > Update to the Quarkus LTS 3.8.5 and change the dev card name to Apache > MyFaces. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4427) Cant open any pages in quarkus when using quarkus.package.type=uber-jar
[
https://issues.apache.org/jira/browse/MYFACES-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894274#comment-17894274
]
Volodymyr Siedlecki commented on MYFACES-4427:
--
Was this fixed for 2.3-next? I see it's an affected version.
> Cant open any pages in quarkus when using quarkus.package.type=uber-jar
> ---
>
> Key: MYFACES-4427
> URL: https://issues.apache.org/jira/browse/MYFACES-4427
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3-next-M6, 4.0.2, 4.1.0-RC2
> Environment: JDK17 and JDK11 with Quarkus 2.6.2.Final
>Reporter: Carlos Matos
>Assignee: Melloware
>Priority: Major
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
>
> When you package your quarkus jsf app using: mvn package and use
> quarkus.package.type=uber-jar, you can't open any pages inside the
> application, shows the following error:
> {code:java}
> 2022-01-21 20:10:37,884 ERROR [io.und.req.io] (executor-thread-0) Exception
> handling request a9490912-cc69-46bb-8af2-7cf23c0fcf5c-1 to /settings.xhtml:
> javax.servlet.ServletException
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:239)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:63)
> at
> io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:67)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:133)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:65)
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:247)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:56)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:111)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:108)
> at
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at
> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at
> io.quarkus.undertow.runtime.UndertowDeploymentRecorder$9$1.call(UndertowDeploymentRecorder.java:590)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:152)
> at
> io.quarkus.undertow.runtime.UndertowDeploymentRecorder$1.handleRequest(UndertowDeploymentRecorder.java:119)
> at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:290)
> at
> io.undertow.server.DefaultExchangeHandler.handle(DefaultExchangeHandler.java:18)
> at
> io.quarkus.undertow.runtime.UndertowDeploymentRecorder$5$1.run(UndertowDeploymentRecorder.java:412)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.uti
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894273#comment-17894273
]
Volodymyr Siedlecki commented on MYFACES-4676:
--
Reverted for 4.1.0-RC3, so I'll target RC4 instead.
PR: https://github.com/apache/myfaces/pull/772
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0, 4.1.0-RC2
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Trivial
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC4
>
> Attachments: Screenshot 2024-07-22 153633.png, test-faces22-ajax.war
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 153633.png|width=541,height=408!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4684) Quarkus: WebSockets not working
[
https://issues.apache.org/jira/browse/MYFACES-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894272#comment-17894272
]
Volodymyr Siedlecki commented on MYFACES-4684:
--
Safe to close out? Any follow up issues can be a new Jira issue?
> Quarkus: WebSockets not working
> ---
>
> Key: MYFACES-4684
> URL: https://issues.apache.org/jira/browse/MYFACES-4684
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 4.0.2, 4.1.0-RC2
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Attachments: image-2024-10-16-08-49-21-201.png,
> image-2024-10-16-13-37-32-161.png
>
>
> Using a WebSocket in Quarkus throws this
> {code:java}
> Suppressed: java.lang.NullPointerException: Cannot invoke
> "org.apache.myfaces.push.cdi.WebsocketScopeManager$AbstractScope.isChannelAvailable(String)"
> because the return value of
> "org.apache.myfaces.push.cdi.WebsocketScopeManager.getScope(String, boolean)"
> is null
> at
> org.apache.myfaces.push.WebsocketComponentRenderer.encodeEnd(WebsocketComponentRenderer.java:148)
> at
> jakarta.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:634)
> at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:523)
> at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519)
> at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519)
> at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1779)
> at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
> at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at
> jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:63)
> at
> io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:67)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:133)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:65)
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:247)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:111)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:108)
> at
> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at
> io.undertow.servlet.core.ContextClassLoaderSet
[jira] [Commented] (MYFACES-4683) Scripts executed in reverse order during ajax event
[ https://issues.apache.org/jira/browse/MYFACES-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894271#comment-17894271 ] Volodymyr Siedlecki commented on MYFACES-4683: -- Looks like this was fixed: [https://github.com/search?q=repo%3Aapache%2Fmyfaces+MYFACES-4683&type=pullrequests] I'll close it out for the 4.1.0-RC3 release notes. > Scripts executed in reverse order during ajax event > --- > > Key: MYFACES-4683 > URL: https://issues.apache.org/jira/browse/MYFACES-4683 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC2 > Environment: Windows, Chrome >Reporter: Jamie Goodfellow >Assignee: Werner Punz >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > When myfaces handles an ajax request, the script tags of the rendered xhtml > fragments are executed from last to first which is the opposite of what would > happen during a regular page load. I encountered this problem because one of > my components references another component in it's constructor and the > referenced component didn't exist yet during an ajax call because of reverse > execution. I found the problem code: > .sort((node1, node2) => node1.compareDocumentPosition(node2) - 3) // > preceding 2, following == 4) > The compareDocumentPosition method compares the node2 position relative to > node1's position. If node2 is preceding node1 then the sort return value > should be 1 but in this case it will be -1 as 2 (return of > compareDocumentPosition) minus 3 is -1. The correct code should be: > .sort((node1, node2) => node2.compareDocumentPosition(node1) - 3) // > preceding 2, following == 4) > Here is a jsfiddle - [JSFiddle - Code > Playground|https://jsfiddle.net/jc03vLt5/] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4654) Investigate Jakarta Schema Xsd Files Updates for 4.1
[ https://issues.apache.org/jira/browse/MYFACES-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894269#comment-17894269 ] Volodymyr Siedlecki commented on MYFACES-4654: -- I see a lot more final schema available now: [https://jakarta.ee/xml/ns/jakartaee/#11] Moving this to the next release > Investigate Jakarta Schema Xsd Files Updates for 4.1 > > > Key: MYFACES-4654 > URL: https://issues.apache.org/jira/browse/MYFACES-4654 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Major > Fix For: 4.1.0-RC3 > > > Not sure if we need any updates, but we should look into it. > [https://github.com/apache/myfaces/tree/4.1.x/impl/src/main/resources/org/apache/myfaces/resource] > > It doesn't look like any changes changed for 4.0 (maybe should have?) > I don't see any updates for EE11: > [https://jakarta.ee/xml/ns/jakartaee/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4685) TypeError: newBodyData is undefined
[
https://issues.apache.org/jira/browse/MYFACES-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893902#comment-17893902
]
Volodymyr Siedlecki commented on MYFACES-4685:
--
I think the issue may be this check? In Firefox, it's entered. On Safari, it's
not.
!image-2024-10-29-12-00-44-931.png!
> TypeError: newBodyData is undefined
> ---
>
> Key: MYFACES-4685
> URL: https://issues.apache.org/jira/browse/MYFACES-4685
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-10-29-11-53-59-387.png,
> image-2024-10-29-12-00-44-931.png, jsf_ajax_keyword_web.war,
> jsf_ajax_keyword_web.war.zip
>
>
>
> The variable newBodyData is undefined in the current JSF 2.3 snapshot. This
> is reproducible via the jsf_ajax_keyword_web.war (attached). Please set the
> project stage to development.
> The issue seems to be that the quirks/_AjaxResponseQuirks.js's _replaceBody
> method is used instead of the xhrCore/_AjaxResponse.js's code.
> Head data is pulled, and the passed into _replaceBody.
>
> {code:java}
> var parsedData = this._replaceHead(request, context, cDataBlock);
> ('undefined' != typeof parsedData && null != parsedData)
> ? this._replaceBody(request, context, cDataBlock, parsedData) :
> this._replaceBody(request, context, cDataBlock);
> {code}
>
> Then the head data is selected (3rd arg):
> {code:java}
> doc = (arguments.length > 3) ? arguments[3] : _Lang.parseXML(newData);{code}
> Then leads to the problem that no body element exists when it's extracted
> next, leaving it to be undefined:
> {code:java}
> var newBodyData = doc.getElementsByTagName("body")[0];{code}
> See stack trace here:
> {noformat}
> TypeError: newBodyData is undefined
> _replaceBody
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8803
>
> processUpdate
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8273
>
> processChanges
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8215
>
> processResponse
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7905
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10043
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10523
>
> onsuccess
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7447
>
> hitch
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
>
> mixMaps
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
>
> send
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7349
>
> enqueue
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6152
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4685) TypeError: newBodyData is undefined
[
https://issues.apache.org/jira/browse/MYFACES-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893901#comment-17893901
]
Volodymyr Siedlecki commented on MYFACES-4685:
--
[~werpu] I'm testing this on Firefox 131.0.3 (aarch64) with the 2.3.11
snapshot.
[http://localhost:9080/jsf_ajax_keyword_web/faces/ajaxAllKeyword1.xhtml]
!image-2024-10-29-11-53-59-387.png!
I can reproduce this fairly easily. Although, you're right that it doesn't
seem to happen on other browsers, such as Chrome?
> TypeError: newBodyData is undefined
> ---
>
> Key: MYFACES-4685
> URL: https://issues.apache.org/jira/browse/MYFACES-4685
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-10-29-11-53-59-387.png,
> jsf_ajax_keyword_web.war, jsf_ajax_keyword_web.war.zip
>
>
>
> The variable newBodyData is undefined in the current JSF 2.3 snapshot. This
> is reproducible via the jsf_ajax_keyword_web.war (attached). Please set the
> project stage to development.
> The issue seems to be that the quirks/_AjaxResponseQuirks.js's _replaceBody
> method is used instead of the xhrCore/_AjaxResponse.js's code.
> Head data is pulled, and the passed into _replaceBody.
>
> {code:java}
> var parsedData = this._replaceHead(request, context, cDataBlock);
> ('undefined' != typeof parsedData && null != parsedData)
> ? this._replaceBody(request, context, cDataBlock, parsedData) :
> this._replaceBody(request, context, cDataBlock);
> {code}
>
> Then the head data is selected (3rd arg):
> {code:java}
> doc = (arguments.length > 3) ? arguments[3] : _Lang.parseXML(newData);{code}
> Then leads to the problem that no body element exists when it's extracted
> next, leaving it to be undefined:
> {code:java}
> var newBodyData = doc.getElementsByTagName("body")[0];{code}
> See stack trace here:
> {noformat}
> TypeError: newBodyData is undefined
> _replaceBody
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8803
>
> processUpdate
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8273
>
> processChanges
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8215
>
> processResponse
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7905
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10043
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10523
>
> onsuccess
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7447
>
> hitch
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
>
> mixMaps
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
>
> send
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7349
>
> enqueue
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6152
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4686) ComponentNotFoundException for Included Facelets (MYFACES-4624 Regression)
Volodymyr Siedlecki created MYFACES-4686:
Summary: ComponentNotFoundException for Included Facelets
(MYFACES-4624 Regression)
Key: MYFACES-4686
URL: https://issues.apache.org/jira/browse/MYFACES-4686
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC2, 4.0.2, 2.3.11, 2.3-next-M9
Reporter: Volodymyr Siedlecki
There's a regression caused by
https://issues.apache.org/jira/browse/MYFACES-4624
If you reference a component from another page, it will also fail to be
resolved.
a.xhtml
{code:java}
...
...
{code}
b.xhtml
{code:java}
http://www.w3.org/1999/xhtml";
xmlns:h="jakarta.faces.html"
xmlns:ui="jakarta.faces.facelets">
Hello
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4624) SearchExpressions must fail when component in viewroot is not resolvable
[ https://issues.apache.org/jira/browse/MYFACES-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890550#comment-17890550 ] Volodymyr Siedlecki edited comment on MYFACES-4624 at 10/23/24 8:14 PM: I'll create a JIRA since I don't think the regression above was the intended effect? was (Author: volosied): I'll create a JIRA since I don't think the regression above was the indented effect? > SearchExpressions must fail when component in viewroot is not resolvable > > > Key: MYFACES-4624 > URL: https://issues.apache.org/jira/browse/MYFACES-4624 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1 > > > when using something like: > ``` > > > > > ``` > the result was that it was resolved to "j_id__v_0" instead of throwing a > ComponentNotFoundException > ":mainForm:input" would be the right expression -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4624) SearchExpressions must fail when component in viewroot is not resolvable
[ https://issues.apache.org/jira/browse/MYFACES-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890550#comment-17890550 ] Volodymyr Siedlecki commented on MYFACES-4624: -- I'll create a JIRA since I don't think the regression above was the indented effect? > SearchExpressions must fail when component in viewroot is not resolvable > > > Key: MYFACES-4624 > URL: https://issues.apache.org/jira/browse/MYFACES-4624 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1 > > > when using something like: > ``` > > > > > ``` > the result was that it was resolved to "j_id__v_0" instead of throwing a > ComponentNotFoundException > ":mainForm:input" would be the right expression -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890549#comment-17890549
]
Volodymyr Siedlecki edited comment on MYFACES-4680 at 10/17/24 7:27 PM:
Looks like the wrong page was requested. "pushed" is displayed for the other
tests, just not the viewscope case. Don't forget to add my java fix in (PR
748) to get a response back.
1) Visit spec1396UserScopedWebsocket to initialize the channel (poor app
design).
2) Go to [spec1396ViewScopedWebsocket.xhtml for the failing scenario
|https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
If you're still not able to, let me know. Thanks :)
was (Author: volosied):
Looks like the wrong page was requested. "pushed" is displayed for the other
tests, just not the viewscope case. Don't forget to add my java fix in (PR
748) to get a response back.
1) Visit spec1396UserScopedWebsocket to initialize the channel (poor app
design).
2) Go to [spec1396ViewScopedWebsocket.xhtml for the failing scenario
|https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: image-2024-10-17-21-20-41-622.png,
> image-2024-10-17-21-21-22-229.png, screenshot-1.png,
> test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890549#comment-17890549
]
Volodymyr Siedlecki edited comment on MYFACES-4680 at 10/17/24 7:25 PM:
Looks like the wrong page was requested. "pushed" is displayed for the other
tests, just not the viewscope case. Don't forget to add my java fix in (PR
748) to get a response back.
1) Visit spec1396UserScopedWebsocket to initialize the channel (poor app
design).
2) Go to [spec1396ViewScopedWebsocket.xhtml for the failing scenario
|https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
was (Author: volosied):
Looks like the wrong page was requested.
1) Visit spec1396UserScopedWebsocket to initialize the channel (poor app
design).
2) Go to [spec1396ViewScopedWebsocket.xhtml for the failing scenario
|https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: image-2024-10-17-21-20-41-622.png,
> image-2024-10-17-21-21-22-229.png, screenshot-1.png,
> test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890549#comment-17890549
]
Volodymyr Siedlecki commented on MYFACES-4680:
--
Looks like the wrong page was requested.
1) Visit spec1396UserScopedWebsocket to initialize the channel (poor app
design).
2) Go to [spec1396ViewScopedWebsocket.xhtml for the failing scenario
|https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: image-2024-10-17-21-20-41-622.png,
> image-2024-10-17-21-21-22-229.png, screenshot-1.png,
> test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4682) Error Message: newBodyData is undefined
[
https://issues.apache.org/jira/browse/MYFACES-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889829#comment-17889829
]
Volodymyr Siedlecki commented on MYFACES-4682:
--
Completely forgot I created this originally. Closing in favor of MYFACES-4685.
> Error Message: newBodyData is undefined
> ---
>
> Key: MYFACES-4682
> URL: https://issues.apache.org/jira/browse/MYFACES-4682
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.11, 3.0.3
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: jsf_ajax_keyword_web.war
>
>
> The EE8 TCK for JSF 2.3 is failing for the following tests:
> [com.sun.ts.tests.jsf.spec.ajax.keyword.URLClient|https://github.com/jakartaee/platform-tck/blob/8.0.x/src/com/sun/ts/tests/jsf/spec/ajax/keyword/URLClient.java]
> - ajaxAllKeywordTest
> - ajaxFormKeywordTest
> - ajaxNoneKeywordTest
> - ajaxThisKeywordTest
> They all seem to report the same exception in the JavaScript code:
> {code:java}
> Error Message: newBodyData is undefined
> Error Name: clientError
> Server error name: TypeError{code}
>
> {code:java}
> TypeError: newBodyData is undefined
> _replaceBody
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8799
> processUpdate
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8269
> processChanges
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8211
> processResponse
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7901
> response
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10039
> response
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10519
> onsuccess
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7443
> hitch
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
> mixMaps
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
> send
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7345
> enqueue
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6148
> xhrQueuedPost
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8897
> request
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:9688
> request
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10476
> anonymous
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development
> line 10178 > Function:3
> chain
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10178
> chain
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10542
> onclick
> http://localhost:9080/ajax-keyword-SNAPSHOT/faces/ajaxAllKeyword1.xhtml:1{code}
> I haven't tested 3.0.3, but I except the same issue. I will follow up to
> verify.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4624) SearchExpressions must fail when component in viewroot is not resolvable
[
https://issues.apache.org/jira/browse/MYFACES-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889824#comment-17889824
]
Volodymyr Siedlecki commented on MYFACES-4624:
--
[~tandraschko]
There's a regression caused by this change.
If you reference a component from another page, it will also fail to be
resolved.
a.xhtml
{color:#cc}...
...
{color}
b.xhtml
{color:#808080}<{color}{color:#569cd6}ui:composition{color}{color:#cc}
{color}{color:#9cdcfe}xmlns{color}{color:#cc}={color}{color:#ce9178}"http://www.w3.org/1999/xhtml"{color}
{color:#cc}
{color}{color:#9cdcfe}xmlns:h{color}{color:#cc}={color}{color:#ce9178}"jakarta.faces.html"{color}
{color:#cc}
{color}{color:#9cdcfe}xmlns:ui{color}{color:#cc}={color}{color:#ce9178}"jakarta.faces.facelets"{color}{color:#808080}>{color}
{color:#cc}
{color}{color:#808080}<{color}{color:#569cd6}h:form{color}{color:#cc}
{color}{color:#9cdcfe}id{color}{color:#cc}={color}{color:#ce9178}"test"{color}{color:#808080}>{color}
{color:#cc} Hello{color}
{color:#cc}
{color}{color:#808080}{color}
{color:#cc}
{color}{color:#808080}{color}
> SearchExpressions must fail when component in viewroot is not resolvable
>
>
> Key: MYFACES-4624
> URL: https://issues.apache.org/jira/browse/MYFACES-4624
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1
>
>
> when using something like:
> ```
>
>
>
>
> ```
> the result was that it was resolved to "j_id__v_0" instead of throwing a
> ComponentNotFoundException
> ":mainForm:input" would be the right expression
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4685) TypeError: newBodyData is undefined
[
https://issues.apache.org/jira/browse/MYFACES-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889754#comment-17889754
]
Volodymyr Siedlecki commented on MYFACES-4685:
--
Looks to be introduced via
https://github.com/apache/myfaces/pull/446/files#diff-fd7880979d061522d8f4e4b2aa55a2e45805a742224fe98229e454b80464c0a4R89
> TypeError: newBodyData is undefined
> ---
>
> Key: MYFACES-4685
> URL: https://issues.apache.org/jira/browse/MYFACES-4685
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.11
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: jsf_ajax_keyword_web.war
>
>
>
> The variable newBodyData is undefined in the current JSF 2.3 snapshot. This
> is reproducible via the jsf_ajax_keyword_web.war (attached). Please set the
> project stage to development.
> The issue seems to be that the quirks/_AjaxResponseQuirks.js's _replaceBody
> method is used instead of the xhrCore/_AjaxResponse.js's code.
> Head data is pulled, and the passed into _replaceBody.
>
> {code:java}
> var parsedData = this._replaceHead(request, context, cDataBlock);
> ('undefined' != typeof parsedData && null != parsedData)
> ? this._replaceBody(request, context, cDataBlock, parsedData) :
> this._replaceBody(request, context, cDataBlock);
> {code}
>
> Then the head data is selected (3rd arg):
> {code:java}
> doc = (arguments.length > 3) ? arguments[3] : _Lang.parseXML(newData);{code}
> Then leads to the problem that no body element exists when it's extracted
> next, leaving it to be undefined:
> {code:java}
> var newBodyData = doc.getElementsByTagName("body")[0];{code}
> See stack trace here:
> {noformat}
> TypeError: newBodyData is undefined
> _replaceBody
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8803
>
> processUpdate
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8273
>
> processChanges
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8215
>
> processResponse
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7905
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10043
>
> response
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10523
>
> onsuccess
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7447
>
> hitch
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
>
> mixMaps
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
>
> send
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7349
>
> enqueue
> http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6152
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4685) TypeError: newBodyData is undefined
Volodymyr Siedlecki created MYFACES-4685:
Summary: TypeError: newBodyData is undefined
Key: MYFACES-4685
URL: https://issues.apache.org/jira/browse/MYFACES-4685
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.3.11
Reporter: Volodymyr Siedlecki
Attachments: jsf_ajax_keyword_web.war
The variable newBodyData is undefined in the current JSF 2.3 snapshot. This is
reproducible via the jsf_ajax_keyword_web.war (attached). Please set the
project stage to development.
The issue seems to be that the quirks/_AjaxResponseQuirks.js's _replaceBody
method is used instead of the xhrCore/_AjaxResponse.js's code.
Head data is pulled, and the passed into _replaceBody.
{code:java}
var parsedData = this._replaceHead(request, context, cDataBlock);
('undefined' != typeof parsedData && null != parsedData) ?
this._replaceBody(request, context, cDataBlock, parsedData) :
this._replaceBody(request, context, cDataBlock);
{code}
Then the head data is selected (3rd arg):
{code:java}
doc = (arguments.length > 3) ? arguments[3] : _Lang.parseXML(newData);{code}
Then leads to the problem that no body element exists when it's extracted next,
leaving it to be undefined:
{code:java}
var newBodyData = doc.getElementsByTagName("body")[0];{code}
See stack trace here:
{code:java}
TypeError: newBodyData is undefined
_replaceBody
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8803
processUpdate
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8273
processChanges
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8215
processResponse
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7905
response
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10043
response
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10523
onsuccess
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7447
hitch
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
mixMaps
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
send
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7349
enqueue
http://localhost:9080/jsf_ajax_keyword_web/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6152
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Siedlecki resolved MYFACES-4666.
--
Assignee: Volodymyr Siedlecki
Resolution: Fixed
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Trivial
> Fix For: 5.0.0, 4.1.0-RC3
>
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4682) Error Message: newBodyData is undefined
Volodymyr Siedlecki created MYFACES-4682:
Summary: Error Message: newBodyData is undefined
Key: MYFACES-4682
URL: https://issues.apache.org/jira/browse/MYFACES-4682
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.3.11, 3.0.3
Reporter: Volodymyr Siedlecki
The EE8 TCK for JSF 2.3 is failing for the following tests:
com.sun.ts.tests.jsf.spec.ajax.keyword.URLClient
- ajaxAllKeywordTest
- ajaxFormKeywordTest
- ajaxNoneKeywordTest
- ajaxThisKeywordTest
They all seem to report the same exception in the JavaScript code:
{code:java}
Error Message: newBodyData is undefined
Error Name:
clientError Server error name: TypeError
Note, this message is
only sent, because project stage is development and no other error listeners
are registered.{code}
{code:java}
TypeError: newBodyData is undefined_replaceBody
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8799
processUpdate
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8269
processChanges
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8211
processResponse
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7901
response
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10039
response
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10519
onsuccess
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7443
hitch
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2408
mixMaps
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:2439
send
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:7345
enqueue
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:6148
xhrQueuedPost
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:8897
request
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:9688
request
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10476
anonymous
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development
line 10178 > Function:3chain
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10178
chain
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/javax.faces.resource/jsf.js?ln=javax.faces&stage=Development:10542
onclick
http://localhost:9080/ajax-keyword-SNAPSHOT/faces/ajaxAllKeyword1.xhtml:1 {code}
I haven't tested 3.0.3, but I except the same issue. I will follow up to verify.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881112#comment-17881112 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thank you! Looking forward to the PRs :) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4681) Faces 4.1 TCK Failure: headRenderPassthroughTest - Head ID Not Rendered
Volodymyr Siedlecki created MYFACES-4681:
Summary: Faces 4.1 TCK Failure: headRenderPassthroughTest - Head
ID Not Rendered
Key: MYFACES-4681
URL: https://issues.apache.org/jira/browse/MYFACES-4681
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC2
Reporter: Volodymyr Siedlecki
Test:
[https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/old-tck/source/src/com/sun/ts/tests/jsf/spec/render/head/URLClient.java#L85]
We fail to render the head id for this test even though it's specified in the
facelet.
App:
[https://github.com/jakartaee/faces/tree/fbaccab3da18ee26d40cd6f77d91de79ef1c7b15/tck/old-tck/source/src/web/jsf/spec/render/head|https://github.com/jakartaee/faces/blob/fbaccab3da18ee26d40cd6f77d91de79ef1c7b15/tck/old-tck/source/src/web/jsf/spec/render/head/passthroughtest_facelet.xhtml#L29]
Related Spec Issue: [https://github.com/jakartaee/faces/issues/1760]
As noted by BalcusC's comment, the output mode is controllable, not by the
doctype, but by the {{}} in {{faces-config.xml.}}
{{By default, the facelet processing is the HTML5 output. This means the
publicId and systemId should be null as there is no DTD. This is not the case
in our code, as we create with doctype using the declaration from the xhtml
page. }}
{{Doctype initialization: }}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/view/facelets/compiler/CompilationManager.java#L148]}}
{{This leads to the HTML5 check to fail when attempting to render the IDs in
the head and body elements.}}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/renderkit/html/HtmlHeadRenderer.java#L64-L67]}}
{{[https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/renderkit/html/util/HtmlRendererUtils.java#L1785-L1787]
}}
{{Please review in case anything looks incorrect. }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880376#comment-17880376
]
Volodymyr Siedlecki commented on MYFACES-4680:
--
Never mind – that was some other issue.
This PR gets us half way to fixing this TCK failure:
[https://github.com/apache/myfaces/pull/748] (it sends the websocket message,
and thus invokes the behavior function)
However, I get an JS exception stating that a form must exist.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880351#comment-17880351
]
Volodymyr Siedlecki commented on MYFACES-4680:
--
I'm missing something here – the {{behaviors}} callback should be for the web
socket, not the XHR request.
Let me do some more investigation into this.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> The app expects "pushed!" to display when the "push" button is pressed. It
> is not, and the test fails.
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered / called with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
> {code:java}
> faces.push.init('j_id_c','/test-faces23-websocket/jakarta.faces.push/view?76379b861759b95fa70c118d2e05d29f','view',function(){document.getElementById('opened').innerHTML='yes';},null,null,null,{renderAjaxOutput:[function(event){myfaces.ab('j_id_c',event,'renderAjaxOutput','','ajaxOutput')}]},true);{code}
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handles the one XHR for the button click. Neither do I see the
> onMessage invoked, which per the javadoc should trigger the behavior (
> "behavior param: Client behavior functions to be invoked when specific
> message is received.")?
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4680) 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
[
https://issues.apache.org/jira/browse/MYFACES-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879991#comment-17879991
]
Volodymyr Siedlecki edited comment on MYFACES-4680 at 9/7/24 1:46 AM:
--
This looks like a server side script generation issue – I will look into it see
what kind of fix I can provide.
https://github.com/apache/myfaces/blob/4.1.x/impl/src/main/java/org/apache/myfaces/push/WebsocketComponentRenderer.java#L237
was (Author: volosied):
This looks like a server side script generation issue – I will look into it see
what kind of fix I can provide.
> 4.1 TCK Failure: Spec1396IT#testViewScopedWebsocket
> ---
>
> Key: MYFACES-4680
> URL: https://issues.apache.org/jira/browse/MYFACES-4680
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.15, 2.3.10, 2.3-next-M8, 4.0.0, 4.1.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces23-websocket.war
>
>
> Ajax requests do not occur when they are registered a websocket tag, from
> what I could gather. It seems like the renderAjaxOutput behavior isn't
> registered with the faces.push.init script.
> MyFaces generated code (see behavior param (1) – second to last):
>
> Facelet:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/main/webapp/spec1396ViewScopedWebsocket.xhtml#L39]
> {code:java}
> onopen="function(){document.getElementById('opened').innerHTML='yes';}">
>
> {code}
> Link to Test:
> [https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces23/websocket/src/test/java/ee/jakarta/tck/faces/test/javaee8/websocket/Spec1396IT.java#L94]
> I test the same TCK app on Mojarra, and it sends out two XHR requests when
> the button is clicked. One for the button click and another for the
> renderAjaxOutput event.
> MyFaces only handle the XHR for the button click.
> Docs:
> [1)
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push|https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.push]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879878#comment-17879878 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Failures look to be caused but the new error handling changes. But this change is good to merge. Can you also create a PR for 2.2 / 2.3 (I would like a user of ours to test it out, too). Thank you > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879876#comment-17879876
]
Volodymyr Siedlecki commented on MYFACES-4676:
--
I think this is causing 3 new errors in the TCK: (linked the 4.1.0 TCK but I
tested 4.0 code)
{code:java}
Name: undefined Error: decode: A RuntimeException Has Occurred!{code}
http://localhost:9080/test-faces22-ajax/issue2179-page2.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue2179IT.java#L49
{code:java}
Error from undefined {code}
http://localhost:9080/test-faces22-ajax/ajaxScriptError.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue3473IT.java#L35
{code:java}
Error from undefined {code}
http://localhost:9080/test-faces22-ajax/exceptionDuringRender.xhtml
https://github.com/jakartaee/faces/blob/4.1.0-RELEASE/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue3171IT.java#L35
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0, 4.1.0-RC2
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Trivial
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Attachments: Screenshot 2024-07-22 153633.png, test-faces22-ajax.war
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 153633.png|width=541,height=408!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879362#comment-17879362
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
I added a draft PR here: [https://github.com/apache/myfaces/pull/747]
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878950#comment-17878950 ] Volodymyr Siedlecki commented on MYFACES-4679: -- I agree – 4606 is a bit messy and is over complicating things... :( > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878944#comment-17878944 ] Volodymyr Siedlecki commented on MYFACES-4679: -- To add some clarification for the example above since it uses checkboxes – I believe the previous checkbox regression with 4606 only applied if the checkbox was ajax-enabled – not the submit button in the form. >From what I remember, the name/value pair shouldn't be sent when the checkbox >is unchecked. However, the 745 proposed fix doesn't reach the checkbox / radio >handling within the appendIssuingItem method because the behavior event >attribute is found. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878589#comment-17878589
]
Volodymyr Siedlecki commented on MYFACES-4679:
--
BalusC responded: [https://www.eclipse.org/lists/faces-dev/msg00416.html]
{code:java}
The action event should only be queued when the action event is fired (which is
"click" in case of commandButton+ajax).{code}
He also created a issue in Mojarra here:
[https://github.com/eclipse-ee4j/mojarra/issues/5488]
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878588#comment-17878588
]
Volodymyr Siedlecki commented on MYFACES-4679:
--
I tested 4606 against your 745 (4.0) PR, but it doesn't send the client id as
part of the ajax request.
{code:java}
{code}
{code:java}
{code}
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877750#comment-17877750 ] Volodymyr Siedlecki commented on MYFACES-4679: -- You are correct about MyFaces - 2.3.10 doesn't invoke the action when blur occurs (only the listener), but 2.3.11 (with 4606) invokes both. I just tested Mojarra and found the following behaviors when the blur event is triggered: 2.2.20: - Only the ajaxEventBean.listener() is triggered 2.3.21: - Both ajaxEventBean.listener() and ajaxEventBean.confirm() are triggered Both: - Only 1 XHR request is sent - Issuing element is not attached I'm curious what changed in the RI to trigger the confirm action? > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877722#comment-17877722 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thanks again. Reverting would be a last resort. I created a pull request and I think my second commit might a potential solution. Otherwise, perhaps we need to open up a spec issue here? Would appreciate your feedback. Thanks as always! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877168#comment-17877168
]
Volodymyr Siedlecki commented on MYFACES-4676:
--
Thank you
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0, 4.1.0-RC2
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Trivial
> Fix For: 5.0.0, 4.0.3, 4.1.0-RC3
>
> Attachments: Screenshot 2024-07-22 153633.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 153633.png|width=541,height=408!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876741#comment-17876741 ] Volodymyr Siedlecki edited comment on MYFACES-4679 at 8/26/24 4:12 PM: --- Thanks – let me know what you find. As far as I can tell, I think 4606 may need to be reverted. Or perhaps the HtmlButtonRendererBase#decode method should be updated to handle ajax requests? The isSubmitted should only be true for click events in ajax requests? Also, an easier way to test the behavior is to click on the input text box and press tab twice (once to focus and again to cause the blur event) was (Author: volosied): Thanks – let me know what you find. As far as I can tell, I think 4606 may need to be reverted. An easier way to test is to click on the input text box and press tab twice (once to focus and again to cause the blur event) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876751#comment-17876751 ] Volodymyr Siedlecki edited comment on MYFACES-4679 at 8/26/24 3:05 PM: --- [commandButton doc|https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/commandButton.html] If the value in the Map for the value of the "clientId" property of the component is not null, get the value of the "type" attribute, and convert it to lower case. If the result is equal to the String "reset" (without the quotes), return from decode(). Otherwise, create a javax.faces.event.ActionEvent around the component, and pass it to the queueEvent() method of the component, which must be an instance of UICommand. Wording isn't great, but spec looks to imply that we should create an ActionEvent if clientId of the component is in the param map. was (Author: volosied): [commandButton doc|https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/commandButton.html] If the value in the Map for the value of the "clientId" property of the component is not null, get the value of the "type" attribute, and convert it to lower case. If the result is equal to the String "reset" (without the quotes), return from decode(). Otherwise, create a javax.faces.event.ActionEvent around the component, and pass it to the queueEvent() method of the component, which must be an instance of UICommand. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876751#comment-17876751 ] Volodymyr Siedlecki edited comment on MYFACES-4679 at 8/26/24 3:05 PM: --- [commandButton doc|https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/commandButton.html] If the value in the Map for the value of the "clientId" property of the component is not null, get the value of the "type" attribute, and convert it to lower case. If the result is equal to the String "reset" (without the quotes), return from decode(). Otherwise, create a javax.faces.event.ActionEvent around the component, and pass it to the queueEvent() method of the component, which must be an instance of UICommand. Wording isn't great, but spec looks to imply that we should create an ActionEvent if clientId of the component is in the param map. I'll wait for your input. Thanks! was (Author: volosied): [commandButton doc|https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/commandButton.html] If the value in the Map for the value of the "clientId" property of the component is not null, get the value of the "type" attribute, and convert it to lower case. If the result is equal to the String "reset" (without the quotes), return from decode(). Otherwise, create a javax.faces.event.ActionEvent around the component, and pass it to the queueEvent() method of the component, which must be an instance of UICommand. Wording isn't great, but spec looks to imply that we should create an ActionEvent if clientId of the component is in the param map. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876751#comment-17876751 ] Volodymyr Siedlecki commented on MYFACES-4679: -- [commandButton doc|https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/commandButton.html] If the value in the Map for the value of the "clientId" property of the component is not null, get the value of the "type" attribute, and convert it to lower case. If the result is equal to the String "reset" (without the quotes), return from decode(). Otherwise, create a javax.faces.event.ActionEvent around the component, and pass it to the queueEvent() method of the component, which must be an instance of UICommand. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876741#comment-17876741 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thanks – let me know what you find. As far as I can tell, I think 4606 may need to be reverted. An easier way to test is to click on the input text box and press tab twice (once to focus and again to cause the blur event) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876699#comment-17876699 ] Volodymyr Siedlecki commented on MYFACES-4679: -- Thank you so much! > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app (note that ajax tags have a blur > event). > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > In summary: > Before 4606: > Button 1: > nothing called > Button 2: > listener called > With 4606: > Button 1: > confirm called > Button 2: > listener called > confirm called > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876351#comment-17876351 ] Volodymyr Siedlecki commented on MYFACES-4679: -- I think when you click the button - both the XHR (ajax) and the post occur – which explain the 1 listener and 2 confirm calls. 1) confirm - POST 2) listener - XHR 3) confirm -XHR (due to the isSubmitted caused by 4606) > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app. > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876349#comment-17876349 ] Volodymyr Siedlecki commented on MYFACES-4679: -- For my last note ( multiple invocations for the listener / confirm). Here's an example for 1 button press: [8/23/24, 15:08:34:901 EDT] 004b SystemOut O confirm() was called [8/23/24, 15:08:34:908 EDT] 0029 SystemOut O listener() was called [8/23/24, 15:08:34:909 EDT] 0029 SystemOut O confirm() was called > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app. > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876349#comment-17876349 ] Volodymyr Siedlecki edited comment on MYFACES-4679 at 8/23/24 7:10 PM: --- For my last note ( multiple invocations for the listener / confirm). Here's an example for 1 button press. It does not happen consistently for some odd reason. [8/23/24, 15:08:34:901 EDT] 004b SystemOut O confirm() was called [8/23/24, 15:08:34:908 EDT] 0029 SystemOut O listener() was called [8/23/24, 15:08:34:909 EDT] 0029 SystemOut O confirm() was called was (Author: volosied): For my last note ( multiple invocations for the listener / confirm). Here's an example for 1 button press: [8/23/24, 15:08:34:901 EDT] 004b SystemOut O confirm() was called [8/23/24, 15:08:34:908 EDT] 0029 SystemOut O listener() was called [8/23/24, 15:08:34:909 EDT] 0029 SystemOut O confirm() was called > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app. > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[ https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876346#comment-17876346 ] Volodymyr Siedlecki commented on MYFACES-4679: -- [~werpu] I think I will need to rely on your help here again, if you could take a look at this. Thank you. > MYFACES-4606 Causes Multiple Events To Queue > > > Key: MYFACES-4679 > URL: https://issues.apache.org/jira/browse/MYFACES-4679 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: MYFACES-4679.zip > > > Easier to demonstrate via the attached app. > 1) Deploy application with MYFACES-4606 applied. > 2) Visit index.xhtml > 3) Click down on the first button (don't let go) > 4 Move the cursor elsewhere and then let the click go. > 5) Click anywhere on the page to trigger the blur event (unfocus the button). > 6) Repeat with the second button > With the second button, both the listener and confirm actions to occur. Even > though, the button wasn't actually clicked. > In my view, only the listener event should occur, not the confirm actions. > However, by adding the issuing element to the request, JSF thinks the button > was clicked after all. > The activate action check is here: > [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] > The "isSubmitted" method return true for paramMap.containsKey(clientId) which > is what the 4606 fix did (add the client id). > *This there a way to keep the older behavior for this scenario (pre-4606)?* > Additionally, I've seen the multiple invocations for the listener / confirm, > but I can't pin point the problem (could be some other button click > combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
Volodymyr Siedlecki created MYFACES-4679: Summary: MYFACES-4606 Causes Multiple Events To Queue Key: MYFACES-4679 URL: https://issues.apache.org/jira/browse/MYFACES-4679 Project: MyFaces Core Issue Type: Bug Reporter: Volodymyr Siedlecki Easier to demonstrate via the attached app. 1) Deploy application with MYFACES-4606 applied. 2) Visit index.xhtml 3) Click down on the first button (don't let go) 4 Move the cursor elsewhere and then let the click go. 5) Click anywhere on the page to trigger the blur event (unfocus the button). 6) Repeat with the second button With the second button, both the listener and confirm actions to occur. Even though, the button wasn't actually clicked. In my view, only the listener event should occur, not the confirm actions. However, by adding the issuing element to the request, JSF thinks the button was clicked after all. The activate action check is here: [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65] The "isSubmitted" method return true for paramMap.containsKey(clientId) which is what the 4606 fix did (add the client id). *This there a way to keep the older behavior for this scenario (pre-4606)?* Additionally, I've seen the multiple invocations for the listener / confirm, but I can't pin point the problem (could be some other button click combination). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875282#comment-17875282
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
[~tandraschko] This issue causes a TCK app failure for us, so we create a TCK
challenge here: [https://github.com/jakartaee/servlet/issues/691]
The test defines a nonexistent servlet, and this causes myfaces to throw the
ClassNotFoundException as it looks for faces servlet. There's some push back in
the challenge, so I hope to address it MyFaces.
I would like update implementation to catch the ClassNotFoundException and log
it was a warning. It would allow apps to continue to start up while still
notifying the developers of the CNFE. (it would avoid breaking any apps that
migrate to 4.1)
Thanks
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4676) Error Data Paylod Not Following Spec in Faces 4.0
[
https://issues.apache.org/jira/browse/MYFACES-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867859#comment-17867859
]
Volodymyr Siedlecki commented on MYFACES-4676:
--
Links below are where the error data object is created (from what I could
tell).
Looks like the 4.0 JavaScript impl code changed when it was refactored:
[https://github.com/apache/myfaces/blob/34c87d136076f512bcbea2560c6421a8b41fc05a/api/src/client/typescript/faces/impl/xhrCore/ResponseProcessor.ts#L164-L197]
Original:
[https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L568-L627]
> Error Data Paylod Not Following Spec in Faces 4.0
> -
>
> Key: MYFACES-4676
> URL: https://issues.apache.org/jira/browse/MYFACES-4676
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 4.0.0
>Reporter: Thomas Smith
>Priority: Trivial
> Attachments: Screenshot 2024-07-22 153633.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The [Error Data Payload (Table 16)|#a6973]] outlined in the spec isn't
> followed. As seen in the screenshot below something seems to be going wrong
> for responseText, responseCode, and status. Additionally, description and
> responseXML aren't included in the payload.
> !Screenshot 2024-07-22 153633.png|width=541,height=408!
> The response from the server still seems to be accurate:
> {code:java}
> encoding="UTF-8"?>org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException{code}
> The information seems to be lost somewhere in between the server response and
> error payload generation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860620#comment-17860620 ] Volodymyr Siedlecki commented on MYFACES-4672: -- It works for us. I"ll close out this issue. thank you again :) > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4672. -- Resolution: Fixed > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856958#comment-17856958 ] Volodymyr Siedlecki commented on MYFACES-4672: -- Thanks, the suggestion above looks to work well. I'll use it for now – one of our jsf-2.2 needs it. I look forward to your full analysis / fix :) Once again, I appreciate your quick help here. > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856875#comment-17856875
]
Volodymyr Siedlecki commented on MYFACES-4672:
--
Are you saying we should use use " if(targetBuf.has(identifier)) {" instead?
[https://github.com/Apache/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L63]
I'll leave it to you as this is out of my area at this point. Thank you again
for all your help here :)
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856856#comment-17856856
]
Volodymyr Siedlecki commented on MYFACES-4672:
--
For better reference this is the original fix I used which caused the form data
problems:
{{_MF_CLS(_PFX_XHR + "_MultipartAjaxRequestLevel2",
myfaces._impl.xhrCore._AjaxRequest, \{
getFormData: function() {
var A;
if (this._context._mfInternal.xhrOp === "multipartQueuedPost") {
A =
this._Lang.createFormDataDecorator(jsf.getViewState(this._sourceForm));
this._AJAXUTIL.appendIssuingItem(this._source, A);
} else \{
A = this._Lang.createFormDataDecorator(jsf.getViewState(new Array()))
this._AJAXUTIL.encodeSubmittableFields(A, this._sourceForm, null);
this._AJAXUTIL.appendIssuingItem(this._source, A);
}
return A;
},}}
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[
https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856855#comment-17856855
]
Volodymyr Siedlecki commented on MYFACES-4672:
--
Thanks!
I did tried adding the function, but it caused other errors in their
application. The XHR did not contain the form data in the request – it was
formatted differently.
When I decorated the form data object, the request had:
{color:#1d1c1d}j_id_a:j_id_d=[object File] j_id_a_SUBMIT=1
javax.faces.ViewState=etXhe99OOEwGmJMwtxyC6OvI0hBYMSNfhRFQFlnPdIp07mF2KWgN0fDLNVqbkvHTdDOAWQ==
javax.faces.behavior.event=change javax.faces.partial.event=change
javax.faces.source=j_id_a:j_id_d javax.faces.partial.ajax=true
javax.faces.partial.execute=j_id_a:j_id_d j_id_a=j_id_a{color}
It should look more like this:
{color:#cc}-10818876671980492753015449693{color}
{color:#cc}Content-Disposition: form-data{color}{color:#6a9955};
name="j_id_a:j_id_d"; filename="1.txt"{color}
{color:#cc}Content-Type: text/plain{color}
{color:#cc}1{color}
{color:#cc}-10818876671980492753015449693{color}
{color:#cc}Content-Disposition: form-data{color}{color:#6a9955};
name="j_id_a_SUBMIT"{color}
{color:#cc}1
{color}
> Uncaught TypeError: G.hasKey is not a function
> --
>
> Key: MYFACES-4672
> URL: https://issues.apache.org/jira/browse/MYFACES-4672
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.16
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> This affects 2.2 which I know is out of date, but I have a user of MyFaces
> 2.2 who needs this bug fixed.
> I ported MYFACES-4606 to 2.2 here:
> [https://github.com/apache/myfaces/pull/647]
> 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't
> realize that _AjaxRequestLevel2 was removed from 2.3 in this PR:
> [https://github.com/apache/myfaces/pull/415/files]
> _AjaxRequestLevel2 still exists in the 2.2 codebase.
> This mean that `if(targetBuf.hasKey(identifier))` was called from
> _AjaxRequestLevel2's getFormData which does not decorate the FormData to
> include the hasKey method – thus we get " G.hasKey is not a function".
> [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44]
> This error is reproducible via multi-part form requests that use ajax.
> What is the proper fix here? I'll create a draft PR for what I think is
> correct.
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
[ https://issues.apache.org/jira/browse/MYFACES-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856844#comment-17856844 ] Volodymyr Siedlecki commented on MYFACES-4672: -- https://github.com/apache/myfaces/pull/720 > Uncaught TypeError: G.hasKey is not a function > -- > > Key: MYFACES-4672 > URL: https://issues.apache.org/jira/browse/MYFACES-4672 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.16 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > This affects 2.2 which I know is out of date, but I have a user of MyFaces > 2.2 who needs this bug fixed. > I ported MYFACES-4606 to 2.2 here: > [https://github.com/apache/myfaces/pull/647] > 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't > realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: > [https://github.com/apache/myfaces/pull/415/files] > _AjaxRequestLevel2 still exists in the 2.2 codebase. > This mean that `if(targetBuf.hasKey(identifier))` was called from > _AjaxRequestLevel2's getFormData which does not decorate the FormData to > include the hasKey method – thus we get " G.hasKey is not a function". > [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] > This error is reproducible via multi-part form requests that use ajax. > What is the proper fix here? I'll create a draft PR for what I think is > correct. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4672) Uncaught TypeError: G.hasKey is not a function
Volodymyr Siedlecki created MYFACES-4672: Summary: Uncaught TypeError: G.hasKey is not a function Key: MYFACES-4672 URL: https://issues.apache.org/jira/browse/MYFACES-4672 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.15 Reporter: Volodymyr Siedlecki This affects 2.2 which I know is out of date, but I have a user of MyFaces 2.2 who needs this bug fixed. I ported MYFACES-4606 to 2.2 here: [https://github.com/apache/myfaces/pull/647] 4606 was applied to 2.3, so I applied the same fix to 2.2. However, I didn't realize that _AjaxRequestLevel2 was removed from 2.3 in this PR: [https://github.com/apache/myfaces/pull/415/files] _AjaxRequestLevel2 still exists in the 2.2 codebase. This mean that `if(targetBuf.hasKey(identifier))` was called from _AjaxRequestLevel2's getFormData which does not decorate the FormData to include the hasKey method – thus we get " G.hasKey is not a function". [https://github.com/volosied/myfaces/blob/d5d28a0e6cae3ea22e021c64ecf474d6352bf900/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxRequestLevel2.js#L32-L44] This error is reproducible via multi-part form requests that use ajax. What is the proper fix here? I'll create a draft PR for what I think is correct. Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4671) PushImpl.ts Socket#onerror attempting to use undefined variable
[
https://issues.apache.org/jira/browse/MYFACES-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856085#comment-17856085
]
Volodymyr Siedlecki commented on MYFACES-4671:
--
The change looks fine to me. I've assigned it to Werner, so that he could also
take a look. Thanks
> PushImpl.ts Socket#onerror attempting to use undefined variable
> ---
>
> Key: MYFACES-4671
> URL: https://issues.apache.org/jira/browse/MYFACES-4671
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2, 4.1.0-RC2
> Environment: OS: Windows 11
> Java version 17.0.7
>Reporter: Thomas Smith
>Assignee: Werner Punz
>Priority: Minor
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> While running some OpenLiberty FAT tests, specifically
> io.openliberty.org.apache.myfaces.4.0_fat/WebSocketTests, we discovered a
> small bug where JSON.parse(event.data) was running where event.data was
> undefined.
> Here is the line it occurs:
> [https://github.com/apache/myfaces/blob/dae36dde5cc42208d034dda23107ad79f68ecc3a/api/src/client/typescript/faces/impl/PushImpl.ts#L156]
> Volodymyr created a GitHub issue describing the issue here: [Faces 4.0 Fix
> WebSocketTests so that "onerror listener" occurs - Issue #27598 -
> OpenLiberty/open-liberty
> (github.com)|https://github.com/OpenLiberty/open-liberty/issues/27598]
> Proposed Solution: Change
> {code:java}
> JSON.parse(event.data) {code}
> to
> {code:java}
> JSON.parse(event.data === undefined ? null : event.data){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852458#comment-17852458
]
Volodymyr Siedlecki commented on MYFACES-4669:
--
There is a workaround thankfully. I hope Arjan might be able to comment in the
spec issue – it would be nice to have this behavior consistent.
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\";>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852172#comment-17852172
]
Volodymyr Siedlecki edited comment on MYFACES-4669 at 6/4/24 7:35 PM:
--
I reported a similar problem here:
[https://github.com/jakartaee/faces/issues/1796]
MyFaces will need to NOT escape the XML. I think this is a spec bug?
Code to set escape to false:
https://github.com/apache/myfaces/blob/1b8695232fdf601cad043e45be570da89a4e65b3/integration-tests/automaticExtensionlessMapping/src/main/java/org/apache/myfaces/core/integrationtests/ProgrammaticViewBean.java#L59C1-L62C34
was (Author: volosied):
I reported a similar problem here:
[https://github.com/jakartaee/faces/issues/1796]
MyFaces will need to escape the XML. I think this is a spec bug.
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\";>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4669) Programmatic Facelet Not Rendering Correctly
[
https://issues.apache.org/jira/browse/MYFACES-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852172#comment-17852172
]
Volodymyr Siedlecki commented on MYFACES-4669:
--
I reported a similar problem here:
[https://github.com/jakartaee/faces/issues/1796]
MyFaces will need to escape the XML. I think this is a spec bug.
> Programmatic Facelet Not Rendering Correctly
>
>
> Key: MYFACES-4669
> URL: https://issues.apache.org/jira/browse/MYFACES-4669
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2, 5.0.0, 4.1.0-RC3
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: image-2024-05-28-17-42-16-539.png,
> image-2024-05-28-17-43-37-052.png, programmatic_view.zip
>
>
> Attached is an example:
> Run
> {code:java}
> mvn clean jetty:run -Pmojarra40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders correctly.
> !image-2024-05-28-17-42-16-539.png!
>
> Run
> {code:java}
> mvn clean jetty:run -Pmyfaces40{code}
> and navigate to [http://localhost:8080/facelet.xhtml] you will see the
> programmatic view renders incorrectly with ESCAPED HTML tags. [~werpu] this
> looks like more double escaping for XML?
> !image-2024-05-28-17-43-37-052.png!
> {code:java}
> package org.apache.myfaces.core.extensions.quarkus.showcase.view;
> import jakarta.enterprise.context.ApplicationScoped;
> import jakarta.faces.annotation.View;
> import jakarta.faces.application.StateManager;
> import jakarta.faces.component.UIComponent;
> import jakarta.faces.component.UIOutput;
> import jakarta.faces.component.html.HtmlBody;
> import jakarta.faces.component.html.HtmlCommandButton;
> import jakarta.faces.component.html.HtmlForm;
> import jakarta.faces.component.html.HtmlOutputText;
> import jakarta.faces.context.FacesContext;
> import jakarta.faces.view.facelets.Facelet;
> @View("/facelet.xhtml")
> @ApplicationScoped
> public class FaceletView extends Facelet
> {
> @Override
> public void apply(FacesContext facesContext, UIComponent parent)
> {
> if
> (!facesContext.getAttributes().containsKey(StateManager.IS_BUILDING_INITIAL_STATE))
> {
> return;
> }
> var components = new ComponentBuilder(facesContext);
> var rootChildren = parent.getChildren();
> var doctype = new UIOutput();
> doctype.setValue("");
> rootChildren.add(doctype);
> var htmlTag = new UIOutput();
> htmlTag.setValue("http://www.w3.org/1999/xhtml\";>");
> rootChildren.add(htmlTag);
> HtmlBody body = components.create(HtmlBody.COMPONENT_TYPE);
> rootChildren.add(body);
> HtmlForm form = components.create(HtmlForm.COMPONENT_TYPE);
> form.setId("form");
> body.getChildren().add(form);
> HtmlOutputText message =
> components.create(HtmlOutputText.COMPONENT_TYPE);
> message.setId("message");
> HtmlCommandButton actionButton =
> components.create(HtmlCommandButton.COMPONENT_TYPE);
> actionButton.setId("button");
> actionButton.addActionListener(
> e -> message.setValue("Hello, World! Welcome to Faces 4.0 on
> Jakarta EE 10"));
> actionButton.setValue("Greet");
> form.getChildren().add(actionButton);
> parent.getChildren().add(message);
> htmlTag = new UIOutput();
> htmlTag.setValue("");
> rootChildren.add(htmlTag);
> }
> private static class ComponentBuilder
> {
> FacesContext facesContext;
> ComponentBuilder(FacesContext facesContext)
> {
> this.facesContext = facesContext;
> }
> @SuppressWarnings("unchecked")
> T create(String componentType)
> {
> try
> {
> return (T)
> facesContext.getApplication().createComponent(componentType);
> }
> catch (ClassCastException e)
> {
> throw new IllegalArgumentException("Component type " +
> componentType + " is not valid.", e);
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852156#comment-17852156
]
Volodymyr Siedlecki commented on MYFACES-4670:
--
Turns out this is fixed in the latest code. My changes didn't include
https://issues.apache.org/jira/browse/MYFACES-4658.
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Siedlecki resolved MYFACES-4670.
--
Resolution: Invalid
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852146#comment-17852146
]
Volodymyr Siedlecki edited comment on MYFACES-4670 at 6/4/24 6:24 PM:
--
Looks like the extra
form1:box true
is the problem?
Code:
https://github.com/apache/myfaces/blob/4.0.x/api/src/client/typescript/faces/impl/xhrCore/XhrRequest.ts#L419-L422
was (Author: volosied):
Looks like the extra
form1:box true
is the problem?
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852146#comment-17852146
]
Volodymyr Siedlecki edited comment on MYFACES-4670 at 6/4/24 6:24 PM:
--
Looks like the extra "form1:box true" is the problem?
Added here:
[https://github.com/apache/myfaces/blob/4.0.x/api/src/client/typescript/faces/impl/xhrCore/XhrRequest.ts#L419-L422]
was (Author: volosied):
Looks like the extra
form1:box true
is the problem?
Code:
https://github.com/apache/myfaces/blob/4.0.x/api/src/client/typescript/faces/impl/xhrCore/XhrRequest.ts#L419-L422
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852146#comment-17852146
]
Volodymyr Siedlecki commented on MYFACES-4670:
--
Looks like the extra
form1:box true
is the problem?
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0/2.3 look fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
[
https://issues.apache.org/jira/browse/MYFACES-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852144#comment-17852144
]
Volodymyr Siedlecki commented on MYFACES-4670:
--
[~werpu] Could you take a look?
> Cannot Uncheck CheckBox (MYFACES-4606 Regression)
> -
>
> Key: MYFACES-4670
> URL: https://issues.apache.org/jira/browse/MYFACES-4670
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: checkbox.war
>
>
> You cannot uncheck a checkbox after it is selected. App is attached. It
> looks like a regression from MYFACES-4606. MyFaces 3.0 looks fine and only
> 4.0 seems to be affected here.
> Form Data is found below:
> Working (3.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Second >>>
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1 "form1"{code}
> Failing (4.0):
> First Request
> {code:java}
> form1:box "true"
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"{code}
> Second >
> {code:java}
> form1_SUBMIT "1"
> jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
> jakarta.faces.behavior.event "change"
> jakarta.faces.partial.event "change"
> jakarta.faces.source "form1:box"
> jakarta.faces.partial.ajax "true"
> form1 "form1"
> jakarta.faces.partial.execute "form1:box"
> jakarta.faces.partial.render "form1:box"
> form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4670) Cannot Uncheck CheckBox (MYFACES-4606 Regression)
Volodymyr Siedlecki created MYFACES-4670:
Summary: Cannot Uncheck CheckBox (MYFACES-4606 Regression)
Key: MYFACES-4670
URL: https://issues.apache.org/jira/browse/MYFACES-4670
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Volodymyr Siedlecki
You cannot uncheck a checkbox after it is selected. App is attached. It looks
like a regression from MYFACES-4606. MyFaces 3.0 looks fine and only 4.0 seems
to be affected here.
Form Data is found below:
Working (3.0):
First Request
{code:java}
form1:box "true"
form1_SUBMIT "1"
jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
jakarta.faces.behavior.event "change"
jakarta.faces.partial.event "change"
jakarta.faces.source "form1:box"
jakarta.faces.partial.ajax "true"
jakarta.faces.partial.execute "form1:box"
jakarta.faces.partial.render "form1:box"
form1 "form1"{code}
Second >>>
{code:java}
form1_SUBMIT "1"
jakarta.faces.ViewState "ODcyODU5ZDg0NDRmZmZmMzAwMDAwMDAx"
jakarta.faces.behavior.event "change"
jakarta.faces.partial.event "change"
jakarta.faces.source "form1:box"
jakarta.faces.partial.ajax "true"
jakarta.faces.partial.execute "form1:box"
jakarta.faces.partial.render "form1:box"
form1 "form1"{code}
Failing (4.0):
First Request
{code:java}
form1:box "true"
form1_SUBMIT "1"
jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
jakarta.faces.behavior.event "change"
jakarta.faces.partial.event "change"
jakarta.faces.source "form1:box"
jakarta.faces.partial.ajax "true"
form1 "form1"
jakarta.faces.partial.execute "form1:box"
jakarta.faces.partial.render "form1:box"{code}
Second >
{code:java}
form1_SUBMIT "1"
jakarta.faces.ViewState "MDJmNTEzOWQ0NDFlZDVlYjAwMDAwMDAx"
jakarta.faces.behavior.event "change"
jakarta.faces.partial.event "change"
jakarta.faces.source "form1:box"
jakarta.faces.partial.ajax "true"
form1 "form1"
jakarta.faces.partial.execute "form1:box"
jakarta.faces.partial.render "form1:box"
form1:box "true"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4654) Investigate Jakarta Schema Xsd Files Updates for 4.1
[ https://issues.apache.org/jira/browse/MYFACES-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845038#comment-17845038 ] Volodymyr Siedlecki commented on MYFACES-4654: -- Looks like only bean.xml is final. This Jira may be pushed back into a further release. > Investigate Jakarta Schema Xsd Files Updates for 4.1 > > > Key: MYFACES-4654 > URL: https://issues.apache.org/jira/browse/MYFACES-4654 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Major > Fix For: 4.1.0-RC3 > > > Not sure if we need any updates, but we should look into it. > [https://github.com/apache/myfaces/tree/4.1.x/impl/src/main/resources/org/apache/myfaces/resource] > > It doesn't look like any changes changed for 4.0 (maybe should have?) > I don't see any updates for EE11: > [https://jakarta.ee/xml/ns/jakartaee/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4665) @BeforeDestroyed Not Implemented for 4.1
[ https://issues.apache.org/jira/browse/MYFACES-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4665. -- Resolution: Fixed > @BeforeDestroyed Not Implemented for 4.1 > > > Key: MYFACES-4665 > URL: https://issues.apache.org/jira/browse/MYFACES-4665 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC2 >Reporter: Volodymyr Siedlecki >Assignee: Volodymyr Siedlecki >Priority: Major > > @Initialized and @Destroyed were completed in MYFACES-4506 but not for > @BeforeDestroyed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844695#comment-17844695
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
This problem occurred in our OSGI environment with an absence of the web.xml
(servlet looks to be added dynamically), and we have a fix (add the class to
the thread context loader) .
But I agree – let's keep it in.
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844675#comment-17844675
]
Volodymyr Siedlecki edited comment on MYFACES-4666 at 5/8/24 2:33 PM:
--
[~tandraschko] We can leave it as is, but hoping you could provide some more
information?
was (Author: volosied):
[~tandraschko] We have leave it as is, but hoping you could provide some more
information?
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844675#comment-17844675
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
[~tandraschko] We have leave it as is, but hoping you could provide some more
information?
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
Volodymyr Siedlecki created MYFACES-4666:
Summary: ClassUtils.simpleClassForName Throws
ClassNotFoundException
Key: MYFACES-4666
URL: https://issues.apache.org/jira/browse/MYFACES-4666
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC1
Reporter: Volodymyr Siedlecki
We noticed a new exception in Faces 4.1:
{code:java}
jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
at
org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
at
org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
at
org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
at
org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
This did not occur in 4.0. It only introduced with this change:
[https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
true is now passed into simpleClassForName which throws the exception:
[https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
Was this intentional for any specific scenario? Is an exception appropriate
here? We didn't have this before, so I'm wondering if this is needed in 4.1?
Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4665) @BeforeDestroyed Not Implemented for 4.1
Volodymyr Siedlecki created MYFACES-4665: Summary: @BeforeDestroyed Not Implemented for 4.1 Key: MYFACES-4665 URL: https://issues.apache.org/jira/browse/MYFACES-4665 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC2 Reporter: Volodymyr Siedlecki @Initialized and @Destroyed were completed in MYFACES-4506 but not for @BeforeDestroyed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
[ https://issues.apache.org/jira/browse/MYFACES-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4664. -- Resolution: Fixed > Update Faces To Address 4.1 TCK Failures > > > Key: MYFACES-4664 > URL: https://issues.apache.org/jira/browse/MYFACES-4664 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Volodymyr Siedlecki >Priority: Major > > Creating a single Jira to cover the 3 issues below: > - Make the UUID Converter Implicit > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] > - Fix up rowStatePreserved in UIRepeat > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] > - Implement Spec 1760 > - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
[ https://issues.apache.org/jira/browse/MYFACES-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841344#comment-17841344 ] Volodymyr Siedlecki commented on MYFACES-4664: -- Spec 1760 in 4.1: [https://github.com/apache/myfaces/pull/708] rowStatePreserved in 4.1: [https://github.com/apache/myfaces/pull/701] UUID Converter Implicit in 4.1: https://github.com/apache/myfaces/pull/700 > Update Faces To Address 4.1 TCK Failures > > > Key: MYFACES-4664 > URL: https://issues.apache.org/jira/browse/MYFACES-4664 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Volodymyr Siedlecki >Priority: Major > > Creating a single Jira to cover the 3 issues below: > - Make the UUID Converter Implicit > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] > - Fix up rowStatePreserved in UIRepeat > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] > - Implement Spec 1760 > - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4662) Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to the Faces Servlet
[
https://issues.apache.org/jira/browse/MYFACES-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841343#comment-17841343
]
Volodymyr Siedlecki commented on MYFACES-4662:
--
5.0: https://github.com/apache/myfaces/pull/709
> Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to
> the Faces Servlet
>
>
> Key: MYFACES-4662
> URL: https://issues.apache.org/jira/browse/MYFACES-4662
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.0.0, 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> While investigating the 4.1 TCK tests, a 404 was returned for some pages in
> the headAndBodyRenderer app. Only the `*.xhtml` extensions worked even though
> the servlet mappings were listed:
> web.xml:
> {code:java}
>
> facesServlet
>
>
> facesServlet
> *.xhtml
> *.xhtmlAsXhtml
> *.xhtmlAsXml
> {code}
> Turns out that our FaceletViewDeclarationLanguageStrategy class looked if
> *.xhtml matched, and if not, then it looked at any mappings set via
> jakarta.faces.FACELETS_VIEW_MAPPINGS. This isn't set in the app. Ultimately,
> FaceletViewDeclarationLanguageStrategy#handlesView returns false and since no
> VDL is found, the page fails to load.
> [https://github.com/apache/myfaces/blob/7f6fefb4b05ccf5272e6907397954f7d4db8f4d2/impl/src/main/java/org/apache/myfaces/view/facelets/FaceletViewDeclarationLanguageStrategy.java#L62-L76
>
> |https://github.com/jakartaee/faces/tree/4.1/tck/faces41/headAndBodyRenderer/src/main/webapp]
> I think we should update the code to look at the servlet mappings, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
Volodymyr Siedlecki created MYFACES-4664: Summary: Update Faces To Address 4.1 TCK Failures Key: MYFACES-4664 URL: https://issues.apache.org/jira/browse/MYFACES-4664 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC1, 5.0.0 Reporter: Volodymyr Siedlecki Creating a single Jira to cover the 3 issues below: - Make the UUID Converter Implicit - [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] - Fix up rowStatePreserved in UIRepeat - [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] - Implement Spec 1760 - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4662) Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to the Faces Servlet
Volodymyr Siedlecki created MYFACES-4662:
Summary: Update FaceletViewDeclarationLanguageStrategy to look at
exact mappings to the Faces Servlet
Key: MYFACES-4662
URL: https://issues.apache.org/jira/browse/MYFACES-4662
Project: MyFaces Core
Issue Type: Improvement
Reporter: Volodymyr Siedlecki
While investigating the 4.1 TCK tests, a 404 was returned for some pages in the
headAndBodyRenderer app. Only the `*.xhtml` extensions worked even though the
servlet mappings were listed:
web.xml:
{code:java}
facesServlet
jakarta.faces.webapp.FacesServlet
facesServlet
*.xhtml
*.xhtmlAsXhtml
*.xhtmlAsXml
{code}
Turns out that our FaceletViewDeclarationLanguageStrategy class looked if
*.xhtml matched, and if not, then it looked at any mappings set via
jakarta.faces.FACELETS_VIEW_MAPPINGS. This isn't set in the app.
[https://github.com/apache/myfaces/blob/7f6fefb4b05ccf5272e6907397954f7d4db8f4d2/impl/src/main/java/org/apache/myfaces/view/facelets/FaceletViewDeclarationLanguageStrategy.java#L62-L76
|https://github.com/jakartaee/faces/tree/4.1/tck/faces41/headAndBodyRenderer/src/main/webapp]
I think we should update it to look at the servlet mappings, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4658) faces.util.chain behavior changed
Volodymyr Siedlecki created MYFACES-4658:
Summary: faces.util.chain behavior changed
Key: MYFACES-4658
URL: https://issues.apache.org/jira/browse/MYFACES-4658
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.0.2
Reporter: Volodymyr Siedlecki
Given the following generated HTML, an alert will occur. If you click OK, it
will perform an action on a backing bean. However, if you cancel, it should
not.
{code:java}
{code}
On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
Faces 4.0, however, pressing cancel *does* invoke the bean.
Faces 3.0:
jsf.util.chain snippet:
{noformat}
if (FUNC == typeof arguments[cnt]) {
ret = arguments[cnt].call(source, event);
} else {
//either a function or a string can be passed in case of a
string we have to wrap it into another function
ret = new Function("event", arguments[cnt]).call(source, event);
}
//now if one function returns false in between we stop the
execution of the cycle
//here, note we do a strong comparison here to avoid constructs
like 'false' or null triggering
if (ret === false /*undefined check implicitly done here by using a
strong compare*/) {
return false;
}
}{noformat}
Faces 4.0:
{noformat}
function chain(source, event, ...funcs) {
// we can use our lazy stream each functionality to run our chain here.
// by passing a boolean as return value into the onElem call
// we can stop early at the first false, just like the spec requests
let ret;
funcs.every(func => {
let returnVal = resolveAndExecute(source, event, func);
if (returnVal !== false) {
ret = returnVal;
}
return returnVal !== false;
});
return ret;
}{noformat}
It looks like conditions changed here? "ret === false" became "returnVal !==
false" ? If cancel is pressed, false is returned, which means the chain
function returns false in 3.0. In faces 4.0, ret is never set, so undefined is
returned.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833656#comment-17833656
]
Volodymyr Siedlecki commented on MYFACES-4658:
--
[~werpu] I'm not sure what the correct logic is here, so I'll assign this to
you.
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set, so undefined
> is returned.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4657) servletRegistration.getClassName() may be null and cause an NPE
Volodymyr Siedlecki created MYFACES-4657:
Summary: servletRegistration.getClassName() may be null and cause
an NPE
Key: MYFACES-4657
URL: https://issues.apache.org/jira/browse/MYFACES-4657
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC1
Reporter: Volodymyr Siedlecki
{color:#cc}Stack Dump =
{color}{color:#ce9178}java.lang.NullPointerException{color}{color:#cc}:
type is {color}{color:#569cd6}null{color}{color:#cc}.{color}
{color:#ce9178} at
org.apache.myfaces.core.api.shared.lang.Assert.notNull(Assert.java:35){color}
{color:#ce9178} at
org.apache.myfaces.util.lang.ClassUtils.classForName(ClassUtils.java:207){color}
{color:#ce9178} at
org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:258){color}
{color:#ce9178} at
org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177){color}
{color:#ce9178} at
org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:326){color}
{color:#ce9178} at
org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){color}
{color:#ce9178}Introduced via
[https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213]
Web.xml Snippet to reproduce:
test.jsp
/test.jsp
test.jsp
/test.jsp
There is no servlet class in this scenario, so the code tries to search for a
null class name. {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4654) Investigate Jakarta Schema Xsd Files Updates for 4.1
Volodymyr Siedlecki created MYFACES-4654: Summary: Investigate Jakarta Schema Xsd Files Updates for 4.1 Key: MYFACES-4654 URL: https://issues.apache.org/jira/browse/MYFACES-4654 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC1 Reporter: Volodymyr Siedlecki Not sure if we need any updates, but we should look into it. [https://github.com/apache/myfaces/tree/4.1.x/impl/src/main/resources/org/apache/myfaces/resource] It doesn't look like any changes changed for 4.0 (maybe should have?) I don't see any updates for EE11: [https://jakarta.ee/xml/ns/jakartaee/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4651) Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases
[ https://issues.apache.org/jira/browse/MYFACES-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822203#comment-17822203 ] Volodymyr Siedlecki commented on MYFACES-4651: -- 5.0 Commit: https://github.com/apache/myfaces/commit/0af66ca29c8982713b8b1b444eb0a0346cb1104d > Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases > -- > > Key: MYFACES-4651 > URL: https://issues.apache.org/jira/browse/MYFACES-4651 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Trivial > Fix For: 4.1.0-RC2 > > > Found in > [https://github.com/apache/myfaces/blob/4.1.x/api/src/main/java/jakarta/faces/application/ViewHandler.java] > facelets.BUFFER_SIZE > facelets.DECORATORS > facelets.LIBRARIES > facelets.REFRESH_PERIOD > facelets.SKIP_COMMENTS > > Jakarta Faces Spec issue: https://github.com/jakartaee/faces/issues/1828 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4651) Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases
[ https://issues.apache.org/jira/browse/MYFACES-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4651. -- Resolution: Fixed > Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases > -- > > Key: MYFACES-4651 > URL: https://issues.apache.org/jira/browse/MYFACES-4651 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Trivial > Fix For: 5.0.0, 4.1.0-RC2 > > > Found in > [https://github.com/apache/myfaces/blob/4.1.x/api/src/main/java/jakarta/faces/application/ViewHandler.java] > facelets.BUFFER_SIZE > facelets.DECORATORS > facelets.LIBRARIES > facelets.REFRESH_PERIOD > facelets.SKIP_COMMENTS > > Jakarta Faces Spec issue: https://github.com/jakartaee/faces/issues/1828 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4652) TLD Document Jar Empty
[ https://issues.apache.org/jira/browse/MYFACES-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820895#comment-17820895 ] Volodymyr Siedlecki commented on MYFACES-4652: -- I'm not sure if the information is the same or different between the two jars. If the same, we should stop generating the empty one. > TLD Document Jar Empty > -- > > Key: MYFACES-4652 > URL: https://issues.apache.org/jira/browse/MYFACES-4652 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Major > > We have two TLD jars generated: > - > [myfaces-impl-4.1.0-RC1-facelets-tlddoc.jar|https://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-impl/4.1.0-RC1/] > - > [myfaces-impl-4.1.0-RC1-tlddoc.jar|https://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-impl/4.1.0-RC1/] > > The first one contains the TLD information while the second one is empty? > !https://private-user-images.githubusercontent.com/5934310/307974997-6b77860a-f237-4782-bfeb-2ef96bb08cd4.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg5ODcyMTYsIm5iZiI6MTcwODk4NjkxNiwicGF0aCI6Ii81OTM0MzEwLzMwNzk3NDk5Ny02Yjc3ODYwYS1mMjM3LTQ3ODItYmZlYi0yZWY5NmJiMDhjZDQucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDIyNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAyMjZUMjIzNTE2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTRmNDljNTIzNWJjZTMyZDcyMTE0YmJiZWUyODQ5ZGNkOWQ4MGM3NjM3ZjY3ODM5NjdlZjFjNjlkZTFkN2YwMCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.dDdqvfTIn2PDQtHCY-cMbfW5YTE2YMYlHv6sYiuqhTU|width=1686! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4652) TLD Document Jar Empty
Volodymyr Siedlecki created MYFACES-4652: Summary: TLD Document Jar Empty Key: MYFACES-4652 URL: https://issues.apache.org/jira/browse/MYFACES-4652 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC1 Reporter: Volodymyr Siedlecki We have two TLD jars generated: - [myfaces-impl-4.1.0-RC1-facelets-tlddoc.jar|https://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-impl/4.1.0-RC1/] - [myfaces-impl-4.1.0-RC1-tlddoc.jar|https://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-impl/4.1.0-RC1/] The first one contains the TLD information while the second one is empty? !https://private-user-images.githubusercontent.com/5934310/307974997-6b77860a-f237-4782-bfeb-2ef96bb08cd4.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg5ODcyMTYsIm5iZiI6MTcwODk4NjkxNiwicGF0aCI6Ii81OTM0MzEwLzMwNzk3NDk5Ny02Yjc3ODYwYS1mMjM3LTQ3ODItYmZlYi0yZWY5NmJiMDhjZDQucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDIyNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAyMjZUMjIzNTE2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTRmNDljNTIzNWJjZTMyZDcyMTE0YmJiZWUyODQ5ZGNkOWQ4MGM3NjM3ZjY3ODM5NjdlZjFjNjlkZTFkN2YwMCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.dDdqvfTIn2PDQtHCY-cMbfW5YTE2YMYlHv6sYiuqhTU|width=1686! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4651) Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases
Volodymyr Siedlecki created MYFACES-4651: Summary: Faces 4.1: Spec 1828 - Remove facelets.* Context Parameter Aliases Key: MYFACES-4651 URL: https://issues.apache.org/jira/browse/MYFACES-4651 Project: MyFaces Core Issue Type: Bug Reporter: Volodymyr Siedlecki Found in [https://github.com/apache/myfaces/blob/4.1.x/api/src/main/java/jakarta/faces/application/ViewHandler.java] - facelets.BUFFER_SIZE - facelets.DECORATORS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4637) Support collection of records in PushContext#send
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810951#comment-17810951
]
Volodymyr Siedlecki commented on MYFACES-4637:
--
This fix is still open – only change I made was to update 4.1.0 to build with
Java 17.
I'll aim to have this fixed in the next release (4.1.0-RC2), likely.
> Support collection of records in PushContext#send
> --
>
> Key: MYFACES-4637
> URL: https://issues.apache.org/jira/browse/MYFACES-4637
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Fix For: 5.0.0
>
>
> Originally brought up via
> [https://github.com/OpenLiberty/open-liberty/issues/26854]
> PushContext#send(Object obj) does not support collections of Records (added
> in Java 14). Currently, empty JSON objects are returned. This problem occurs
> within Json encoding logic.
> [https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/push/Json.java#L80-L118]
> Json.encode will go through all the type checks linked above and since none
> of them match, the last one (encodeBean) will be chosen. However, this simply
> results in an empty JSON responses ( such as [ {}, {}, {} ]).
> Only work around I see for how is to call toString on the collection instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4631) DuplicateIdException via addComponentResource
[
https://issues.apache.org/jira/browse/MYFACES-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810947#comment-17810947
]
Volodymyr Siedlecki commented on MYFACES-4631:
--
If you have provide another app, I can try to debug it. However, I don't think
I can alone based on the info you provided.
We've had numerous issues and attempts to fix the JSTL-JSF integration, but
it's not perfect. You can read more here:
[https://myfaces.apache.org/#/coreConceptsJSTL]
I'll close this issue out, but feel free to make another with this new
scenario. Thanks!
> DuplicateIdException via addComponentResource
> -
>
> Key: MYFACES-4631
> URL: https://issues.apache.org/jira/browse/MYFACES-4631
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Fix For: 4.0.2, 4.1.0-RC1
>
>
> See Bug Report here:
> [https://github.com/primefaces-extensions/primefaces-extensions/issues/517]
>
> [https://github.com/omnifaces/omnifaces/wiki/Combine-hardcoded-PrimeFaces-resources-using-CombinedResourceHandler]
>
> See comment here for root cause:
> [https://github.com/primefaces-extensions/primefaces-extensions/issues/517#issuecomment-1688911766]
> {{{}I saw we had a id counter and it starts at 0 before the state is stored.
> So when the script is added, it's always using the same counter. [ See
> here.|https://github.com/apache/myfaces/blob/304099d4588383424df9105d5a751911c1c5301a/api/src/main/java/jakarta/faces/component/UIViewRoot.java#L493-L495]{}}}{{{}I
> think the main issue is that we aren't adding ids to the nested items here:
> [https://github.com/apache/myfaces/blob/304099d4588383424df9105d5a751911c1c5301a/api/src/main/java/jakarta/faces/component/UIViewRoot.java#L218-L224]{}}}
> {{We need to look at the children and also assign IDs. }}
> {{Only issue I see above is that I search only the immediate children and
> don't drill down any further. Otherwise, it seems to fix the duplicate id
> exception :)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4649) ViewScoped bean handling broken because of refactoring
[ https://issues.apache.org/jira/browse/MYFACES-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810944#comment-17810944 ] Volodymyr Siedlecki commented on MYFACES-4649: -- main (5.0.x) commit: https://github.com/apache/myfaces/commit/e26a7caff13cfc9a04682ec2ccd71eb670c5a59a > ViewScoped bean handling broken because of refactoring > -- > > Key: MYFACES-4649 > URL: https://issues.apache.org/jira/browse/MYFACES-4649 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 4.0.2, 4.1.0, 5.0.0 > > > i restored the 2.3.x behavior > this occured because of DeltaSpike putAll values from oldViewMap to > newViewMap on redirect via SecurityAwareViewHandler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4614) Print error message when action method not found
[
https://issues.apache.org/jira/browse/MYFACES-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810932#comment-17810932
]
Volodymyr Siedlecki commented on MYFACES-4614:
--
Commit for the fix:
https://github.com/apache/myfaces/commit/526e899575d003ef89bb4a1fd3fce7385d051149
> Print error message when action method not found
>
>
> Key: MYFACES-4614
> URL: https://issues.apache.org/jira/browse/MYFACES-4614
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0
>
> Attachments: MYFACES-4614.zip
>
>
> Given the following example (also attached), where the number of method
> parameters does not match and the method cannot be called, an exception
> should be thrown.
> XHTML:
> {code:java}
>
> action="#{testView.onClick}"/>
> {code}
> Java:
> {code:java}
> public void onClick(Object parameter) {
> System.out.println("Button clicked");
> } {code}
> MyFaces does not throw an exception, while Mojarra throws:
> {code:java}
> Juli 12, 2023 1:44:32 PM com.sun.faces.lifecycle.InvokeApplicationPhase
> execute
> WARNUNG: #{testView.onClick}: /test.xhtml @17,60
> action="#{testView.onClick}": Method not found: TestView(string=Welcome to
> PrimeFaces!!!, integer=null, decimal=null, localDateTime=null,
> list=[TestObject(id=8e4d3985-c2f7-47dc-a5de-7e51acc41ec1, name=Thriller,
> artist=Michael Jackson, released=1982),
> TestObject(id=93adce20-fadb-4e8a-b16b-72eb9d03ae0e, name=Back in Black,
> artist=AC/DC, released=1980),
> TestObject(id=93e267a0-d6f9-4303-a82b-51ef16f88b02, name=The Bodyguard,
> artist=Whitney Houston, released=1992),
> TestObject(id=29ebc993-d665-47ec-844f-c14a34dc0554, name=The Dark Side of the
> Moon, artist=Pink Floyd, released=1973)]).onClick()
> jakarta.faces.FacesException: #{testView.onClick}: /test.xhtml @17,60
> action="#{testView.onClick}": Method not found: TestView(string=Welcome to
> PrimeFaces!!!, integer=null, decimal=null, localDateTime=null,
> list=[TestObject(id=8e4d3985-c2f7-47dc-a5de-7e51acc41ec1, name=Thriller,
> artist=Michael Jackson, released=1982),
> TestObject(id=93adce20-fadb-4e8a-b16b-72eb9d03ae0e, name=Back in Black,
> artist=AC/DC, released=1980),
> TestObject(id=93e267a0-d6f9-4303-a82b-51ef16f88b02, name=The Bodyguard,
> artist=Whitney Houston, released=1992),
> TestObject(id=29ebc993-d665-47ec-844f-c14a34dc0554, name=The Dark Side of the
> Moon, artist=Pink Floyd, released=1973)]).onClick()
> at
> com.sun.faces.application.ActionListenerImpl.getNavigationOutcome(ActionListenerImpl.java:83)
> at
> com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:62)
> at
> org.primefaces.application.DialogActionListener.processAction(DialogActionListener.java:54)
> at jakarta.faces.component.UICommand.broadcast(UICommand.java:205)
> at jakarta.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:858)
> at
> jakarta.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1332)
> at
> com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:56)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:72)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:159)
> at
> jakarta.faces.webapp.FacesServlet.executeLifecyle(FacesServlet.java:691)
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:449)
> at
> org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1410)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764)
> at
> org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1665)
> at
> org.eclipse.jetty.websocket.servlet.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:170)
> at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
> at
> org
[jira] [Commented] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810076#comment-17810076 ] Volodymyr Siedlecki commented on MYFACES-4642: -- Removed the fixed version since no fixes were merged, but I'll keep this issue open > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Priority: Major > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4637) Support collection of records in PushContext#send
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808995#comment-17808995
]
Volodymyr Siedlecki commented on MYFACES-4637:
--
[~tandraschko] Since 4.1 is now part of EE11, I think we should backport this
change to 4.1.x ( and have 4.1 build with Java 17).
Expect a PR soon. I'll have this be included in the RC1.
> Support collection of records in PushContext#send
> --
>
> Key: MYFACES-4637
> URL: https://issues.apache.org/jira/browse/MYFACES-4637
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Volodymyr Siedlecki
>Assignee: Volodymyr Siedlecki
>Priority: Major
> Fix For: 5.0.0
>
>
> Originally brought up via
> [https://github.com/OpenLiberty/open-liberty/issues/26854]
> PushContext#send(Object obj) does not support collections of Records (added
> in Java 14). Currently, empty JSON objects are returned. This problem occurs
> within Json encoding logic.
> [https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/push/Json.java#L80-L118]
> Json.encode will go through all the type checks linked above and since none
> of them match, the last one (encodeBean) will be chosen. However, this simply
> results in an empty JSON responses ( such as [ {}, {}, {} ]).
> Only work around I see for how is to call toString on the collection instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4623) DuplicateIdException when adding component with resource in JSTL tag handler
[
https://issues.apache.org/jira/browse/MYFACES-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803096#comment-17803096
]
Volodymyr Siedlecki commented on MYFACES-4623:
--
You're right. I reverted 4.0 change without merging the updated fix back in.
I'll get a PR up soon. Thanks for spotting it.
> DuplicateIdException when adding component with resource in JSTL tag handler
>
>
> Key: MYFACES-4623
> URL: https://issues.apache.org/jira/browse/MYFACES-4623
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Fix For: 4.1.0, 5.0.0
>
>
> The following error occurs when a JSF component adding a resource is added in
> a JSTL tag handler:
> {code:java}
> org.apache.myfaces.view.facelets.compiler.DuplicateIdException: Component
> with duplicate id "j_id__rd_5" found. The first component is {Component-Path
> : [Class: jakarta.faces.component.UIViewRoot,ViewId: /test.xhtml][Class:
> org.apache.myfaces.component.ComponentResourceContainer,Id:
> jakarta_faces_location_head][Class: jakarta.faces.component.UIOutput,Id:
> j_id__rd_5]}
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.createAndQueueException(CheckDuplicateIdFaceletUtils.java:139)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:95)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:109)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:103)
> at
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:81)
> at
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:701)
> at
> jakarta.faces.application.StateManager.getViewState(StateManager.java:147)
> [...]{code}
> In our example, the resource that is apparently added to the component tree
> twice is _inputmask/inputmask.js_ of the _p:calendar_ component when using it
> in a {_}c:forEach{_}.
> The error only happens if _STRICT_JSF_2_FACELETS_COMPATIBILITY_ is enabled,
> but that is a requirement for our application. The error does not occur in
> Mojarra.
> I would appreciate you looking into this, as it is a pretty big problem for
> us. And before you ask: We're using c:forEach because in our application
> changing from c:forEach/c:if to ui:repeat/ui:fragment would result in an
> increase of components in the component tree by a factor of about 5 on some
> sites.
> I could copy and paste more of the code here, but I think it's easier to just
> look at the reproducer:
> [https://github.com/mkomko/primefaces-test/tree/inputmask-duplicateid]
> The error occurs when opening the dialog using the button and then clicking
> "Cancel".
> Thank you very much in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4644) Automatic extensionless mapping does not work on Java Facelet
[ https://issues.apache.org/jira/browse/MYFACES-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793340#comment-17793340 ] Volodymyr Siedlecki commented on MYFACES-4644: -- We can do that. How would we register them? Or to rephrase, where should we store the mappings if we used an extension? This is the general stack for when the extension-less mappings are registered: ViewResourceIterator.(FacesContext, ResourceHandlerSupport, String, List, String, String, int, ResourceVisitOption…) line: 51 ResourceHandlerImpl.getViewResources(FacesContext, String, int, ResourceVisitOption…) line: 1698 FaceletViewDeclarationLanguage(ViewDeclarationLanguage).getViews(FacesContext, String, int, ViewVisitOption…) line: 169 FaceletViewDeclarationLanguage.getViews(FacesContext, String, int, ViewVisitOption…) line: 2642 ViewHandlerImpl.getViews(FacesContext, String, int, ViewVisitOption…) line: 550 ViewHandlerImpl(ViewHandler).getViews(FacesContext, String, ViewVisitOption…) line: 423 … FacesInitializerImpl.initAutomaticExtensionlessMapping(FacesContext, ServletContext) line: 687 > Automatic extensionless mapping does not work on Java Facelet > - > > Key: MYFACES-4644 > URL: https://issues.apache.org/jira/browse/MYFACES-4644 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1, 4.1.0, 5.0.0 >Reporter: Volodymyr Siedlecki >Priority: Major > > Reported against Mojarra, but also affects MyFaces. > https://github.com/eclipse-ee4j/mojarra/issues/5362 > MyFaces fails to find the page: > ``` > Error 404: java.io.FileNotFoundException: SRVE0190E: File not found: > /hello-facelet > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
