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