Hi Bauke,
I would be very careful with the notion of caching as you do not know 
the "shape" of the component tree.
May I ask why do you think you need to cache it?
Thanks!
Kind regards,
Manfred Riem
On 1/4/17, 11:53 AM, Bauke Scholtz wrote:
> Hi,
>
> Done: 
> https://java.net/projects/mojarra/sources/git/revision/bd9a9226de3d8d60cf8fd1b748c94e707c2355df
>
>      * ..., then skip validation for current component, else perform 
> standard
>      * superclass processing by 
> <code>super.processValidators(context</code>.</p>
>
> On a related note, Manfred, am I allowed to perform caching in the API 
> class to save potentially unnecessary component tree visits? Via a 
> private or public context attribute? Or is this prohibited to the 
> implementation?
>
> Cheers, B
>
>
>
> On Wed, Jan 4, 2017 at 6:56 PM, manfred riem <manfred.riem_at_oracle.com 
> <mailto:manfred.riem_at_oracle.com>> wrote:
>
>     Hi Bauke,
>
>     Please do so it is 100% clear.
>
>     Thanks!
>
>     Kind regards,
>     Manfred Riem
>
>     On 1/4/17, 10:50 AM, Bauke Scholtz wrote:
>>     Hi,
>>
>>     It does. Or should I explicitly mention that the else case must
>>     call super.processValidators()?
>>
>>     Cheers, B
>>
>>     On Tue, Jan 3, 2017 at 10:05 PM, manfred riem
>>     <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>>
>>         Hi Bauke,
>>
>>         Can you please verify this change stays inline with the
>>         master contract of processValidators()
>>
>>         Thanks!
>>
>>         Kind regards,
>>         Manfred Riem
>>
>>         On 12/29/16, 11:13 AM, Bauke Scholtz wrote:
>>>         Hi,
>>>
>>>         https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433 <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433>
>>>         caused an undesired side effect of the current
>>>         <h:selectOneRadio group> implementation: on a
>>>         <h:selectOneRadio group="..." required="true">, the required
>>>         message incorrectly shows up as many times as there are
>>>         radio buttons of the same group.
>>>
>>>         Therefore I have added UISelectOne#processValidators()
>>>         method with below API rules to get this right, regardless of
>>>         1433.
>>>
>>>             /**
>>>              * <p class="changed_added_2_3">If {_at_link #getGroup()}
>>>         is set, and {_at_link #getSubmittedValue()} is empty, and at
>>>              * least one other component having the same group
>>>         within a <code>UIForm</code> parent has a non-empty
>>>              * {_at_link #getSubmittedValue()} or returns
>>>         <code>true</code> on {_at_link #isLocalValueSet()} or returns
>>>              * <code>false</code> on {_at_link #isValid()}, then skip
>>>         validation for current component.</p>
>>>              */
>>>
>>>
>>>         If this needs more clarification, please let me know.
>>>
>>>         Cheers, B
>>>
>>>
>>>         On Wed, Sep 28, 2016 at 1:31 PM, Josh Juneau
>>>         <juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>> wrote:
>>>
>>>             Thanks for the update Bauke, excellent work!
>>>
>>>             Josh Juneau
>>>             juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>>>             http://jj-blogger.blogspot.com
>>>             https://www.apress.com/index.php/author/author/view/id/1866
>>>             <https://www.apress.com/index.php/author/author/view/id/1866>
>>>
>>>
>>>             On Wed, Sep 28, 2016 at 6:08 AM, Bauke Scholtz
>>>             <balusc_at_gmail.com <mailto:balusc_at_gmail.com>> wrote:
>>>
>>>                 Hi,
>>>
>>>                 The <h:selectOneRadio group> is finally done. Encode
>>>                 was trivial, but decode was after all tricky if you
>>>                 have to take all possible scenarios into account.
>>>                 Two main tricks were done here: 1) include
>>>                 component's client ID in HTML element value and 2)
>>>                 create a SelectItem wrapper which delegates to the
>>>                 right index of the parent.
>>>
>>>                 API is done as per
>>>                 https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329
>>>                 <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329>
>>>                 Impl is done as per
>>>                 https://java.net/jira/browse/JAVASERVERFACES-4188
>>>                 <https://java.net/jira/browse/JAVASERVERFACES-4188>
>>>
>>>                 Concrete use cases are shown in this comment:
>>>                 https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329?focusedCommentId=392914&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-392914
>>>                 <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329?focusedCommentId=392914&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-392914>
>>>
>>>                 Cheers, B
>>>
>>>                 On Mon, Aug 8, 2016 at 11:01 AM, Bauke Scholtz
>>>                 <balusc_at_gmail.com <mailto:balusc_at_gmail.com>> wrote:
>>>
>>>                     FYI: I will take this issue on me.
>>>
>>>                     Cheers, B
>>>
>>>                     On Wed, Sep 30, 2015 at 3:00 PM, Kito Mann
>>>                     <kito.mann_at_virtua.com
>>>                     <mailto:kito.mann_at_virtua.com>> wrote:
>>>
>>>                         I like the passthrough approach, but we
>>>                         should really provide a tag too. There are
>>>                         still plenty of people who don't use the
>>>                         pure HTML syntax (especially since it's not
>>>                         supported by third-party component libraries).
>>>
>>>                         ___
>>>
>>>                         Kito D. Mann | @kito99 | Author, JSF in Action
>>>                         Virtua, Inc. | http://www.virtua.com |
>>>                         JSF/Java EE training and consulting
>>>                         http://www.JSFCentral.com | @jsfcentral
>>>                         +1 203-998-0403 <tel:%2B1%20203-998-0403>
>>>
>>>                         * Listen to the Enterprise Java Newscast:
>>>                         _http://
>>>                         <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>                         <http://ww.enterprisejavanews.com>_
>>>                         * JSFCentral Interviews Podcast:
>>>                         http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>                         <http://www.jsfcentral.com/resources/jsfcentralpodcasts/>
>>>                         * Sign up for the JSFCentral Newsletter:
>>>                         http://oi.vresp.com/?fid=ac048d0e17
>>>                         <http://oi.vresp.com/?fid=ac048d0e17>
>>>
>>>                         On Mon, Sep 28, 2015 at 1:39 PM, Edward
>>>                         Burns <edward.burns_at_oracle.com
>>>                         <mailto:edward.burns_at_oracle.com>> wrote:
>>>
>>>                             >>>>> On Mon, 28 Sep 2015 13:55:21
>>>                             +0300, Cagatay Civici
>>>                             <cagatay.civici_at_gmail.com
>>>                             <mailto:cagatay.civici_at_gmail.com>> said:
>>>
>>>                             CC> I like this approach as well, better
>>>                             than what we have discussed so far.
>>>                             CC> +1,
>>>
>>>                             CC> So Bauke, do you propose we dont do
>>>                             anything since it can be already
>>>                             CC> solved with current APIs?
>>>
>>>                             I've asked the original poster, Ryan de
>>>                             Laplante, if he's satisfied with
>>>                             this approach.
>>>
>>>                             Either way, it's a pretty compelling
>>>                             endorsement of pass through
>>>                             elements and attributes.
>>>
>>>                             Ed
>>>
>>>                             --
>>>                             | edward.burns_at_oracle.com
>>>                             <mailto:edward.burns_at_oracle.com> |
>>>                             office: +1 407 458 0017
>>>                             <tel:%2B1%20407%20458%200017>
>>>                             | 28 Business days til JavaOne 2015
>>>                             | 43 Business days til DOAG 2015
>>>
>>>
>>>
>>>
>>>
>>>
>>
>