[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=17848226#comment-17848226
]
SteGr commented on MYFACES-4667:
Kind of, yes.
Your found issue just mentions the restriction for renderers. But according to
BalusC, the spec does not mention the check on {{UIColumn}} for
{{{}invokeOnComponent{}}}. So this could be fixed without a spec change.
> 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|https://github.com/eclipse-ee4j/mojarra/issues/5445#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-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848222#comment-17848222
]
Melloware commented on MYFACES-4667:
Oh good point it might be!
> 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|https://github.com/eclipse-ee4j/mojarra/issues/5445#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-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-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848204#comment-17848204
]
Melloware commented on MYFACES-4667:
Mojarra fix: https://github.com/eclipse-ee4j/mojarra/pull/5446
> 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] [Created] (MYFACES-4667) UIData#invokeOnComponent does not find components
SteGr created MYFACES-4667:
--
Summary: 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
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] [Created] (TOBAGO-2314) SelectOneList, SelectManyList: dropdown menu is not removed after ajax reload
Henning Nöth created TOBAGO-2314: Summary: SelectOneList, SelectManyList: dropdown menu is not removed after ajax reload Key: TOBAGO-2314 URL: https://issues.apache.org/jira/browse/TOBAGO-2314 Project: MyFaces Tobago Issue Type: Bug Components: Core, JavaScript Affects Versions: 6.4.0, 5.12.0 Reporter: Henning Nöth -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2313) Popover: option for keep popover in foreground
Henning Nöth created TOBAGO-2313: Summary: Popover: option for keep popover in foreground Key: TOBAGO-2313 URL: https://issues.apache.org/jira/browse/TOBAGO-2313 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 6.4.0, 5.12.0 Reporter: Henning Nöth The popover component is closed if button looses focus. Add an option to keep the popover open. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2312) Select2: component with duplicate id exception
Henning Nöth created TOBAGO-2312: Summary: Select2: component with duplicate id exception Key: TOBAGO-2312 URL: https://issues.apache.org/jira/browse/TOBAGO-2312 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.5.1 Reporter: Henning Nöth If using MyFaces 2.0.16 or lower, the usage of the selectOneChoice and selectManyBox component may lead to a "component with duplicate id" exception. This is related to the select2 implementation. The issue can be reproduced in the Tobago select/select2 demo. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2311) SelectOneList/selectManyList: gray out disabled items
Henning Nöth created TOBAGO-2311: Summary: SelectOneList/selectManyList: gray out disabled items Key: TOBAGO-2311 URL: https://issues.apache.org/jira/browse/TOBAGO-2311 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Disabled items have no other color. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4654) Investigate Jakarta Schema Xsd Files Updates for 4.1
[ https://issues.apache.org/jira/browse/MYFACES-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845038#comment-17845038 ] Volodymyr Siedlecki commented on MYFACES-4654: -- Looks like only bean.xml is final. This Jira may be pushed back into a further release. > Investigate Jakarta Schema Xsd Files Updates for 4.1 > > > Key: MYFACES-4654 > URL: https://issues.apache.org/jira/browse/MYFACES-4654 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1 >Reporter: Volodymyr Siedlecki >Priority: Major > Fix For: 4.1.0-RC3 > > > Not sure if we need any updates, but we should look into it. > [https://github.com/apache/myfaces/tree/4.1.x/impl/src/main/resources/org/apache/myfaces/resource] > > It doesn't look like any changes changed for 4.0 (maybe should have?) > I don't see any updates for EE11: > [https://jakarta.ee/xml/ns/jakartaee/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4665) @BeforeDestroyed Not Implemented for 4.1
[ https://issues.apache.org/jira/browse/MYFACES-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4665. -- Resolution: Fixed > @BeforeDestroyed Not Implemented for 4.1 > > > Key: MYFACES-4665 > URL: https://issues.apache.org/jira/browse/MYFACES-4665 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC2 >Reporter: Volodymyr Siedlecki >Assignee: Volodymyr Siedlecki >Priority: Major > > @Initialized and @Destroyed were completed in MYFACES-4506 but not for > @BeforeDestroyed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2307) Lazy sheet does not fetch entries when using column panel
[ https://issues.apache.org/jira/browse/TOBAGO-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2307. -- Fix Version/s: 5.12.0 6.4.0 Resolution: Fixed > Lazy sheet does not fetch entries when using column panel > - > > Key: TOBAGO-2307 > URL: https://issues.apache.org/jira/browse/TOBAGO-2307 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.11.0, 6.3.0 >Reporter: Marcus Kroeger >Assignee: Henning Nöth >Priority: Major > Fix For: 5.12.0, 6.4.0 > > > When using a column panel within the sheet, the lazy loading does not fetch > entries -- 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=17844695#comment-17844695
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
This problem occurred in our OSGI environment with an absence of the web.xml
(servlet looks to be added dynamically), and we have a fix (add the class to
the thread context loader) .
But I agree – let's keep it in.
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [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] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679
]
Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:45 PM:
--
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
{code:java}
// code placeholder
globalEval(code: string, nonce ?: string): DomQuery {
const head = document.getElementsByTagName("head")?.[0]
?? document.documentElement.getElementsByTagName("head")?.[0];
const script = document.createElement("script");
if (nonce) {
if ('undefined' != typeof script?.nonce) {
script.nonce = nonce;
} else {
script.setAttribute("nonce", nonce);
}
}
script.type = "text/javascript";
script.innerHTML = code;
let newScriptElement = head.appendChild(script);
head.removeChild(newScriptElement);
return this;
} {code}
What happens here is at the moment the script is appended it gets evaled by the
browser engine, and once evaled it is removed...
was (Author: werpu):
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:43 PM: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! Btw forgot, the modern eval method for scripts is to append them to the head and clear them out again, that way the browser safely can do the eval! All 3 implementations of the scripts nowadays use this method for evaling js! Might play into this, but this is just a sidenote! was (Author: werpu): Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz commented on MYFACES-4378: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:39 PM: -- I just checked our scripts, there is no dedicated handling of a javax.faces.Resource field... If there is one, it would only get executed/evaled automatically if it is of type script type="text/javascript" in this case the eval would not be needed, in the second case if there is an eval, then a script type="text/javascript" id="javax.faces.Resource" is pointless and you would get a double eval, but the culprit here is a renderer sending such a response! the namespace javax.faces.Resource normally is for resource requests not render areas, but using it is not a spec violation to my knowledge, any id on a script would have produced the same result! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844676#comment-17844676 ] Melloware commented on MYFACES-4378: I totally agree and the behavior you describe is what Mojarra does. Resource is only for resources not for scripts. > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844675#comment-17844675
]
Volodymyr Siedlecki edited comment on MYFACES-4666 at 5/8/24 2:33 PM:
--
[~tandraschko] We can leave it as is, but hoping you could provide some more
information?
was (Author: volosied):
[~tandraschko] We have leave it as is, but hoping you could provide some more
information?
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:32 PM: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- 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=17844675#comment-17844675
]
Volodymyr Siedlecki commented on MYFACES-4666:
--
[~tandraschko] We have leave it as is, but hoping you could provide some more
information?
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
Volodymyr Siedlecki created MYFACES-4666:
Summary: ClassUtils.simpleClassForName Throws
ClassNotFoundException
Key: MYFACES-4666
URL: https://issues.apache.org/jira/browse/MYFACES-4666
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC1
Reporter: Volodymyr Siedlecki
We noticed a new exception in Faces 4.1:
{code:java}
jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
at
org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
at
org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
at
org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
at
org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
This did not occur in 4.0. It only introduced with this change:
[https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
true is now passed into simpleClassForName which throws the exception:
[https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
Was this intentional for any specific scenario? Is an exception appropriate
here? We didn't have this before, so I'm wondering if this is needed in 4.1?
Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz commented on MYFACES-4378: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844642#comment-17844642
]
Melloware commented on MYFACES-4378:
[~werpu] yes i don't think its your TS I was just wondering what s weird about
the issue is that Myfaces is sending the script back in both
`javax.faces.Resource` and in `EVAL` sections which to me is the bug. It
should only be in the `` section in this scenario.
{code:java}
{code}
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4665) @BeforeDestroyed Not Implemented for 4.1
Volodymyr Siedlecki created MYFACES-4665: Summary: @BeforeDestroyed Not Implemented for 4.1 Key: MYFACES-4665 URL: https://issues.apache.org/jira/browse/MYFACES-4665 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC2 Reporter: Volodymyr Siedlecki @Initialized and @Destroyed were completed in MYFACES-4506 but not for @BeforeDestroyed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:33 PM: -- Well, I dont think the new typescript based myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:32 PM: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz commented on MYFACES-4378: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843567#comment-17843567
]
Melloware edited comment on MYFACES-4378 at 5/5/24 1:48 PM:
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
[~werpu] you may be interested in this as well...
was (Author: melloware):
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843567#comment-17843567
]
Melloware commented on MYFACES-4378:
Reopened with simple reproducer provided:
[https://github.com/omnifaces/omnifaces/issues/804]
Reported in PrimeFaces: [https://github.com/primefaces/primefaces/issues/11780]
Because PrimeFaces constantly appends to the `head` this will eventually cause
the browser to fill up the head making the DOM slower and slower if you are on
a page with AJAX constantly.
{code:java}
else if (id === PrimeFaces.ajax.RESOURCE) {
$('head').append(content);
} {code}
That was discovered in this issue:
[https://github.com/primefaces/primefaces/issues/11714]
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Task
>Affects Versions: 2.3.7, 2.3-next-M4, 3.0.0, 4.0.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware reopened MYFACES-4378: > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.7, 2.3-next-M4, 3.0.0, 4.0.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2306) SelectOneList, SelectManyList: scroll bar in tc:box
[ https://issues.apache.org/jira/browse/TOBAGO-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2306. -- Fix Version/s: 5.12.0 6.4.0 Resolution: Fixed > SelectOneList, SelectManyList: scroll bar in tc:box > --- > > Key: TOBAGO-2306 > URL: https://issues.apache.org/jira/browse/TOBAGO-2306 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Major > Fix For: 5.12.0, 6.4.0 > > > A tc:box get a vertical scrollbar if the dropdown menu is opened from a > tc:selectOneList or a tc:selectManyList component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2305) Sheet: tobago-auto-spacing might be added on label layout component
[ https://issues.apache.org/jira/browse/TOBAGO-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2305. -- Fix Version/s: 5.12.0 6.4.0 Resolution: Fixed > Sheet: tobago-auto-spacing might be added on label layout component > --- > > Key: TOBAGO-2305 > URL: https://issues.apache.org/jira/browse/TOBAGO-2305 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > Fix For: 5.12.0, 6.4.0 > > > The tobago-auto-spacing CSS class is added if a column panel contains a > second sheet. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2310) Always process collapsible state
Henning Nöth created TOBAGO-2310: Summary: Always process collapsible state Key: TOBAGO-2310 URL: https://issues.apache.org/jira/browse/TOBAGO-2310 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Henning Nöth Currently, the collapsible state is only processed when a command is executed with tc:operation. After the implementation of https://issues.apache.org/jira/browse/TOBAGO-2298, the collapsible state is also processed for popups in the update model phase in order to keep the current collapsible state when the backdrop is clicked. The state is only processed if the new value is "true" in order to keep the behavior the same. It is possible to open a box/panel/section without notifying the server. This should be changed. If a submit is executed, the current collapsible state should always be processed in the update model phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2308) Column selector does not select all entries when using column panel
Marcus Kroeger created TOBAGO-2308: -- Summary: Column selector does not select all entries when using column panel Key: TOBAGO-2308 URL: https://issues.apache.org/jira/browse/TOBAGO-2308 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Marcus Kroeger When using colunm panel in sheet, the column selector does not select all columns when clicking "all" checkbox -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2307) Lazy sheet does not fetch entries when using column panel
Marcus Kroeger created TOBAGO-2307: -- Summary: Lazy sheet does not fetch entries when using column panel Key: TOBAGO-2307 URL: https://issues.apache.org/jira/browse/TOBAGO-2307 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Marcus Kroeger When using a column panel within the sheet, the lazy loading does not fetch entries -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2309) Column Selector does not select all entries when using lazy sheet
Marcus Kroeger created TOBAGO-2309: -- Summary: Column Selector does not select all entries when using lazy sheet Key: TOBAGO-2309 URL: https://issues.apache.org/jira/browse/TOBAGO-2309 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Marcus Kroeger When using lazy loading within sheet, the column selector needs to select all entries, even they are not fetched yet. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2306) SelectOneList, SelectManyList: scroll bar in tc:box
Henning Nöth created TOBAGO-2306: Summary: SelectOneList, SelectManyList: scroll bar in tc:box Key: TOBAGO-2306 URL: https://issues.apache.org/jira/browse/TOBAGO-2306 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth A tc:box get a vertical scrollbar if the dropdown menu is opened from a tc:selectOneList or a tc:selectManyList component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
[ https://issues.apache.org/jira/browse/MYFACES-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Siedlecki resolved MYFACES-4664. -- Resolution: Fixed > Update Faces To Address 4.1 TCK Failures > > > Key: MYFACES-4664 > URL: https://issues.apache.org/jira/browse/MYFACES-4664 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Volodymyr Siedlecki >Priority: Major > > Creating a single Jira to cover the 3 issues below: > - Make the UUID Converter Implicit > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] > - Fix up rowStatePreserved in UIRepeat > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] > - Implement Spec 1760 > - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
[ https://issues.apache.org/jira/browse/MYFACES-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841344#comment-17841344 ] Volodymyr Siedlecki commented on MYFACES-4664: -- Spec 1760 in 4.1: [https://github.com/apache/myfaces/pull/708] rowStatePreserved in 4.1: [https://github.com/apache/myfaces/pull/701] UUID Converter Implicit in 4.1: https://github.com/apache/myfaces/pull/700 > Update Faces To Address 4.1 TCK Failures > > > Key: MYFACES-4664 > URL: https://issues.apache.org/jira/browse/MYFACES-4664 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Volodymyr Siedlecki >Priority: Major > > Creating a single Jira to cover the 3 issues below: > - Make the UUID Converter Implicit > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] > - Fix up rowStatePreserved in UIRepeat > - > [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] > - Implement Spec 1760 > - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4662) Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to the Faces Servlet
[
https://issues.apache.org/jira/browse/MYFACES-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841343#comment-17841343
]
Volodymyr Siedlecki commented on MYFACES-4662:
--
5.0: https://github.com/apache/myfaces/pull/709
> Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to
> the Faces Servlet
>
>
> Key: MYFACES-4662
> URL: https://issues.apache.org/jira/browse/MYFACES-4662
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.0.0, 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> While investigating the 4.1 TCK tests, a 404 was returned for some pages in
> the headAndBodyRenderer app. Only the `*.xhtml` extensions worked even though
> the servlet mappings were listed:
> web.xml:
> {code:java}
>
> facesServlet
>
>
> facesServlet
> *.xhtml
> *.xhtmlAsXhtml
> *.xhtmlAsXml
> {code}
> Turns out that our FaceletViewDeclarationLanguageStrategy class looked if
> *.xhtml matched, and if not, then it looked at any mappings set via
> jakarta.faces.FACELETS_VIEW_MAPPINGS. This isn't set in the app. Ultimately,
> FaceletViewDeclarationLanguageStrategy#handlesView returns false and since no
> VDL is found, the page fails to load.
> [https://github.com/apache/myfaces/blob/7f6fefb4b05ccf5272e6907397954f7d4db8f4d2/impl/src/main/java/org/apache/myfaces/view/facelets/FaceletViewDeclarationLanguageStrategy.java#L62-L76
>
> |https://github.com/jakartaee/faces/tree/4.1/tck/faces41/headAndBodyRenderer/src/main/webapp]
> I think we should update the code to look at the servlet mappings, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4664) Update Faces To Address 4.1 TCK Failures
Volodymyr Siedlecki created MYFACES-4664: Summary: Update Faces To Address 4.1 TCK Failures Key: MYFACES-4664 URL: https://issues.apache.org/jira/browse/MYFACES-4664 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.1.0-RC1, 5.0.0 Reporter: Volodymyr Siedlecki Creating a single Jira to cover the 3 issues below: - Make the UUID Converter Implicit - [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uuidConverter/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uuidConverter/Spec1819IT.java#L38] - Fix up rowStatePreserved in UIRepeat - [https://github.com/jakartaee/faces/blob/4.1/tck/faces41/uiRepeat/src/test/java/org/eclipse/ee4j/tck/faces/faces41/uiRepeat/Spec1263IT.java#L33] - Implement Spec 1760 - [https://github.com/jakartaee/faces/issues/1760] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [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=17839377#comment-17839377 ] Milan Siebenbürger commented on MYFACES-4660: - I made PR's for these branches. It would be great, if you could check it. milan > 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] [Resolved] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
[ https://issues.apache.org/jira/browse/MYFACES-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melloware resolved MYFACES-4663. Resolution: Fixed > Quarkus: Register RepeatStatus for reflection > - > > Key: MYFACES-4663 > URL: https://issues.apache.org/jira/browse/MYFACES-4663 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 4.0.2, 4.1.0-RC1, 5.0.0 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > This class " > org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if > reference in EL like reference in the `index` you get `method index not found > on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
[ https://issues.apache.org/jira/browse/MYFACES-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839104#comment-17839104 ] Melloware commented on MYFACES-4663: Fixed with: https://github.com/apache/myfaces/pull/702 > Quarkus: Register RepeatStatus for reflection > - > > Key: MYFACES-4663 > URL: https://issues.apache.org/jira/browse/MYFACES-4663 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 4.0.2, 4.1.0-RC1, 5.0.0 >Reporter: Melloware >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > This class " > org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if > reference in EL like reference in the `index` you get `method index not found > on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4663) Quarkus: Register RepeatStatus for reflection
Melloware created MYFACES-4663: -- Summary: Quarkus: Register RepeatStatus for reflection Key: MYFACES-4663 URL: https://issues.apache.org/jira/browse/MYFACES-4663 Project: MyFaces Core Issue Type: Improvement Components: Extension Feature Affects Versions: 4.1.0-RC1, 4.0.2, 5.0.0 Reporter: Melloware This class " org.apache.myfaces.view.facelets.component.RepeatStatus" is a POJO and if reference in EL like reference in the `index` you get `method index not found on RepeatStatus" in native mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4662) Update FaceletViewDeclarationLanguageStrategy to look at exact mappings to the Faces Servlet
Volodymyr Siedlecki created MYFACES-4662:
Summary: Update FaceletViewDeclarationLanguageStrategy to look at
exact mappings to the Faces Servlet
Key: MYFACES-4662
URL: https://issues.apache.org/jira/browse/MYFACES-4662
Project: MyFaces Core
Issue Type: Improvement
Reporter: Volodymyr Siedlecki
While investigating the 4.1 TCK tests, a 404 was returned for some pages in the
headAndBodyRenderer app. Only the `*.xhtml` extensions worked even though the
servlet mappings were listed:
web.xml:
{code:java}
facesServlet
jakarta.faces.webapp.FacesServlet
facesServlet
*.xhtml
*.xhtmlAsXhtml
*.xhtmlAsXml
{code}
Turns out that our FaceletViewDeclarationLanguageStrategy class looked if
*.xhtml matched, and if not, then it looked at any mappings set via
jakarta.faces.FACELETS_VIEW_MAPPINGS. This isn't set in the app.
[https://github.com/apache/myfaces/blob/7f6fefb4b05ccf5272e6907397954f7d4db8f4d2/impl/src/main/java/org/apache/myfaces/view/facelets/FaceletViewDeclarationLanguageStrategy.java#L62-L76
|https://github.com/jakartaee/faces/tree/4.1/tck/faces41/headAndBodyRenderer/src/main/webapp]
I think we should update it to look at the servlet mappings, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [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=17837835#comment-17837835
]
Melloware commented on MYFACES-4661:
I just tested with 2.3-next-M9-SNAPSHOT and can confirm its fixed `Caused by:
javax.faces.component.search.ComponentNotFoundException: Cannot find component
for expression ":subview1:txtString" referenced from "frmTest:j_id_k".`
> 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] [Resolved] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Melloware resolved MYFACES-4661.
Resolution: Duplicate
> 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-4624) SearchExpressions must fail when component in viewroot is not resolvable
[ https://issues.apache.org/jira/browse/MYFACES-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837834#comment-17837834 ] Melloware commented on MYFACES-4624: I just tested with 2.3-next-M9-SNAPSHOT and can confirm its fixed `Caused by: javax.faces.component.search.ComponentNotFoundException: Cannot find component for expression ":subview1:txtString" referenced from "frmTest:j_id_k".` > SearchExpressions must fail when component in viewroot is not resolvable > > > Key: MYFACES-4624 > URL: https://issues.apache.org/jira/browse/MYFACES-4624 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1 > > > when using something like: > ``` > > > > > ``` > the result was that it was resolved to "j_id__v_0" instead of throwing a > ComponentNotFoundException > ":mainForm:input" would be the right expression -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-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] [Created] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
Melloware created MYFACES-4661:
--
Summary: 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: 4.1.0-RC1, 4.0.2, 2.3-next-M8, 3.0.2, 2.3.10
Reporter: Melloware
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] [Created] (TOBAGO-2305) Sheet: tobago-auto-spacing might be added on label layout component
Henning Nöth created TOBAGO-2305: Summary: Sheet: tobago-auto-spacing might be added on label layout component Key: TOBAGO-2305 URL: https://issues.apache.org/jira/browse/TOBAGO-2305 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth The tobago-auto-spacing CSS class is added if a column panel contains a second sheet. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TOBAGO-2304) Update jsoup to 1.15.3
[ https://issues.apache.org/jira/browse/TOBAGO-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837150#comment-17837150 ] Timur Muslimov commented on TOBAGO-2304: Thank you, but I didn't found it in your release notes or in closed tasks: https://issues.apache.org/jira/browse/TOBAGO-2134?jql=project%20%3D%20TOBAGO%20AND%20fixVersion%20in%20(2.5.0%2C%202.5.1) > Update jsoup to 1.15.3 > -- > > Key: TOBAGO-2304 > URL: https://issues.apache.org/jira/browse/TOBAGO-2304 > Project: MyFaces Tobago > Issue Type: Task >Reporter: Timur Muslimov >Assignee: Henning Nöth >Priority: Major > > Because of the issue in the current version - > [CVE-2022-36033|https://nvd.nist.gov/vuln/detail/CVE-2022-36033]: > jsoup is a Java HTML parser, built for HTML editing, cleaning, scraping, and > cross-site scripting (XSS) safety. jsoup may incorrectly sanitize HTML > including `javascript:` URL expressions, which could allow XSS attacks when a > reader subsequently clicks that link. If the non-default > `SafeList.preserveRelativeLinks` option is enabled, HTML including > `javascript:` URLs that have been crafted with control characters will not be > sanitized. If the site that this HTML is published on does not set a Content > Security Policy, an XSS attack is then possible. This issue is patched in > jsoup 1.15.3. Users should upgrade to this version. Additionally, as the > unsanitized input may have been persisted, old content should be cleaned > again using the updated version. To remediate this issue without immediately > upgrading: - disable `SafeList.preserveRelativeLinks`, which will rewrite > input URLs as absolute URLs - ensure an appropriate [Content Security > Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is defined. > (This should be used regardless of upgrading, as a defence-in-depth best > practice.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2304) Update jsoup to 1.15.3
Timur Muslimov created TOBAGO-2304: -- Summary: Update jsoup to 1.15.3 Key: TOBAGO-2304 URL: https://issues.apache.org/jira/browse/TOBAGO-2304 Project: MyFaces Tobago Issue Type: Task Reporter: Timur Muslimov Assignee: Henning Nöth Because of the issue in the current version - [CVE-2022-31160|https://nvd.nist.gov/vuln/detail/CVE-2022-31160]: jQuery UI is a curated set of user interface interactions, effects, widgets, and themes built on top of jQuery. Versions prior to 1.13.2 are potentially vulnerable to cross-site scripting. Initializing a checkboxradio widget on an input enclosed within a label makes that parent label contents considered as the input label. Calling `.checkboxradio( "refresh" )` on such a widget and the initial HTML contained encoded HTML entities will make them erroneously get decoded. This can lead to potentially executing JavaScript code. The bug has been patched in jQuery UI 1.13.2. To remediate the issue, someone who can change the initial HTML can wrap all the non-input contents of the `label` in a `span`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2303) Update jQuery UI to 1.13.2
Timur Muslimov created TOBAGO-2303: -- Summary: Update jQuery UI to 1.13.2 Key: TOBAGO-2303 URL: https://issues.apache.org/jira/browse/TOBAGO-2303 Project: MyFaces Tobago Issue Type: Task Reporter: Timur Muslimov Assignee: Henning Nöth Fix For: 2.4.5, 4.5.5 Because of some issues in the current version. CVE-2021-41182 CVE-2021-41183 CVE-2021-41184 -- 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=17836641#comment-17836641 ] Melloware commented on MYFACES-4659: Sorry i fixed it! > 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: 2.3.11, 3.0.3, 2.3-next-M9, 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-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] [Resolved] (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:all-tabpanel ] Melloware resolved MYFACES-4659. Resolution: Fixed > 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] [Resolved] (TOBAGO-2298) Backdrop attribute for popups
[ https://issues.apache.org/jira/browse/TOBAGO-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2298. -- Fix Version/s: 5.12.0 6.4.0 Resolution: Fixed > Backdrop attribute for popups > - > > Key: TOBAGO-2298 > URL: https://issues.apache.org/jira/browse/TOBAGO-2298 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Major > Fix For: 5.12.0, 6.4.0 > > > Add a backdrop attribute for popups. Currently the backdrop attribute for the > Bootstrap modal component is always "static". This should be configurable in > the tobago-config.xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2302) sheet: select row is broken is using column panel
Henning Nöth created TOBAGO-2302: Summary: sheet: select row is broken is using column panel Key: TOBAGO-2302 URL: https://issues.apache.org/jira/browse/TOBAGO-2302 Project: MyFaces Tobago Issue Type: Bug Components: JavaScript Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Sometime the column panel cannot be deselected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2301) Show/hide column panel by click
Henning Nöth created TOBAGO-2301: Summary: Show/hide column panel by click Key: TOBAGO-2301 URL: https://issues.apache.org/jira/browse/TOBAGO-2301 Project: MyFaces Tobago Issue Type: New Feature Components: JavaScript Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth The tc:columnPanel is a horizontal panel all over the sheet. Currently the show/hide mechanismn only works with CSS. There should be a mechanism like tc:operation to hide/show the column panel by clicking on a button. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4660) WebSockets - view destroying + multiple tabs/windows
Milan Siebenbürger created MYFACES-4660: --- Summary: 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.2, 4.0.1, 4.0.0, 5.0.0 Reporter: Milan Siebenbürger 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] [Created] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
Melloware created MYFACES-4659: -- Summary: 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: 4.1.0-RC1, 4.0.2, 2.3-next-M8, 2.3.10 Reporter: Melloware 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] (TOBAGO-2226) Popover component
[ https://issues.apache.org/jira/browse/TOBAGO-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2226. -- Fix Version/s: 5.11.1 6.3.1 Resolution: Fixed > Popover component > - > > Key: TOBAGO-2226 > URL: https://issues.apache.org/jira/browse/TOBAGO-2226 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.7.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Major > Fix For: 5.11.1, 6.3.1 > > > Create a popover component. > https://getbootstrap.com/docs/5.3/components/popovers/ > There are already two features which use the Bootstrap popover component. > Once for error on a form component (like tc:in) and secondary the "help" > attribute. The configurability is not the best. For example it's not possible > to have an info button with a titleless popover. > We should create a which can be placed inside a or > . The may also be used to configure help/error buttons > on form components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4658.
--
Fix Version/s: 5.0.0
4.1.0-RC2
4.0.3
Resolution: Fixed
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833954#comment-17833954
]
Werner Punz commented on MYFACES-4658:
--
[~volosied] I have fixed the issue in the 3 attached pull requests (each for
each branch which uses the new codebase) please give it a shot, and if it works
for you then I can merge!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:15 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
Should be an easy fix, expect it later today!
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:14 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = r
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:09 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
>
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:08 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz commented on MYFACES-4658:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833668#comment-17833668
]
Werner Punz commented on MYFACES-4658:
--
Yes I will take care of it. I need to compare this with the spec as well!
Probably a slight deviation from the spec I have introduced here with my
rewrite!
Should be easy to fix!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4658) faces.util.chain behavior changed
Volodymyr Siedlecki created MYFACES-4658:
Summary: faces.util.chain behavior changed
Key: MYFACES-4658
URL: https://issues.apache.org/jira/browse/MYFACES-4658
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.0.2
Reporter: Volodymyr Siedlecki
Given the following generated HTML, an alert will occur. If you click OK, it
will perform an action on a backing bean. However, if you cancel, it should
not.
{code:java}
{code}
On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
Faces 4.0, however, pressing cancel *does* invoke the bean.
Faces 3.0:
jsf.util.chain snippet:
{noformat}
if (FUNC == typeof arguments[cnt]) {
ret = arguments[cnt].call(source, event);
} else {
//either a function or a string can be passed in case of a
string we have to wrap it into another function
ret = new Function("event", arguments[cnt]).call(source, event);
}
//now if one function returns false in between we stop the
execution of the cycle
//here, note we do a strong comparison here to avoid constructs
like 'false' or null triggering
if (ret === false /*undefined check implicitly done here by using a
strong compare*/) {
return false;
}
}{noformat}
Faces 4.0:
{noformat}
function chain(source, event, ...funcs) {
// we can use our lazy stream each functionality to run our chain here.
// by passing a boolean as return value into the onElem call
// we can stop early at the first false, just like the spec requests
let ret;
funcs.every(func => {
let returnVal = resolveAndExecute(source, event, func);
if (returnVal !== false) {
ret = returnVal;
}
return returnVal !== false;
});
return ret;
}{noformat}
It looks like conditions changed here? "ret === false" became "returnVal !==
false" ? If cancel is pressed, false is returned, which means the chain
function returns false in 3.0. In faces 4.0, ret is never set, so undefined is
returned.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833656#comment-17833656
]
Volodymyr Siedlecki commented on MYFACES-4658:
--
[~werpu] I'm not sure what the correct logic is here, so I'll assign this to
you.
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set, so undefined
> is returned.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2300) Icon attribute for buttons and links
Henning Nöth created TOBAGO-2300: Summary: Icon attribute for buttons and links Key: TOBAGO-2300 URL: https://issues.apache.org/jira/browse/TOBAGO-2300 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Currently there is only an "image" attribute for both, images (.jpg, .png,...) and icons (FontAwesome, BootstrapIcons). The decision if there is an image or an icon depends on a regular expression. This was fine when there was only FontAwesome4 as an icon library. But now there is a regular expression for BootstrapIcons, FontAwesome4, FA5 and FA6. We should introduce an "icon" attribute for icon librarys. Then the regular expressions might be removed in the next major release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2299) Aria-labelledby attribute on popup
Henning Nöth created TOBAGO-2299: Summary: Aria-labelledby attribute on popup Key: TOBAGO-2299 URL: https://issues.apache.org/jira/browse/TOBAGO-2299 Project: MyFaces Tobago Issue Type: Bug Components: Core, Themes Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Add aria-labelledby="...", referencing the modal title. Also check if aria-modal should be replaced with aria-hidden. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4657) servletRegistration.getClassName() may be null and cause an NPE
Volodymyr Siedlecki created MYFACES-4657:
Summary: servletRegistration.getClassName() may be null and cause
an NPE
Key: MYFACES-4657
URL: https://issues.apache.org/jira/browse/MYFACES-4657
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 4.1.0-RC1
Reporter: Volodymyr Siedlecki
{color:#cc}Stack Dump =
{color}{color:#ce9178}java.lang.NullPointerException{color}{color:#cc}:
type is {color}{color:#569cd6}null{color}{color:#cc}.{color}
{color:#ce9178} at
org.apache.myfaces.core.api.shared.lang.Assert.notNull(Assert.java:35){color}
{color:#ce9178} at
org.apache.myfaces.util.lang.ClassUtils.classForName(ClassUtils.java:207){color}
{color:#ce9178} at
org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:258){color}
{color:#ce9178} at
org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177){color}
{color:#ce9178} at
org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:326){color}
{color:#ce9178} at
org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){color}
{color:#ce9178}Introduced via
[https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213]
Web.xml Snippet to reproduce:
test.jsp
/test.jsp
test.jsp
/test.jsp
There is no servlet class in this scenario, so the code tries to search for a
null class name. {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2298) Backdrop attribute for popups
Henning Nöth created TOBAGO-2298: Summary: Backdrop attribute for popups Key: TOBAGO-2298 URL: https://issues.apache.org/jira/browse/TOBAGO-2298 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Add a backdrop attribute for popups. Currently the backdrop attribute for the Bootstrap modal component is always "static". This should be configurable in the tobago-config.xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2297) Sheet header: different font-weight calculation
[ https://issues.apache.org/jira/browse/TOBAGO-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2297. -- Fix Version/s: 5.11.1 6.3.1 Resolution: Fixed > Sheet header: different font-weight calculation > --- > > Key: TOBAGO-2297 > URL: https://issues.apache.org/jira/browse/TOBAGO-2297 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > Fix For: 5.11.1, 6.3.1 > > > The sheet header font-weight calculation is different, depending wether the > columns attribute is used. > If the columns attribute is NOT used, the browse style sheet set > "font-weight: bold" on "TH". > If the columns attribute IS used, Tobago set "font-weight: normal" on "TH" > and then set "font-weight: bold" on "tobago-out". > The font-weight style set for sheets with columns attribute should be > removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2297) Sheet header: different font-weight calculation
Henning Nöth created TOBAGO-2297: Summary: Sheet header: different font-weight calculation Key: TOBAGO-2297 URL: https://issues.apache.org/jira/browse/TOBAGO-2297 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth The sheet header font-weight calculation is different, depending wether the columns attribute is used. If the columns attribute is NOT used, the browse style sheet set "font-weight: bold" on "TH". If the columns attribute IS used, Tobago set "font-weight: normal" on "TH" and then set "font-weight: bold" on "tobago-out". The font-weight style set for sheets with columns attribute should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2296) Some FontAwesome 5 icons are renderes as image
[ https://issues.apache.org/jira/browse/TOBAGO-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2296. -- Fix Version/s: 5.11.1 6.3.1 Resolution: Fixed > Some FontAwesome 5 icons are renderes as image > -- > > Key: TOBAGO-2296 > URL: https://issues.apache.org/jira/browse/TOBAGO-2296 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Major > Fix For: 5.11.1, 6.3.1 > > > Tobago doesn't recognize "fab fa-elementor" as a FA5 icon. > See: https://fontawesome.com/v5/icons/elementor?f=brands=solid -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2296) Some FontAwesome 5 icons are broken
Henning Nöth created TOBAGO-2296: Summary: Some FontAwesome 5 icons are broken Key: TOBAGO-2296 URL: https://issues.apache.org/jira/browse/TOBAGO-2296 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Tobago doesn't recognize "fab fa-elementor" as a FA5 icon. See: https://fontawesome.com/v5/icons/elementor?f=brands=solid -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2295) Support FontAwesome 6
[
https://issues.apache.org/jira/browse/TOBAGO-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Nöth resolved TOBAGO-2295.
--
Fix Version/s: 5.11.1
6.3.1
Resolution: Fixed
> Support FontAwesome 6
> -
>
> Key: TOBAGO-2295
> URL: https://issues.apache.org/jira/browse/TOBAGO-2295
> Project: MyFaces Tobago
> Issue Type: New Feature
> Components: Core
>Affects Versions: 5.11.0, 6.3.0
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Major
> Fix For: 5.11.1, 6.3.1
>
>
> The following code must be used for FontAwesome 6, but an image is rendered
> instead of an icon.
> {code:xml}{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2295) Support FontAwesome 6
Henning Nöth created TOBAGO-2295:
Summary: Support FontAwesome 6
Key: TOBAGO-2295
URL: https://issues.apache.org/jira/browse/TOBAGO-2295
Project: MyFaces Tobago
Issue Type: New Feature
Components: Core
Affects Versions: 6.3.0, 5.11.0
Reporter: Henning Nöth
The following code must be used for FontAwesome 6, but an image is rendered
instead of an icon.
{code:xml}{code}
--
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=17828929#comment-17828929
]
chaloma1 commented on MYFACES-4656:
---
Hmm yes, you are correct. I was confused, because i was looking at the
stateHelper eval function, which for value expressions is getting
key.toString(), but not for literal values. Thank you.
> 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-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=17828307#comment-17828307
]
Melloware commented on MYFACES-4656:
IT looks like Mojarra submitted this PR
[https://github.com/eclipse-ee4j/mojarra/pull/5418] not sure if MyFaces has
similar code?
> 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] (TOBAGO-2294) CustomClass not rendered for tree listbox
[ https://issues.apache.org/jira/browse/TOBAGO-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Nöth resolved TOBAGO-2294. -- Fix Version/s: 5.11.1 6.3.1 Resolution: Fixed > CustomClass not rendered for tree listbox > - > > Key: TOBAGO-2294 > URL: https://issues.apache.org/jira/browse/TOBAGO-2294 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.11.0, 6.3.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > Fix For: 5.11.1, 6.3.1 > > > Using on has no effect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2294) CustomClass not rendered for tree listbox
Henning Nöth created TOBAGO-2294: Summary: CustomClass not rendered for tree listbox Key: TOBAGO-2294 URL: https://issues.apache.org/jira/browse/TOBAGO-2294 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 6.3.0, 5.11.0 Reporter: Henning Nöth Using on has no effect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
