DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23897>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23897 Xalan does not replace attributes with same expanded name ------- Additional Comments From [EMAIL PROTECTED] 2003-10-31 03:56 ------- Hi Richard, The output I get (except for indentation): <?xml version="1.0" encoding="UTF-8"?> <root> <Out xmlns:a="http://www.ped.com"; a:attr1="Wrong" xmlns:d="http://www.ped.com"; d:attr1="Test2-OK"/> </root> I think you were expecting this: <?xml version="1.0" encoding="UTF-8"?> <root> <Out xmlns:a="http://www.ped.com"; a:attr1="Test2-OK"/> </root> my gut feeling is that this has to do with the ToXMLTream.addAttributeAlways (...) method which starts like this: public void addAttributeAlways( String uri, String localName, String rawName, String type, String value) { int index; index = m_attributes.getIndex(rawName); if (index >= 0) { This method always adds an attribute, but if the attribute already exists then it replaces the value. It is searching if the attribute already exists based on the raw name "d:attr1" as a key rather than the uri/localName ( "http://www.ped.com"; / "attr1") as a key. It then thinks that both attributes are unique. I gave this a try: public void addAttributeAlways( String uri, String localName, String rawName, String type, String value) { int index; index = m_attributes.getIndex(rawName); if (index < 0) index = m_attributes.getIndex(uri,localName); if (index >= 0) { So it had a go using this change, which may be the right way to search. In this case the output was: <?xml version="1.0" encoding="UTF-8"?> <root> <Out xmlns:a="http://www.ped.com"; a:attr1="Test2-OK" xmlns:d="http://www.ped.com"/> </root> The value is OK now, but we still have the extra namespace for prefix 'd'. Is that a problem? I'm very worried about performance. This code was highly tuned in AttributesImplSerializer to deal with attibutes quickly and had a big impact, in a good way, on performance for 2.5.1. This extra check that I've thrown in will be a bad performance impact because most attributes are added only once, so we will be looking twice for virtually all attributes, and the lookup via uri/localName is not tuned. The underlying search is linear in the existing attribute list so this will introduce an order N*N impact for large number of attributes. I'm not suggesting to take my "patch" as-is. But it is in the right area. (Also I haven't tried this change out on any conformance bucket). - Brian
