Markus Jung created TOMEE-4644:
----------------------------------
Summary: Faces config parser rejects XSI schemaLocation on https
namespace
Key: TOMEE-4644
URL: https://issues.apache.org/jira/browse/TOMEE-4644
Project: TomEE
Issue Type: Bug
Reporter: Markus Jung
h2. Summary
faces-config.xml unmarshaller fails on the https XSI schemaLocation attribute
Faces 4.1 uses
h2. Description
TomEE's faces-config.xml unmarshaller, {{ReadDescriptors.readFacesConfig}},
rejects the {{schemaLocation}} attribute when it sits on the
{{https://www.w3.org/2001/XMLSchema-instance}} namespace. Faces 4.1 descriptors
declare {{schemaLocation}} on this exact namespace, so deployment fails to
unmarshal the file.
The failure only shows up when the descriptor has child content. A bare
{{<faces-config>}} element with no children deploys fine even with the same
https namespace and attribute. Once the descriptor carries a child element,
such as {{<faces-config-extension>}}, the parser takes a stricter path and the
unknown attribute breaks it.
This is why only one test in the affected group fails.
{{headAndBodyRenderer/Spec1760IT}} has a {{<faces-config-extension>}} in its
faces-config.xml and hits the strict path. The sibling tests
{{uiRepeat/Spec1263IT}} and {{uuidConverter/Spec1819IT}} use the same https
namespace but on an empty {{<faces-config>}}, so they deploy and pass.
h2. Steps to reproduce / TCK reference
* TCK test: {{faces41/headAndBodyRenderer/Spec1760IT}}
* Deploy any Faces 4.1 app whose faces-config.xml declares the
{{https://www.w3.org/2001/XMLSchema-instance}} namespace with a
{{schemaLocation}} attribute AND has child content (e.g.
{{<faces-config-extension>}}) inside {{<faces-config>}}.
* Deployment fails during unmarshalling in {{ReadDescriptors.readFacesConfig}}.
* Currently excluded in {{runner-standalone/exclusions/faces.txt}} in the
apache/tomee-tck harness repo. Remove the entry there once fixed.
* For contrast, {{uiRepeat/Spec1263IT}} and {{uuidConverter/Spec1819IT}} use
the same namespace on an empty {{<faces-config>}} and already pass, confirming
the child-content path is what triggers the bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)