[jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2260) Header Content Injection Patch

Header Content Injection Patch ------------------------------ Key: JBPORTAL-2260 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2260 Project: JBoss Portal Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 2.7.0 Final Reporter: Dan Krieger Priority: Minor Problem was addressed on user forum here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=145564 Seems the error can be a bit tricky to track down due to different implementations of org.w3c.dom.Element being used. Here's my explanation from the forum: PortletResponseImpl creates an element based on the default document factory for your java implementation. In my case I get back an instance of org.apache.xerces.dom.ElementImpl Inside of HeaderContentTagHandler when its going through the list of header elements, it simply appends the element to the output buffer. This forces a toString() call on the element. This is where the randomness may occur depending on the implementation. I looked at the latest xerces source and the toString() implementation in NodeImpl (parent class for ElementImpl which contains toString() function) doesn't actually output the element in xml format, but instead is for debug purposes only: [code] // // Object methods // /** NON-DOM method for debugging convenience. */ public String toString() { return "["+getNodeName()+": "+getNodeValue()+"]"; } [/code] I found a solution using Xerces to do the serializing. Its not that elegant of a solution, but it seems many of the elements that are injected via jboss-portlet.xml injection method are W3C Elements that throw UnsupportedOperationException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira