You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@gmail.com> on 2009/01/06 19:13:03 UTC
Questions about TUSCANY-2463
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
Re: Questions about TUSCANY-2463
Posted by Greg Dritschler <gr...@gmail.com>.
That probably will work, as long as the code in CompositeProcessor that
writes element extensions is not tripped up by it.
On Thu, Jan 8, 2009 at 5:34 PM, Luciano Resende <lu...@gmail.com>wrote:
>
> Independent of using a separate list or not, there is still an issue
> related to storing the attribute QName to be used during the write
> phase. How about we create a wrapper object that would have the
> attribute QName and it's value (e.g ExtendedAttribute) ? And then we
> could use the current list or if necessary use a separate one ?
>
> Thoughts ?
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: Questions about TUSCANY-2463
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Jan 6, 2009 at 10:13 AM, Greg Dritschler
<gr...@gmail.com> wrote:
> 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?
Looks like the string casting is being used to distinguish between
element and attribute extension, which I agree is wrong and I'll
remove based on the fix for the next item.
> 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
>
Independent of using a separate list or not, there is still an issue
related to storing the attribute QName to be used during the write
phase. How about we create a wrapper object that would have the
attribute QName and it's value (e.g ExtendedAttribute) ? And then we
could use the current list or if necessary use a separate one ?
Thoughts ?
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Questions about TUSCANY-2463
Posted by Luciano Resende <lu...@gmail.com>.
Hey Greg
I'm looking at some issues related to extended elements, and it
will be a good opportunity to investigate these issues as well. I'll
get back to you in a day or so.
Thanks
On Tue, Jan 6, 2009 at 10:13 AM, Greg Dritschler
<gr...@gmail.com> wrote:
> 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
>
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/