Cay Horstmann wrote:

Originally, cc meant "the current composite component" as opposed to "the composite component in this implementation section. For example, consider a login component

 <composite:implementation>
  <util:labeledInputField label="Username" value="#{cc.attrs.name}"/>
  <util:labeledInputField label="Password" value="#{cc.attrs.password}"/>
 </composite:implementation>

Way back when, this wouldn't have worked IF util:labeledInputField was a composite component as well. In that case, cc would have been the labeledInputField, and it would have been necessary to use #{cc.parent.attrs.name} to get the login component's name attribute.

That was fragile. It required the implementor to know which components are composite. Stuff would break if you changed the implementation of a utility component--e.g. from a regular util:labeledInputField to a composite one or the other way around.

The EG then changed the definition of cc,

I am really glad that we changed this. :-)

but apparently nobody remembered to remove the special handling of cc.parent. It is in the spec and the implementation.

Okay, this seems like an oversight to me.  I have logged the following issue to request that we remove this from the spec:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=741

Any objections to making this change in the MR?

Cay - thanks so much for the detailed explanation.  Finally understand how we ended up with the currently specified behavior!