[jira] [Commented] (MYFACES-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848207#comment-17848207
]
Thomas Andraschko commented on MYFACES-4667:
isnt it? https://github.com/jakartaee/faces/issues/1905
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: SteGr
>Priority: Major
>
> While working an a bug in [mojarra implementation|#issuecomment-2115154280]]
> I found an [old primefaces
> issue|https://github.com/primefaces/primefaces/issues/9245#issuecomment-2122507698]
> which was somehow related to my issue. Using the reproducer of that PF
> issue, I was able to really find the root cause of the issue and that even
> myfaces is affected - contrary to what was assumed at the time.
>
> *What happens?*
> A {{p:datatable}} with {{p:column*s*}} was updated by the backend using
> {{{}PrimeFaces#Ajax#update{}}}. The implementation used
> {{UIComponent#invokeOnComponent}} to find the component of the given
> clientId. As {{p:dataTable}} relies on {{UIData}} of myfaces, {{p:columns}}
> won't be handled. Nothing could be found and {{PrimeFaces#Ajax#update}} falls
> back to just forwarding the given clientId.
> *Why does it happen?*
> Like mojarra, myfaces filters the children on processing using {{{}instanceof
> UIColumn{}}}. But {{p:columns}} does not extend that class. Therefore
> {{p:columns}} is not a candiate and is simply ignored.
> *Possible fix* (not yet tested)
> Remove the check.
> *How to reproduce*
> Use the [reproducer
> |https://github.com/primefaces/primefaces/files/9664695/primefaces-test.zip]
> and change the PROJECT_STAGE to Development. Run the project using the
> myfaces23 profile. You should get a lot of logging entries like
> {quote}Mai 21, 2024 2:53:41 PM org.primefaces.PrimeFaces$Ajax update
> WARNUNG: PrimeFaces.current().ajax().update() called but component cant be
> resolved! Expression will just be added to the renderIds: \{0}
> {quote}
--
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=17844686#comment-17844686
]
Thomas Andraschko commented on MYFACES-4666:
You add declared a servlet in web.xml but its not loadable - why should we
ignore the exception?
> 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-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837768#comment-17837768
]
Thomas Andraschko commented on MYFACES-4661:
reminds me of: https://issues.apache.org/jira/browse/MYFACES-4624
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837765#comment-17837765
]
Thomas Andraschko commented on MYFACES-4661:
is it the same with current 4.0 SNAPSHOT?
i think it should actually just fail with "not found exception" as ":subview1"
just doesnt exist, its ":form:subview1"
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836631#comment-17836631 ] Thomas Andraschko commented on MYFACES-4659: [~melloware]you need to set "fix versions" correctly > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4660) WebSockets - view destroying + multiple tabs/windows
[ https://issues.apache.org/jira/browse/MYFACES-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836599#comment-17836599 ] Thomas Andraschko commented on MYFACES-4660: 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. > WebSockets - view destroying + multiple tabs/windows > > > Key: MYFACES-4660 > URL: https://issues.apache.org/jira/browse/MYFACES-4660 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 5.0.0 >Reporter: Milan Siebenbürger >Priority: Minor > > Hello, > We have identified two (hopefully minor) bugs while using WebSockets. > 1. destroying SessionScope channelToken when destroying ViewScope bean > If the user reaches the NUMBER_OF_VIEWS_IN_SESSION limit, the ViewScope bean > (which holds channelTokens) is automatically destroyed (@PreDestroy). > Additionally, any channelToken from the parent sessionScope is destroyed, > even if it is still in use. Unfortunately, this destruction occurs after a > new view is created, so the component is rendered, the WebSocket session is > connected, but the channelToken in the WebsocketScopeManager is destroyed. > The solution to this issue could be simple. The destruction of the > sessionScope channelToken could be left to the automatic destruction of the > SessionScope. We have been testing this solution for several weeks, and it > seems to be working fine. > > 2. using application in multiple tabs / browser windows (with same http > session) > When a user is using the application in more than one tab/window within the > same HTTP session, the user session channels are duplicated (with the same > channelToken) and connected to the same user identification, resulting in two > or more WebSocket sessions. Push messages are then sent to all > tokens/sessions. So far, everything is working as expected. > However, when one of the views is destroyed (i.e., a tab/window is closed), > the connected WebSocket session is also destroyed (which is expected). > Unfortunately, this also will cause user connection to be removed . Since we > don't track how many times the user is using this particular channelToken, > the WebSocket connections in the other tabs/windows are also disrupted. > A potential solution to this issue could involve tracking the number of times > the user starts using the channelToken. We could then remove the user > connection after all instances of its usage are destroyed, or, alternatively, > when the SessionScope object is destroyed. > Unfortunately, implementing this solution would cause a breaking change. It > would involve replacing the Set holding channelTokens with a HashMap that > also keeps track of the number of usages (refer to > WebsocketSessionManager.java:62). Since the method getUserMap is public and > may be used by others (such as ourselves, for implementing WebSocket > heartbeat), they would need to update their code accordingly with the new > version of MyFaces. An alternative approach could be implemented using > another collection to hold the usage count of channelTokens. However, this > method may not be as elegant, although it would not necessitate users to > modify their applications. > So, the questions: > * which of these to implement? > * and to which version (5.0? or 4.X?) > > Of course, I will prepare the changes in the form of a pull request to check > the changes > > Milan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4660) WebSockets - view destroying + multiple tabs/windows
[ https://issues.apache.org/jira/browse/MYFACES-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836599#comment-17836599 ] Thomas Andraschko edited comment on MYFACES-4660 at 4/12/24 1:06 PM: - 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. i would target 4.0, 4.1 and 5.0 which this change. was (Author: tandraschko): 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. > WebSockets - view destroying + multiple tabs/windows > > > Key: MYFACES-4660 > URL: https://issues.apache.org/jira/browse/MYFACES-4660 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 5.0.0 >Reporter: Milan Siebenbürger >Priority: Minor > > Hello, > We have identified two (hopefully minor) bugs while using WebSockets. > 1. destroying SessionScope channelToken when destroying ViewScope bean > If the user reaches the NUMBER_OF_VIEWS_IN_SESSION limit, the ViewScope bean > (which holds channelTokens) is automatically destroyed (@PreDestroy). > Additionally, any channelToken from the parent sessionScope is destroyed, > even if it is still in use. Unfortunately, this destruction occurs after a > new view is created, so the component is rendered, the WebSocket session is > connected, but the channelToken in the WebsocketScopeManager is destroyed. > The solution to this issue could be simple. The destruction of the > sessionScope channelToken could be left to the automatic destruction of the > SessionScope. We have been testing this solution for several weeks, and it > seems to be working fine. > > 2. using application in multiple tabs / browser windows (with same http > session) > When a user is using the application in more than one tab/window within the > same HTTP session, the user session channels are duplicated (with the same > channelToken) and connected to the same user identification, resulting in two > or more WebSocket sessions. Push messages are then sent to all > tokens/sessions. So far, everything is working as expected. > However, when one of the views is destroyed (i.e., a tab/window is closed), > the connected WebSocket session is also destroyed (which is expected). > Unfortunately, this also will cause user connection to be removed . Since we > don't track how many times the user is using this particular channelToken, > the WebSocket connections in the other tabs/windows are also disrupted. > A potential solution to this issue could involve tracking the number of times > the user starts using the channelToken. We could then remove the user > connection after all instances of its usage are destroyed, or, alternatively, > when the SessionScope object is destroyed. > Unfortunately, implementing this solution would cause a breaking change. It > would involve replacing the Set holding channelTokens with a HashMap that > also keeps track of the number of usages (refer to > WebsocketSessionManager.java:62). Since the method getUserMap is public and > may be used by others (such as ourselves, for implementing WebSocket > heartbeat), they would need to update their code accordingly with the new > version of MyFaces. An alternative approach could be implemented using > another collection to hold the usage count of channelTokens. However, this > method may not be as elegant, although it would not necessitate users to > modify their applications. > So, the questions: > * which of these to implement? > * and to which version (5.0? or 4.X?) > > Of course, I will prepare the changes in the form of a pull request to check > the changes > > Milan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834909#comment-17834909 ] Thomas Andraschko commented on MYFACES-4659: +1 > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4655) Cannot resolver managed FacesValidator with empty value
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4655.
Resolution: Fixed
Thanks for the great contribution!
> Cannot resolver managed FacesValidator with empty value
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test.zip
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828445#comment-17828445
]
Thomas Andraschko edited comment on MYFACES-4656 at 3/19/24 4:53 PM:
-
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten getRequired a
string as key
this just cant match - getter and setter need to be in sync
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
was (Author: tandraschko):
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4656.
Resolution: Invalid
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828445#comment-17828445
]
Thomas Andraschko edited comment on MYFACES-4656 at 3/19/24 4:52 PM:
-
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
was (Author: tandraschko):
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
```
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
```
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828445#comment-17828445
]
Thomas Andraschko commented on MYFACES-4656:
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
```
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
```
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828441#comment-17828441
]
Thomas Andraschko commented on MYFACES-4656:
Added a unit test for it, which is currently disabled as it fails
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827556#comment-17827556
]
Thomas Andraschko commented on MYFACES-4656:
a deeper research and PR would be welcome
i currently dont have much time for open source
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4655) NPE in FacesValidatorCDIWrapper
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827041#comment-17827041
]
Thomas Andraschko commented on MYFACES-4655:
would you like to prepare a PR?
> NPE in FacesValidatorCDIWrapper
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test.zip
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4655) NPE in FacesValidatorCDIWrapper
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827018#comment-17827018
]
Thomas Andraschko commented on MYFACES-4655:
yeah please
you can use the primefaces-test project
> NPE in FacesValidatorCDIWrapper
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> Debugging I found out it happens on a validator attached to a composite
> component using the for attribute.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4653) Faces 4.1 Spec Issue 1838: Remove references to the Java SecurityManager and associated APIs
[ https://issues.apache.org/jira/browse/MYFACES-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825366#comment-17825366 ] Thomas Andraschko commented on MYFACES-4653: please also merge to 5.x > Faces 4.1 Spec Issue 1838: Remove references to the Java SecurityManager and > associated APIs > > > Key: MYFACES-4653 > URL: https://issues.apache.org/jira/browse/MYFACES-4653 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Paul Nicolucci >Assignee: Paul Nicolucci >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2 > > > Link to specification issue: [https://github.com/jakartaee/faces/issues/1838] > > We need to clean up our references to the SecurityManager and associated APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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:all-tabpanel ] Thomas Andraschko resolved MYFACES-4642. Resolution: Fixed > 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 >Assignee: Thomas Andraschko >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > 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] [Resolved] (MYFACES-4650) UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED
[ https://issues.apache.org/jira/browse/MYFACES-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4650. Resolution: Fixed > UIViewRoot#resetValues called from #processPartialRendering should use > VisitHint.SKIP_UNRENDERED > > > Key: MYFACES-4650 > URL: https://issues.apache.org/jira/browse/MYFACES-4650 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1, 5.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4650) UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED
Thomas Andraschko created MYFACES-4650: -- Summary: UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED Key: MYFACES-4650 URL: https://issues.apache.org/jira/browse/MYFACES-4650 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Andraschko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4648.
Resolution: Fixed
Thanks,
Great contribution as always
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807272#comment-17807272
]
Thomas Andraschko commented on MYFACES-4648:
as long there is no reason, i think we can stick with empty hashmap.
please provide a PR ASAP, we discussed already about the next release
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4649) ViewScoped bean handling broken because of refactoring
[ https://issues.apache.org/jira/browse/MYFACES-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4649. Resolution: Fixed > 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] [Created] (MYFACES-4649) ViewScoped bean handling broken because of refactoring
Thomas Andraschko created MYFACES-4649: -- Summary: 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 i restored the 2.3.x behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807207#comment-17807207
]
Thomas Andraschko commented on MYFACES-4648:
+1
could you also check mojarra here?
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (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:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4623.
Resolution: Fixed
> 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.0.2, 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] [Resolved] (MYFACES-4641) MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)" imports
[
https://issues.apache.org/jira/browse/MYFACES-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4641.
Resolution: Fixed
> MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)"
> imports
>
>
> Key: MYFACES-4641
> URL: https://issues.apache.org/jira/browse/MYFACES-4641
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Maxime Leur
>Priority: Major
> Fix For: 3.0.3
>
>
> Hi,
> In MyFaces web site, version "3.0.x" is supposed to be compatible with:
> * Java 1.8
> * Servlet 5.0
> * EL 4.0
> * CDI 3.0 (optional)
> * JSTL 2.0 (optional)
> * BV 2.0 (optional)
> But I see that in "MyFaces bundle" the MANIFEST file contains
> "jakarta.servlet.*;version="[3,5)" imports:
> {noformat}
> jakarta.servlet.annotation;version="[3,5)";resolution:=optional
> jakarta.servlet.http;version="[3,5)"
> jakarta.servlet.jsp.jstl.core;version="[1.1.2,2.0.0)"
> jakarta.servlet.jsp.jstl.sql
> jakarta.servlet.jsp.tagext;version="[2.1.0,3.1)"
> jakarta.servlet.jsp;version="[2.1.0,3.1)"
> jakarta.servlet;version="[3,5)"
> {noformat}
> So it seems not compatible on OSGI environment with "Servlet 5.0".
> Regards,
> Maxime
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4641) MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)" imports
[
https://issues.apache.org/jira/browse/MYFACES-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802873#comment-17802873
]
Thomas Andraschko commented on MYFACES-4641:
updated it but not sure if all is correct
please provide a PR otherwise, i dont use OSGI
> MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)"
> imports
>
>
> Key: MYFACES-4641
> URL: https://issues.apache.org/jira/browse/MYFACES-4641
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Maxime Leur
>Priority: Major
> Fix For: 3.0.3
>
>
> Hi,
> In MyFaces web site, version "3.0.x" is supposed to be compatible with:
> * Java 1.8
> * Servlet 5.0
> * EL 4.0
> * CDI 3.0 (optional)
> * JSTL 2.0 (optional)
> * BV 2.0 (optional)
> But I see that in "MyFaces bundle" the MANIFEST file contains
> "jakarta.servlet.*;version="[3,5)" imports:
> {noformat}
> jakarta.servlet.annotation;version="[3,5)";resolution:=optional
> jakarta.servlet.http;version="[3,5)"
> jakarta.servlet.jsp.jstl.core;version="[1.1.2,2.0.0)"
> jakarta.servlet.jsp.jstl.sql
> jakarta.servlet.jsp.tagext;version="[2.1.0,3.1)"
> jakarta.servlet.jsp;version="[2.1.0,3.1)"
> jakarta.servlet;version="[3,5)"
> {noformat}
> So it seems not compatible on OSGI environment with "Servlet 5.0".
> Regards,
> Maxime
--
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=17802834#comment-17802834
]
Thomas Andraschko commented on MYFACES-4623:
[~volosied] whats with this ticket? you added and reverted 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] [Comment Edited] (MYFACES-4637) Have PushContext#Send Support Collection of Records
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795369#comment-17795369
]
Thomas Andraschko edited comment on MYFACES-4637 at 1/4/24 9:38 AM:
I think we should fix that for 4.1 (EE11) and 5.0 (EE12)
for now only 5.0 builds with java17 -> so up to you if we backport all
dependency changes to 4.1
was (Author: tandraschko):
I think we should fix that for 4.1 (EE11) and 5.0 (EE12)
will now push both to Java17, so can easily fix this then
for now only 5.0 builds with java17 -> so up to you if we backport all
dependency changes to 4.1
> Have PushContext#Send Support Collection of Records
> ---
>
> 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] [Resolved] (MYFACES-4645) Conversion error for select items of type String
[
https://issues.apache.org/jira/browse/MYFACES-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4645.
Assignee: Thomas Andraschko
Resolution: Fixed
> Conversion error for select items of type String
>
>
> Key: MYFACES-4645
> URL: https://issues.apache.org/jira/browse/MYFACES-4645
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: image-2023-12-04-13-30-22-019.png,
> primefaces-test-duplicate-conversion-error.zip
>
>
> An error occurs when using select items of type String in combination with
> the OmniFaces SelectItemsIndexConverter. MyFaces seems to attempt to convert
> the submitted value twice, which leads to a NumberFormatException on the
> second try.
> I suspect the following if-statement in
> _org.apache.myfaces.core.api.shared.SelectItemsUtil_ to be the culprit, but
> of course have no idea why it is needed in other cases or how to fix the
> problem:
> !image-2023-12-04-13-30-22-019.png!
> Please see the attached reproducer, which produces the error when selecting a
> value in the SelectOneMenu when run with
> {noformat}
> mvn clean jetty:run -Pmyfaces40{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4647) PushContextImpl send - NPE when no channel found for user
[ https://issues.apache.org/jira/browse/MYFACES-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4647. Resolution: Fixed Thanks for the PRs! > PushContextImpl send - NPE when no channel found for user > - > > Key: MYFACES-4647 > URL: https://issues.apache.org/jira/browse/MYFACES-4647 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0, 4.0.1 >Reporter: Milan Siebenbürger >Priority: Minor > Fix For: 4.0.2, 4.1.0, 5.0.0 > > > When trying to send a push message to a user who has already destroyed his > web socket connection, PushContextImpl.send throws NPE > java.lang.NullPointerException: Cannot invoke "java.util.Set.size()" because > "channelTokenSet" is null > at > org.apache.myfaces.push.cdi.PushContextImpl.send(PushContextImpl.java:134) > at > org.apache.myfaces.push.cdi.PushContextImpl.send(PushContextImpl.java:122) > Method should be null safe, just to continue with next user identification. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4647) PushContextImpl send - NPE when no channel found for user
[ https://issues.apache.org/jira/browse/MYFACES-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797186#comment-17797186 ] Thomas Andraschko commented on MYFACES-4647: plz also for master (5.0) > PushContextImpl send - NPE when no channel found for user > - > > Key: MYFACES-4647 > URL: https://issues.apache.org/jira/browse/MYFACES-4647 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 4.0.0, 4.0.1 >Reporter: Milan Siebenbürger >Priority: Minor > > When trying to send a push message to a user who has already destroyed his > web socket connection, PushContextImpl.send throws NPE > java.lang.NullPointerException: Cannot invoke "java.util.Set.size()" because > "channelTokenSet" is null > at > org.apache.myfaces.push.cdi.PushContextImpl.send(PushContextImpl.java:134) > at > org.apache.myfaces.push.cdi.PushContextImpl.send(PushContextImpl.java:122) > Method should be null safe, just to continue with next user identification. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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:all-tabpanel ] Thomas Andraschko resolved MYFACES-4644. Resolution: Fixed > 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 >Assignee: Volodymyr Siedlecki >Priority: Major > Fix For: 4.1.0, 5.0.0, 4.0.1 > > > 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)
[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=17795426#comment-17795426 ] Thomas Andraschko commented on MYFACES-4644: it seems its only called on startup, so lets leave it as it is > 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 >Assignee: 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)
[jira] [Comment Edited] (MYFACES-4637) Have PushContext#Send Support Collection of Records
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795369#comment-17795369
]
Thomas Andraschko edited comment on MYFACES-4637 at 12/11/23 2:03 PM:
--
I think we should fix that for 4.1 (EE11) and 5.0 (EE12)
will now push both to Java17, so can easily fix this then
for now only 5.0 builds with java17 -> so up to you if we backport all
dependency changes to 4.1
was (Author: tandraschko):
I think we should fix that for 4.1 (EE11) and 5.0 (EE12)
will now push both to Java17, so can easily fix this then
> Have PushContext#Send Support Collection of Records
> ---
>
> 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-4581) Felix Bundle ConcurrentModificationException
[
https://issues.apache.org/jira/browse/MYFACES-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795373#comment-17795373
]
Thomas Andraschko commented on MYFACES-4581:
[~volosied] i merged this PR now as CI fails please
please investigate further or close this issue.
> Felix Bundle ConcurrentModificationException
>
>
> Key: MYFACES-4581
> URL: https://issues.apache.org/jira/browse/MYFACES-4581
> Project: MyFaces Core
> Issue Type: Bug
> Components: build process
>Affects Versions: 4.0.0
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Running `mvn clean install` locally on my machine I get
> `ConcurrentModificationExcepiton` in the Felix plugin. Bumping to 5.1.8
> fixes the issue.
>
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\Tools\apache-maven-3.9.0
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: C:\Tools\jdk-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4637) Have PushContext#Send Support Collection of Records
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795369#comment-17795369
]
Thomas Andraschko commented on MYFACES-4637:
I think we should fix that for 4.1 (EE11) and 5.0 (EE12)
will now push both to Java17, so can easily fix this then
> Have PushContext#Send Support Collection of Records
> ---
>
> 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
>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-4641) MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)" imports
[
https://issues.apache.org/jira/browse/MYFACES-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795365#comment-17795365
]
Thomas Andraschko commented on MYFACES-4641:
Still waiting for the PR to merge :)
> MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)"
> imports
>
>
> Key: MYFACES-4641
> URL: https://issues.apache.org/jira/browse/MYFACES-4641
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Maxime Leur
>Priority: Major
> Fix For: 3.0.3
>
>
> Hi,
> In MyFaces web site, version "3.0.x" is supposed to be compatible with:
> * Java 1.8
> * Servlet 5.0
> * EL 4.0
> * CDI 3.0 (optional)
> * JSTL 2.0 (optional)
> * BV 2.0 (optional)
> But I see that in "MyFaces bundle" the MANIFEST file contains
> "jakarta.servlet.*;version="[3,5)" imports:
> {noformat}
> jakarta.servlet.annotation;version="[3,5)";resolution:=optional
> jakarta.servlet.http;version="[3,5)"
> jakarta.servlet.jsp.jstl.core;version="[1.1.2,2.0.0)"
> jakarta.servlet.jsp.jstl.sql
> jakarta.servlet.jsp.tagext;version="[2.1.0,3.1)"
> jakarta.servlet.jsp;version="[2.1.0,3.1)"
> jakarta.servlet;version="[3,5)"
> {noformat}
> So it seems not compatible on OSGI environment with "Servlet 5.0".
> Regards,
> Maxime
--
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=17793547#comment-17793547 ] Thomas Andraschko commented on MYFACES-4644: [~volosied] did you add an integrationt test? so i can just refactor and see if everything works > 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 >Assignee: 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)
[jira] [Commented] (MYFACES-4645) Conversion error for select items of type String
[
https://issues.apache.org/jira/browse/MYFACES-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792880#comment-17792880
]
Thomas Andraschko commented on MYFACES-4645:
a deeper analysis and comparison to mojarra would be great
> Conversion error for select items of type String
>
>
> Key: MYFACES-4645
> URL: https://issues.apache.org/jira/browse/MYFACES-4645
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: image-2023-12-04-13-30-22-019.png,
> primefaces-test-duplicate-conversion-error.zip
>
>
> An error occurs when using select items of type String in combination with
> the OmniFaces SelectItemsIndexConverter. MyFaces seems to attempt to convert
> the submitted value twice, which leads to a NumberFormatException on the
> second try.
> I suspect the following if-statement in
> _org.apache.myfaces.core.api.shared.SelectItemsUtil_ to be the culprit, but
> of course have no idea why it is needed in other cases or how to fix the
> problem:
> !image-2023-12-04-13-30-22-019.png!
> Please see the attached reproducer, which produces the error when selecting a
> value in the SelectOneMenu when run with
> {noformat}
> mvn clean jetty:run -Pmyfaces40{noformat}
--
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=17792821#comment-17792821 ] Thomas Andraschko commented on MYFACES-4644: TBH we should at least in 5.0 switch to a CDI extension makes the whole thing faster > 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)
[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=17789415#comment-17789415 ] Thomas Andraschko commented on MYFACES-4642: Yeah, please try to analyze further - you know, its open source ;) > 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] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:51 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
you just need to debug deeply through DefaultAnnotationProvider
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
just need to debug deeply through DefaultAnnotationProvider
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:49 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
it might also be just broken on jakarta or newer java version.
just need to debug deeply through DefaultAnnotationProvider
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 4:47 PM:
--
If you would like to work on it, please create a new issue with something like
"Classpath scanning in DefaultAnnotationProvider broken on wildfly" - but as i
said, i wont invest time, i can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
was (Author: tandraschko):
If you would like to work on it, please create a new issue with something like
"Classpath scanning broken on wildfly" - but as i said, i wont invest time, i
can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789213#comment-17789213
]
Thomas Andraschko commented on MYFACES-4643:
If you would like to work on it, please create a new issue with something like
"Classpath scanning broken on wildfly" - but as i said, i wont invest time, i
can just give some advices.
vfs is a own jboss protocoll, not sure if the dir must exist to resolve that
path.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789200#comment-17789200
]
Thomas Andraschko commented on MYFACES-4643:
no, its not per definition incompatible.
OmniFaces could just add a "bean defining annotation" to it (check CDI spec) or
omnifaces / your application must set bean-discovery-mode=all. Anyway, its just
a CDI problem or configuration, we cant help here.
If you set org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING=false,
MyFaces has to manually open all JARs in the WAR and scan for `@FacesConverter`
and that should >actually work<
TBH i wont invest many time here. MF5.0 will rely on CDI scanning only. i would
try to fix your setup here or ask OmniFaces guys to add e.g. @ApplicationScoped.
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (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=17789174#comment-17789174
]
Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:31 PM:
--
Could you just try to add something like this
{code:java}
if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}
{code}
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
was (Author: tandraschko):
Could you just try to add something like this
```if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
> 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] [Comment Edited] (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=17789174#comment-17789174
]
Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:30 PM:
--
Could you just try to add something like this
```if (viewScopeId == null) {
viewScopeId = Integer.toString(new Random().nextInt());
}`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
was (Author: tandraschko):
Could you just try to add something like this
`viewScopeId = Integer.toString(new Random().nextInt());`
in ViewScopeProxyMap#ln 75
if yes, we could fix it easily in old branches but we would need quite a big
refactoring in this whole area in our master
> 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-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=17789174#comment-17789174 ] Thomas Andraschko commented on MYFACES-4642: Could you just try to add something like this `viewScopeId = Integer.toString(new Random().nextInt());` in ViewScopeProxyMap#ln 75 if yes, we could fix it easily in old branches but we would need quite a big refactoring in this whole area in our master > 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] [Comment Edited] (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=17789171#comment-17789171 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:26 PM: -- AFAICS values are stored and restored in the viewmap, even if no CDI is directly involved: [^myfaces-viewmap.zip] you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. was (Author: tandraschko): Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAICS you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > 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] [Comment Edited] (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=17789171#comment-17789171 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 3:23 PM: -- Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAICS you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. was (Author: tandraschko): Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAIK you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > 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-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=17789171#comment-17789171 ] Thomas Andraschko commented on MYFACES-4642: Looks fine IMO [^myfaces-viewmap.zip] values are stored and restored in the viewmap AFAIK you can just run it via "mvn clean jetty:run -Pmyfaces40" and open "http://localhost:8080/primefaces-test/test.xhtml; i dont see anything that our viewmap would be broken. > 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] [Comment Edited] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789158#comment-17789158
]
Thomas Andraschko edited comment on MYFACES-4643 at 11/23/23 3:05 PM:
--
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it for SelectItemsConverter
was (Author: tandraschko):
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4643) OmniFaces converters not found using CDI
[
https://issues.apache.org/jira/browse/MYFACES-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789158#comment-17789158
]
Thomas Andraschko commented on MYFACES-4643:
IMO not a bug but didnt debug it
if you have USE_CDI_FOR_ANNOTATION_SCANNING, we only see all classes running
through CDI
that means that SelectItemsConverter isnt a CDI bean?
Just debug CdiAnnotationProviderExtension#processAnnotatedType and you will
propably see that CDI doesnt invoke it
> OmniFaces converters not found using CDI
>
>
> Key: MYFACES-4643
> URL: https://issues.apache.org/jira/browse/MYFACES-4643
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: primefaces-test.zip
>
>
> [As I wrote in the OmniFaces GitHub
> repository|https://github.com/omnifaces/omnifaces/issues/744#issuecomment-1824172540]:
> When upgrading from OmniFaces 4.1 to 4.2/4.3 in our application (WildFly 30,
> MyFaces 4.0.1), we get the following errors due to the change to the
> _bean-discovery-mode_ discussed in the linked GitHub issue:
> {code:java}
> jakarta.faces.FacesException: Could not find any registered converter-class
> by converterId : omnifaces.SelectItemsConverter {code}
> It especially happens when using the following context-param:
> {code:java}
>
>
> org.apache.myfaces.annotation.USE_CDI_FOR_ANNOTATION_SCANNING
> true
> {code}
> But in our application it even happens without it. Reproducer using
> primefaces-test is attached. Run it using _mvn clean jetty:run -Pmyfaces40_
> and the exception appears.
> I would have thought that it would be an OmniFaces issue, but melloware
> thinks it's a MyFaces issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (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=17789154#comment-17789154 ] Thomas Andraschko edited comment on MYFACES-4642 at 11/23/23 2:53 PM: -- Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? If that would be the case, our own ViewScope would be broken, too? was (Author: tandraschko): Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? > 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 > > > 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-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=17789154#comment-17789154 ] Thomas Andraschko commented on MYFACES-4642: Can you check if a viewmap is created every request? The values, which you put manually into a viewmap, will be lost? > 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 > > > 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] [Reopened] (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:all-tabpanel ] Thomas Andraschko reopened MYFACES-4642: > 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 > > > 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-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=17789054#comment-17789054 ] Thomas Andraschko commented on MYFACES-4642: Faces 4.0 removed the whole ManagedBean stuff and the Faces @ViewScoped is CDI only. Do you use your own or JoinFaces Spring ViewScoped? Better create a issue there. > 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 > > > 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-4641) MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)" imports
[
https://issues.apache.org/jira/browse/MYFACES-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789055#comment-17789055
]
Thomas Andraschko commented on MYFACES-4641:
Would you like to create a PR for 3.x, 4.x, 4.1 and master?
> MyFaces bundle MANIFEST file contains "jakarta.servlet.*;version="[3,5)"
> imports
>
>
> Key: MYFACES-4641
> URL: https://issues.apache.org/jira/browse/MYFACES-4641
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Maxime Leur
>Priority: Major
>
> Hi,
> In MyFaces web site, version "3.0.x" is supposed to be compatible with:
> * Java 1.8
> * Servlet 5.0
> * EL 4.0
> * CDI 3.0 (optional)
> * JSTL 2.0 (optional)
> * BV 2.0 (optional)
> But I see that in "MyFaces bundle" the MANIFEST file contains
> "jakarta.servlet.*;version="[3,5)" imports:
> {noformat}
> jakarta.servlet.annotation;version="[3,5)";resolution:=optional
> jakarta.servlet.http;version="[3,5)"
> jakarta.servlet.jsp.jstl.core;version="[1.1.2,2.0.0)"
> jakarta.servlet.jsp.jstl.sql
> jakarta.servlet.jsp.tagext;version="[2.1.0,3.1)"
> jakarta.servlet.jsp;version="[2.1.0,3.1)"
> jakarta.servlet;version="[3,5)"
> {noformat}
> So it seems not compatible on OSGI environment with "Servlet 5.0".
> Regards,
> Maxime
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788716#comment-17788716
]
Thomas Andraschko commented on MYFACES-4606:
we are done with this now?
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4639) Implementation ClassUtils needs "newInstance" methods added to support OSGI runtimes
[ https://issues.apache.org/jira/browse/MYFACES-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784375#comment-17784375 ] Thomas Andraschko commented on MYFACES-4639: Cant we just pass the classloader? > Implementation ClassUtils needs "newInstance" methods added to support OSGI > runtimes > > > Key: MYFACES-4639 > URL: https://issues.apache.org/jira/browse/MYFACES-4639 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > > This is basically the same issue as > https://issues.apache.org/jira/browse/MYFACES-4449 > This variant was originally reported here: > [https://github.com/OpenLiberty/open-liberty/issues/26760] > However, the CNFE occurs with the newInstance methods since the classes are > looked up via the API classloader and therefore not found (since the classes > exist in the Impl and OSGI creates seperate between bundles. See the > discussion in 4449 for more information) > Example of error: > [ERROR ] Class org.apache.myfaces.push.WebsocketInitRenderer not found > org.apache.myfaces.push.WebsocketInitRenderer cannot be found by > io.openliberty.jakarta.faces.4.0_1.0.84.202311061333 > This error is related to whether the renderkit is an instance of > LazyRenderKit. If it's not, then the standard form look up used (via > newInstance). > LazyRenderKit code was added via MYFACES-3815 : > [https://github.com/apache/myfaces/commit/93a2ddf060d04cea658f58f9223c22b5badeea90] > > I'm not entirely sure how this happens in the users case above, but we should > move these methods again to avoid these errors. I'll have a PR up soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4635) TCK Failure: Cannot find component for expression ":willThrowException" referenced from "submit".
[
https://issues.apache.org/jira/browse/MYFACES-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783801#comment-17783801
]
Thomas Andraschko commented on MYFACES-4635:
TCK challenge merged
> TCK Failure: Cannot find component for expression ":willThrowException"
> referenced from "submit".
> --
>
> Key: MYFACES-4635
> URL: https://issues.apache.org/jira/browse/MYFACES-4635
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Tested on 4.0.1-SNAPSHOT, so this isn't in any released code.
> Test:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3171IT.java#L37]
>
> App:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/main/webapp/exceptionDuringRender.xhtml#L53]
>
> Something must have changed recently that doesn't like the colon.
> _ value="#\{bean.throwExceptionOnAjax}" />_
> __
> __
> __
> Full Exception:
> {color:#cc}Caused by:
> {color}{color:#ce9178}jakarta.faces.component.search.ComponentNotFoundException{color}{color:#cc}:
> Cannot find component for expression
> {color}{color:#ce9178}":willThrowException"{color}{color:#cc} referenced
> from {color}{color:#ce9178}"submit"{color}{color:#cc}.{color}
> {color:#ce9178} at
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.resolveClientIds(SearchExpressionHandlerImpl.java:179){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.appendIds(AjaxScriptBuilder.java:279){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:205){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:117){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:71){color}
> {color:#ce9178} at
> jakarta.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:92){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.appendClientBehaviourScript(ClientBehaviorRendererUtils.java:208){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.getClientBehaviorScript(ClientBehaviorRendererUtils.java:186){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:349){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:315){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.buildBehaviorizedOnClick(HtmlButtonRendererBase.java:340){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.encodeBegin(HtmlButtonRendererBase.java:186){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:561){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:495){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1783){color}
> {color:#ce9178} at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316){color}
> {color:#ce9178} at
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241){color}
> {color:#ce9178} at
> jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225){color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4485) 2.3/3.0: UnsupportedOperationException with Extensionless Mapping
[ https://issues.apache.org/jira/browse/MYFACES-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783796#comment-17783796 ] Thomas Andraschko commented on MYFACES-4485: [~paul.nicolucci] still interessted? Otherwise lets just close it. > 2.3/3.0: UnsupportedOperationException with Extensionless Mapping > - > > Key: MYFACES-4485 > URL: https://issues.apache.org/jira/browse/MYFACES-4485 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.3.10, 3.0.2 >Reporter: Paul Nicolucci >Assignee: Paul Nicolucci >Priority: Major > > The fix for JSF 2.3 / 3.0 is going to take a bit more time to investigate. > > Faces 4.0 / 2.3-next was fixed here: > https://issues.apache.org/jira/browse/MYFACES-4447 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4637) Have PushContext#Send Support Collection of Records
[
https://issues.apache.org/jira/browse/MYFACES-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783788#comment-17783788
]
Thomas Andraschko commented on MYFACES-4637:
We should add some tests here with objects and records
So we have to push to java17
> Have PushContext#Send Support Collection of Records
> ---
>
> 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
>Priority: Major
>
> 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] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783682#comment-17783682 ] Thomas Andraschko edited comment on MYFACES-4629 at 11/7/23 4:19 PM: - also added a small test for it, that its only processed once: https://github.com/apache/myfaces/commit/0ebef69316193230cd305c44fd9c2ffe2ea8aa3f was (Author: tandraschko): also added a small test for it, that its only processed once > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Major > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783682#comment-17783682 ] Thomas Andraschko commented on MYFACES-4629: also added a small test for it, that its only processed once > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Major > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783623#comment-17783623 ] Thomas Andraschko commented on MYFACES-4629: even by design in PrimeFaces, see: https://github.com/primefaces/primefaces/issues/10958 > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Major > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783619#comment-17783619 ] Thomas Andraschko edited comment on MYFACES-4629 at 11/7/23 12:53 PM: -- What happens is that MyFaces always processes AJAX source and execute id's, which is tested above Mojarra only processes the AJAX execute so Mojarra directly invokes "form:input", whereas MyFaces invokes "form" and the form actually processes its child directly our behavior is documented here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L220 the second hint is here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L732 so what happens in MF internally: - we process `form` - we know that the second id is a child of `form`, so we ignore it - we rely on it that form process its childs and here we go: PrimeFaces UITabPanel skips its children i think the MyFaces behavior is good and we need to check if we can fix it in PF or not was (Author: tandraschko): What happens is that MyFaces always processes AJAX source and execute id's, which is tested above Mojarra only processes the AJAX execute our behavior is documented here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L220 the second hint is here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L732 so what happens in MF internally: - we process `form` - we know that the second id is a child of `form`, so we ignore it - we rely on it that form process its childs and here we go: PrimeFaces UITabPanel skips its children i think the MyFaces behavior is good and we need to check if we can fix it in PF or not > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Major > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783619#comment-17783619 ] Thomas Andraschko commented on MYFACES-4629: What happens is that MyFaces always processes AJAX source and execute id's, which is tested above Mojarra only processes the AJAX execute our behavior is documented here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L220 the second hint is here: https://github.com/apache/myfaces/blob/816d4ae3b3d677752a33569231507a0cd7130c6b/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java#L732 so what happens in MF internally: - we process `form` - we know that the second id is a child of `form`, so we ignore it - we rely on it that form process its childs and here we go: PrimeFaces UITabPanel skips its children i think the MyFaces behavior is good and we need to check if we can fix it in PF or not > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Major > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[
https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783613#comment-17783613
]
Thomas Andraschko edited comment on MYFACES-4629 at 11/7/23 12:47 PM:
--
ok, i dont know if its a bug or not but this testcase show the issue:
{code:java}
@Test
public void test() {
ArrayList clientIds = new ArrayList<>();
clientIds.add("form:input");
clientIds.add("form");
PartialVisitContext visitContext = new
PartialVisitContext(facesContext, clientIds,
EnumSet.of(VisitHint.EXECUTE_LIFECYCLE,
VisitHint.SKIP_UNRENDERED));
UIViewRoot viewRoot = new UIViewRoot();
HtmlForm form = new HtmlForm();
form.setId("form");
viewRoot.getChildren().add(form);
HtmlInputText inputText = new HtmlInputText();
inputText.setId("input");
form.getChildren().add(inputText);
final List visitedComponents = new ArrayList<>();
viewRoot.visitTree(visitContext, (VisitContext context, UIComponent
target) -> {
visitedComponents.add(target);
// Same as PhaseAwareVisitCallback:
// Return VisitResult.REJECT as processDecodes/Validators/Updates
already traverse sub tree
return VisitResult.REJECT;
});
// 1 or 2 visitedComponents?
}
{code}
was (Author: tandraschko):
ok, i dont know if its a bug or not but this testcase show the issue:
```java
@Test
public void test() {
ArrayList clientIds = new ArrayList<>();
clientIds.add("form:input");
clientIds.add("form");
PartialVisitContext visitContext = new
PartialVisitContext(facesContext, clientIds,
EnumSet.of(VisitHint.EXECUTE_LIFECYCLE,
VisitHint.SKIP_UNRENDERED));
UIViewRoot viewRoot = new UIViewRoot();
HtmlForm form = new HtmlForm();
form.setId("form");
viewRoot.getChildren().add(form);
HtmlInputText inputText = new HtmlInputText();
inputText.setId("input");
form.getChildren().add(inputText);
final List visitedComponents = new ArrayList<>();
viewRoot.visitTree(visitContext, (VisitContext context, UIComponent
target) -> {
visitedComponents.add(target);
// Same as PhaseAwareVisitCallback:
// Return VisitResult.REJECT as processDecodes/Validators/Updates
already traverse sub tree
return VisitResult.REJECT;
});
// 1 or 2 visitedComponents?
}
```
> Manual AJAX request does not process TabView correctly
> --
>
> Key: MYFACES-4629
> URL: https://issues.apache.org/jira/browse/MYFACES-4629
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: pf-tabview.zip
>
>
> When manually calling PrimeFaces.ajax.Request.handle the validationFailed
> argument is not sent to the client.
> For more details and a reproducer please see
> https://github.com/orgs/primefaces/discussions/123
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[
https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783613#comment-17783613
]
Thomas Andraschko commented on MYFACES-4629:
ok, i dont know if its a bug or not but this testcase show the issue:
```java
@Test
public void test() {
ArrayList clientIds = new ArrayList<>();
clientIds.add("form:input");
clientIds.add("form");
PartialVisitContext visitContext = new
PartialVisitContext(facesContext, clientIds,
EnumSet.of(VisitHint.EXECUTE_LIFECYCLE,
VisitHint.SKIP_UNRENDERED));
UIViewRoot viewRoot = new UIViewRoot();
HtmlForm form = new HtmlForm();
form.setId("form");
viewRoot.getChildren().add(form);
HtmlInputText inputText = new HtmlInputText();
inputText.setId("input");
form.getChildren().add(inputText);
final List visitedComponents = new ArrayList<>();
viewRoot.visitTree(visitContext, (VisitContext context, UIComponent
target) -> {
visitedComponents.add(target);
// Same as PhaseAwareVisitCallback:
// Return VisitResult.REJECT as processDecodes/Validators/Updates
already traverse sub tree
return VisitResult.REJECT;
});
// 1 or 2 visitedComponents?
}
```
> Manual AJAX request does not process TabView correctly
> --
>
> Key: MYFACES-4629
> URL: https://issues.apache.org/jira/browse/MYFACES-4629
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0, 4.0.1
>Reporter: Manuel K
>Priority: Major
> Attachments: pf-tabview.zip
>
>
> When manually calling PrimeFaces.ajax.Request.handle the validationFailed
> argument is not sent to the client.
> For more details and a reproducer please see
> https://github.com/orgs/primefaces/discussions/123
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782520#comment-17782520
]
Thomas Andraschko commented on MYFACES-4636:
2.3 works fine
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4636.
Resolution: Fixed
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782498#comment-17782498
]
Thomas Andraschko commented on MYFACES-4636:
[~werpu] did you change it also for old JS base in past?
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782096#comment-17782096
]
Thomas Andraschko commented on MYFACES-4636:
Can you review plz [~werpu]?
and [~sidvi] can you please retest and build from source? applied the bugfix to
the 2.3-next branch
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> // function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko edited comment on MYFACES-4629 at 10/30/23 9:25 AM: -- Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for PhaseId#RENDER_RESPONSE, not for validating and so on. Thats the bug. So something between is the reason, you may debug it. Another class involved is: PartialVisitContext was (Author: tandraschko): Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for PhaseId#RENDER_RESPONSE, not for validating and so on. Thats the bug. So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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=17780915#comment-17780915
]
Thomas Andraschko edited comment on MYFACES-4623 at 10/30/23 9:23 AM:
--
[~volosied] will you port to 4.0?
was (Author: tandraschko):
[~volosied] will you port to 4.0 and 4.1?
> 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-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=17780915#comment-17780915
]
Thomas Andraschko commented on MYFACES-4623:
[~volosied] will you port to 4.0 and 4.1?
> 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: 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] [Resolved] (MYFACES-4618) Faces 5.0: ui:repeat clarification on attributes, such as offset and size
[ https://issues.apache.org/jira/browse/MYFACES-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4618. Resolution: Fixed > Faces 5.0: ui:repeat clarification on attributes, such as offset and size > - > > Key: MYFACES-4618 > URL: https://issues.apache.org/jira/browse/MYFACES-4618 > Project: MyFaces Core > Issue Type: Improvement >Reporter: Thomas Andraschko >Assignee: Melloware >Priority: Major > Fix For: 5.0.0 > > > See https://github.com/eclipse-ee4j/mojarra/pull/5289 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4635) TCK Failure: Cannot find component for expression ":willThrowException" referenced from "submit".
[
https://issues.apache.org/jira/browse/MYFACES-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776991#comment-17776991
]
Thomas Andraschko commented on MYFACES-4635:
Not sure about IT
But the test expects a exception and we throw one?
> TCK Failure: Cannot find component for expression ":willThrowException"
> referenced from "submit".
> --
>
> Key: MYFACES-4635
> URL: https://issues.apache.org/jira/browse/MYFACES-4635
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Tested on 4.0.1-SNAPSHOT, so this isn't in any released code.
> Test:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3171IT.java#L37]
>
> App:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/main/webapp/exceptionDuringRender.xhtml#L53]
>
> Something must have changed recently that doesn't like the colon.
> _ value="#\{bean.throwExceptionOnAjax}" />_
> __
> __
> __
> Full Exception:
> {color:#cc}Caused by:
> {color}{color:#ce9178}jakarta.faces.component.search.ComponentNotFoundException{color}{color:#cc}:
> Cannot find component for expression
> {color}{color:#ce9178}":willThrowException"{color}{color:#cc} referenced
> from {color}{color:#ce9178}"submit"{color}{color:#cc}.{color}
> {color:#ce9178} at
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.resolveClientIds(SearchExpressionHandlerImpl.java:179){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.appendIds(AjaxScriptBuilder.java:279){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:205){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:117){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:71){color}
> {color:#ce9178} at
> jakarta.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:92){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.appendClientBehaviourScript(ClientBehaviorRendererUtils.java:208){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.getClientBehaviorScript(ClientBehaviorRendererUtils.java:186){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:349){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:315){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.buildBehaviorizedOnClick(HtmlButtonRendererBase.java:340){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.encodeBegin(HtmlButtonRendererBase.java:186){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:561){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:495){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1783){color}
> {color:#ce9178} at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316){color}
> {color:#ce9178} at
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241){color}
> {color:#ce9178} at
> jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225){color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4635) TCK Failure: Cannot find component for expression ":willThrowException" referenced from "submit".
[
https://issues.apache.org/jira/browse/MYFACES-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776869#comment-17776869
]
Thomas Andraschko commented on MYFACES-4635:
everything is correct here
":" means to start from root, so it must throw a exception
if the id says "willThrowException", which is correct
> TCK Failure: Cannot find component for expression ":willThrowException"
> referenced from "submit".
> --
>
> Key: MYFACES-4635
> URL: https://issues.apache.org/jira/browse/MYFACES-4635
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Tested on 4.0.1-SNAPSHOT, so this isn't in any released code.
> Test:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3171IT.java#L37]
>
> App:
> [https://github.com/jakartaee/faces/blob/2719e03eef7ff5dd999dcf084feb5462a27bbea9/tck/faces22/ajax/src/main/webapp/exceptionDuringRender.xhtml#L53]
>
> Something must have changed recently that doesn't like the colon.
> _ value="#\{bean.throwExceptionOnAjax}" />_
> __
> __
> __
> Full Exception:
> {color:#cc}Caused by:
> {color}{color:#ce9178}jakarta.faces.component.search.ComponentNotFoundException{color}{color:#cc}:
> Cannot find component for expression
> {color}{color:#ce9178}":willThrowException"{color}{color:#cc} referenced
> from {color}{color:#ce9178}"submit"{color}{color:#cc}.{color}
> {color:#ce9178} at
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.resolveClientIds(SearchExpressionHandlerImpl.java:179){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.appendIds(AjaxScriptBuilder.java:279){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:205){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.AjaxScriptBuilder.build(AjaxScriptBuilder.java:117){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:71){color}
> {color:#ce9178} at
> jakarta.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:92){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.appendClientBehaviourScript(ClientBehaviorRendererUtils.java:208){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.getClientBehaviorScript(ClientBehaviorRendererUtils.java:186){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:349){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.util.ClientBehaviorRendererUtils.buildBehaviorChain(ClientBehaviorRendererUtils.java:315){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.buildBehaviorizedOnClick(HtmlButtonRendererBase.java:340){color}
> {color:#ce9178} at
> org.apache.myfaces.renderkit.html.base.HtmlButtonRendererBase.encodeBegin(HtmlButtonRendererBase.java:186){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:561){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:495){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> jakarta.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519){color}
> {color:#ce9178} at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1783){color}
> {color:#ce9178} at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316){color}
> {color:#ce9178} at
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122){color}
> {color:#ce9178} at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241){color}
> {color:#ce9178} at
> jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225){color}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4631) DuplicateIdException via addComponentResource
[
https://issues.apache.org/jira/browse/MYFACES-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4631.
Resolution: Fixed
> 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
>
>
> 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] [Resolved] (MYFACES-4634) Exception when processing attribute-extension property in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4634. Resolution: Fixed > Exception when processing attribute-extension property in faces-config.xml > -- > > Key: MYFACES-4634 > URL: https://issues.apache.org/jira/browse/MYFACES-4634 > Project: MyFaces Core > Issue Type: Bug >Reporter: James McLeod >Priority: Major > Fix For: 4.0.2, 2.3-next-M9, 4.1.0 > > Attachments: faces-config_xml-exception.patch > > > The exception is > Oct 03, 2023 8:58:01 A.M. > org.apache.myfaces.config.DefaultFacesConfigurationProvider > getWebAppFacesConfig > INFO: Reading config /WEB-INF/faces-config.xml > Oct 03, 2023 8:58:01 A.M. org.apache.myfaces.webapp.FacesInitializerImpl > initFaces > SEVERE: An error occured while initializing MyFaces: > java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" > because "this.attributeExtensions" is null > jakarta.faces.FacesException: java.lang.NullPointerException: Cannot invoke > "java.util.List.add(Object)" because "this.attributeExtensions" is null > at > org.apache.myfaces.config.impl.FacesConfigUnmarshallerImpl.getFacesConfig(FacesConfigUnmarshallerImpl.java:180) > at > org.apache.myfaces.config.impl.FacesConfigUnmarshallerImpl.getFacesConfig(FacesConfigUnmarshallerImpl.java:77) > at > org.apache.myfaces.config.DefaultFacesConfigurationProvider.getWebAppFacesConfig(DefaultFacesConfigurationProvider.java:399) > at > org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:76) > at > org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:468) > at > org.apache.myfaces.webapp.FacesInitializerImpl.buildConfiguration(FacesInitializerImpl.java:382) > at > org.apache.myfaces.webapp.FacesInitializerImpl.initContainerIntegration(FacesInitializerImpl.java:709) > at > org.apache.myfaces.webapp.FacesInitializerImpl.initFaces(FacesInitializerImpl.java:179) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:54) > at > org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:1046) > at > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:624) > at > org.eclipse.jetty.server.handler.ContextHandler.contextInitialized(ContextHandler.java:983) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:740) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:392) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1305) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:902) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:306) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:533) > at > org.eclipse.jetty.maven.plugin.MavenWebAppContext.doStart(MavenWebAppContext.java:294) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:121) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:121) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at org.eclipse.jetty.server.Server.start(Server.java:470) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at org.eclipse.jetty.server.Server.doStart(Server.java:415) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.maven.plugin.JettyEmbedder.doStart(JettyEmbedder.java:223) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at >
[jira] [Resolved] (MYFACES-4633) Suspicious Logic when setting BeanManager from JNDI
[
https://issues.apache.org/jira/browse/MYFACES-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4633.
Resolution: Fixed
> Suspicious Logic when setting BeanManager from JNDI
> ---
>
> Key: MYFACES-4633
> URL: https://issues.apache.org/jira/browse/MYFACES-4633
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: James McLeod
>Priority: Major
> Fix For: 4.0.2, 4.1.0
>
> Attachments: beanmanager-init-from-jndi.patch
>
>
> Function {{private}} BeanManager lookupBeanManagerFromJndi() in
> [FacesInitializerImpl|https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/webapp/FacesInitializerImpl.java]
> (specifically [line 594 of the current
> version|https://github.com/apache/myfaces/blob/7905297aee87def27bd77975e07545f2e59aa357/impl/src/main/java/org/apache/myfaces/webapp/FacesInitializerImpl.java#L594]
> looks incorrect to me.
> The logic in the function is:
> # Try to retrieve {{beanManager}} as {{java:comp/BeanManager}} in
> {{InitialContext}}
> # If this succeeds (i.e. {{beanManager}} is non-null), try to retrieve
> {{beanManager}} as {{java:comp/env/BeanManager}} in {{InitialContext}}
> The second step should be done if the first attempt to retrieve
> {{beanManager}} fails, not if it succeeds. (If my interpretation is wrong, I
> think an explanatory comment is warranted here!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4634) Exception when processing attribute-extension property in faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772619#comment-17772619 ] Thomas Andraschko commented on MYFACES-4634: same here a PR for branches with the same codebase (4.1, 4.0, 2.3-next) would be great > Exception when processing attribute-extension property in faces-config.xml > -- > > Key: MYFACES-4634 > URL: https://issues.apache.org/jira/browse/MYFACES-4634 > Project: MyFaces Core > Issue Type: Bug >Reporter: James McLeod >Priority: Major > Attachments: faces-config_xml-exception.patch > > > The exception is > Oct 03, 2023 8:58:01 A.M. > org.apache.myfaces.config.DefaultFacesConfigurationProvider > getWebAppFacesConfig > INFO: Reading config /WEB-INF/faces-config.xml > Oct 03, 2023 8:58:01 A.M. org.apache.myfaces.webapp.FacesInitializerImpl > initFaces > SEVERE: An error occured while initializing MyFaces: > java.lang.NullPointerException: Cannot invoke "java.util.List.add(Object)" > because "this.attributeExtensions" is null > jakarta.faces.FacesException: java.lang.NullPointerException: Cannot invoke > "java.util.List.add(Object)" because "this.attributeExtensions" is null > at > org.apache.myfaces.config.impl.FacesConfigUnmarshallerImpl.getFacesConfig(FacesConfigUnmarshallerImpl.java:180) > at > org.apache.myfaces.config.impl.FacesConfigUnmarshallerImpl.getFacesConfig(FacesConfigUnmarshallerImpl.java:77) > at > org.apache.myfaces.config.DefaultFacesConfigurationProvider.getWebAppFacesConfig(DefaultFacesConfigurationProvider.java:399) > at > org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:76) > at > org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:468) > at > org.apache.myfaces.webapp.FacesInitializerImpl.buildConfiguration(FacesInitializerImpl.java:382) > at > org.apache.myfaces.webapp.FacesInitializerImpl.initContainerIntegration(FacesInitializerImpl.java:709) > at > org.apache.myfaces.webapp.FacesInitializerImpl.initFaces(FacesInitializerImpl.java:179) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:54) > at > org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:1046) > at > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:624) > at > org.eclipse.jetty.server.handler.ContextHandler.contextInitialized(ContextHandler.java:983) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:740) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:392) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1305) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:902) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:306) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:533) > at > org.eclipse.jetty.maven.plugin.MavenWebAppContext.doStart(MavenWebAppContext.java:294) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:121) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:121) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171) > at org.eclipse.jetty.server.Server.start(Server.java:470) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:89) > at org.eclipse.jetty.server.Server.doStart(Server.java:415) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93) > at > org.eclipse.jetty.maven.plugin.JettyEmbedder.doStart(JettyEmbedder.java:223) > at >
[jira] [Commented] (MYFACES-4633) Suspicious Logic when setting BeanManager from JNDI
[
https://issues.apache.org/jira/browse/MYFACES-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772603#comment-17772603
]
Thomas Andraschko commented on MYFACES-4633:
Can you do us a favor and provide a PR?
i think the same code should exist in 4.0.x and 2.3-next branch
> Suspicious Logic when setting BeanManager from JNDI
> ---
>
> Key: MYFACES-4633
> URL: https://issues.apache.org/jira/browse/MYFACES-4633
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: James McLeod
>Priority: Major
> Attachments: beanmanager-init-from-jndi.patch
>
>
> Function {{private}} BeanManager lookupBeanManagerFromJndi() in
> [FacesInitializerImpl|https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/webapp/FacesInitializerImpl.java]
> (specifically [line 594 of the current
> version|https://github.com/apache/myfaces/blob/7905297aee87def27bd77975e07545f2e59aa357/impl/src/main/java/org/apache/myfaces/webapp/FacesInitializerImpl.java#L594]
> looks incorrect to me.
> The logic in the function is:
> # Try to retrieve {{beanManager}} as {{java:comp/BeanManager}} in
> {{InitialContext}}
> # If this succeeds (i.e. {{beanManager}} is non-null), try to retrieve
> {{beanManager}} as {{java:comp/env/BeanManager}} in {{InitialContext}}
> The second step should be done if the first attempt to retrieve
> {{beanManager}} fails, not if it succeeds. (If my interpretation is wrong, I
> think an explanatory comment is warranted here!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4632) MyFaces doesnt not generate *.taglib.xml
[ https://issues.apache.org/jira/browse/MYFACES-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772478#comment-17772478 ] Thomas Andraschko commented on MYFACES-4632: dont think its the same, just the same source just check primefaces.taglib.xml, thats missing in MF API currently > MyFaces doesnt not generate *.taglib.xml > > > Key: MYFACES-4632 > URL: https://issues.apache.org/jira/browse/MYFACES-4632 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Priority: Major > > I was checking if this is rendered correclty: > https://github.com/jakartaee/faces/issues/1811 > but it seems that myfaces doesnt generate a taglib.xml > i checked our codebase a bit and it seems that the "myfaces-faces-plugin" can > generate one, but this was mainly used for pre JSF2 AFAICS > myfaces-builder-plugin, which generates our component classes based on this > annotations, doesnt have this feature?! > TBH i dont know what we should do > maybe take the myfaces-builder-plugin, refactor it completely, add taglib.xml > generation and host it as submodule of myfaces-core? > i dont like to have it in a seperate module, release lifecycle and so on > just pain in the past and now its only used anymore in MF core > another way would be to get rid of the whole generation > but this is likely just more work > anyone interessted? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4632) MyFaces doesnt not generate *.taglib.xml
Thomas Andraschko created MYFACES-4632: -- Summary: MyFaces doesnt not generate *.taglib.xml Key: MYFACES-4632 URL: https://issues.apache.org/jira/browse/MYFACES-4632 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Andraschko I was checking if this is rendered correclty: https://github.com/jakartaee/faces/issues/1811 but it seems that myfaces doesnt generate a taglib.xml i checked our codebase a bit and it seems that the "myfaces-faces-plugin" can generate one, but this was mainly used for pre JSF2 AFAICS myfaces-builder-plugin, which generates our component classes based on this annotations, doesnt have this feature?! TBH i dont know what we should do maybe take the myfaces-builder-plugin, refactor it completely, add taglib.xml generation and host it as submodule of myfaces-core? i dont like to have it in a seperate module, release lifecycle and so on just pain in the past another way would be to get rid of the whole generation but this is likely just more work anyone interessted? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4581) Felix Bundle ConcurrentModificationException
[
https://issues.apache.org/jira/browse/MYFACES-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771783#comment-17771783
]
Thomas Andraschko commented on MYFACES-4581:
[~melloware] can we close?
> Felix Bundle ConcurrentModificationException
>
>
> Key: MYFACES-4581
> URL: https://issues.apache.org/jira/browse/MYFACES-4581
> Project: MyFaces Core
> Issue Type: Bug
> Components: build process
>Affects Versions: 4.0.0
>Reporter: Melloware
>Assignee: Melloware
>Priority: Major
>
> Running `mvn clean install` locally on my machine I get
> `ConcurrentModificationExcepiton` in the Felix plugin. Bumping to 5.1.8
> fixes the issue.
>
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\Tools\apache-maven-3.9.0
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: C:\Tools\jdk-17
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko edited comment on MYFACES-4629 at 9/30/23 1:33 PM: - Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for PhaseId#RENDER_RESPONSE, not for validating and so on. Thats the bug. So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. was (Author: tandraschko): Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on. Thats the bug. So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) Manual AJAX request does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko edited comment on MYFACES-4629 at 9/30/23 1:33 PM: - Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on. Thats the bug. So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. was (Author: tandraschko): Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. > Manual AJAX request does not process TabView correctly > -- > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) PrimeFaces.ajax.Request.handle does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko edited comment on MYFACES-4629 at 9/30/23 1:32 PM: - Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. was (Author: tandraschko): Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. Im almost sure it is the same if you have e.g. a h:outputPanel with a input and manually send a AJAX request with the outputPanel as source. > PrimeFaces.ajax.Request.handle does not process TabView correctly > - > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4629) PrimeFaces.ajax.Request.handle does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko edited comment on MYFACES-4629 at 9/30/23 1:26 PM: - Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. Im almost sure it is the same if you have e.g. a h:outputPanel with a input and manually send a AJAX request with the outputPanel as source. was (Author: tandraschko): Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. > PrimeFaces.ajax.Request.handle does not process TabView correctly > - > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4629) PrimeFaces.ajax.Request.handle does not process TabView correctly
[ https://issues.apache.org/jira/browse/MYFACES-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770711#comment-17770711 ] Thomas Andraschko commented on MYFACES-4629: Just some notes if: If you check PartialViewContext#processPartialExecute it contains the tabView Id - but the UITabPanel#process is only invoked for rendering, not for validating and so on So something between is the reason, you may debug it. Another class involved is: PartialVisitContext It MIGHT MAYBE even by design: you set the TabView as AJAX source but only UIComand components or f:ajax can trigger this; so a plain TabView actually not - but not sure if we have something. > PrimeFaces.ajax.Request.handle does not process TabView correctly > - > > Key: MYFACES-4629 > URL: https://issues.apache.org/jira/browse/MYFACES-4629 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1 >Reporter: Manuel K >Priority: Critical > Attachments: pf-tabview.zip > > > When manually calling PrimeFaces.ajax.Request.handle the validationFailed > argument is not sent to the client. > For more details and a reproducer please see > https://github.com/orgs/primefaces/discussions/123 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770702#comment-17770702
]
Thomas Andraschko commented on MYFACES-4536:
[~melloware] can you try to add a unittest here in MF?
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770702#comment-17770702
]
Thomas Andraschko edited comment on MYFACES-4536 at 9/30/23 12:13 PM:
--
[~melloware] can you try to add a unittest here in MF? I can also have a look
then.
was (Author: tandraschko):
[~melloware] can you try to add a unittest here in MF?
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770700#comment-17770700
]
Thomas Andraschko commented on MYFACES-4536:
JFYI the last linked link is not related to this issue, so please ignore
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
>Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
>Reporter: Melloware
>Assignee: Werner Punz
>Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
