I have some questions about the final fix for TUSCANY-2463 which provides
support for handling non-standard attributes on standard SCA XML elements.
BaseAssemblyProcessor has these 2 methods:
protected void readExtendedAttributes(XMLStreamReader reader, QName
elementName, Extensible estensibleElement, StAXAttributeProcessor
extensionAttributeProcessor) throws ContributionReadException,
XMLStreamException {
for (int a = 0; a < reader.getAttributeCount(); a++) {
QName attributeName = reader.getAttributeName(a);
if( attributeName.getNamespaceURI() != null &&
attributeName.getNamespaceURI().length() > 0) {
if( !
elementName.getNamespaceURI().equals(attributeName.getNamespaceURI()) ) {
String attributeExtension = (String)
extensionAttributeProcessor.read(attributeName, reader);
estensibleElement.getExtensions().add(attributeExtension);
}
}
}
}
protected void writeExtendedAttributes(XMLStreamWriter writer,
Extensible extensibleElement, StAXAttributeProcessor
extensionAttributeProcessor) throws ContributionWriteException,
XMLStreamException {
for(Object o : extensibleElement.getExtensions()) {
//FIXME How to identify it's a extended attribute ?
if(o instanceof String) {
extensionAttributeProcessor.write(o, writer);
}
}
}
Questions:
1) Why is readExtendedAttributes casting the object returned by the
processor to a String? How can one distinguish the attribute values if they
are all Strings? You can't tell which value came from which attribute. Can
the cast be removed?
2) Extensible.getExtensions() is used for both elements and attributes which
is going to cause problems. As the FIXME comment indicates, you don't know
if the extension is an attribute or not so you don't know if you should
write it here. Similarly when writing element extensions you don't know how
to skip over the attribute extensions. The original patch that I submitted
for this JIRA kept the attributes in a different list to avoid this problem.
Greg Dritschler
