TCK Challenge: <f:metadata> must be a child of <f:view>

[brideck]

Challenged Tests: ee.jakarta.tck.faces.test.javaee7.protectedview.Bug22995287IT

TCK Version: Jakarta Faces 4.0.x

Tested Implementation: Open Liberty -- containing MyFaces 4.0

Description: The VDL doc for <f:metadata> states "This must be a child of the <f:view>." However, Page2 and Page3 in this test application both have it as a child of the <h:head> instead.

The specification is silent on what exactly is supposed to happen when this stipulation of the spec is violated. As pointed out in a Mojarra issue, MyFaces throws an exception in this case and Mojarra allows it. Accordingly, these tests fail for us with exceptions like the following:

Caused by: jakarta.faces.view.facelets.TagException: /page3.xhtml at line 31 and column 14 <f:metadata> Parent UIComponent j_id_5 should be instance of UIViewRoot
    at org.apache.myfaces.view.facelets.tag.faces.core.ViewMetadataHandler.apply(ViewMetadataHandler.java:60)
    at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
    at jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
    at org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
    at jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
    at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
    at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:67)
    at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
    at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
    at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
    at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:49)
    at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:195)
    at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:423)
    at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:83)
    at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
    ...

The consensus in the Mojarra issue seems to be that MyFaces behavior is the better one in this instance. Regardless, the TCK application should be rewritten in order to be in compliance with the specification.

[pnicolucci]

From my point of view, this is a valid challenge. @arjantijms @BalusC @tandraschko do you agree?

[pnicolucci]

@arjantijms @BalusC I wanted to call attention to this one and get your thoughts. Thanks!

[BalusC]

Valid.

And the spec needs to be updated to explicitly say "immediate child" or "direct child" instead of "child".

Because, especially in CSS terminology, f:view -> h:head -> f:metadata still makes the f:metadata a visible child of f:view.