Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.2.9-core
-
None
-
None
-
All environments
Description
The following is the current code in org.apache.myfaces.trinidad.change.SetFacetChildDocumentChange class:
public void changeDocument(Node componentNode)
{
if (componentNode == null)
throw new IllegalArgumentException(_LOG.getMessage(
"NO_NODE_SPECIFIED"));
// get the fragement, imported into the target document
DocumentFragment targetFragment = getImportedComponentFragment(componentNode);
Element facetElement = ChangeUtils.__getFacetElement(componentNode, _facetName);
if (facetElement != null)
{ // remove any current children ChangeUtils.__removeAllChildren(facetElement); }else
{ Document targetDocument = componentNode.getOwnerDocument(); facetElement = targetDocument.createElementNS(_JSF_CORE_NAMESPACE, "f:facet"); // ISSUE IS THAT THIS FACET ELEMENT DOES NOT HAVE 'name' ATTRIBUTE ON IT // set the xmlns for the prefix to make sure that "f:" is the // prefix for faces // =-= bts TODO In theory, this could cause problems if the // added component used the prefix "f:" for something other than // the JSF core facetElement.setAttributeNS(_XMLNS_NAMESPACE, "xmlns:f", _JSF_CORE_NAMESPACE); componentNode.appendChild(facetElement); } // add our new facet content
facetElement.appendChild(targetFragment);
}
When a new SetFacetChildDocumentChange is created and added to the change manager, and in case the target component did not have a facet already, a new facet element is created wrapping the supplied document fragment, and added. The problem, is that the 'name' attribute is added on the element, as indicated by comments in the code above. This results in parse exceptions by JSP engines.
Fix is to add the 'name' attribute. I'll provide a patch soon.