[
https://issues.apache.org/jira/browse/TUSCANY-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642505#action_12642505
]
Raymond Feng commented on TUSCANY-2631:
---------------------------------------
I investigated the empty namespace issue. Now I think the XML is not valid per
the XML namespace statement:
http://www.w3.org/TR/xml-names/
[Definition: If the attribute name matches PrefixedAttName, then the NCName
gives the namespace prefix, used to associate element and attribute names with
the namespace name in the attribute value in the scope of the element to which
the declaration is attached. In such declarations, the namespace name may not
be empty. ]
You probably have to do this way:
<sca:deployable xmlns="" composite="xyz"
xml:sca="http://www.osoa.org/xmlns/sca/1.0"/>
> More fault tolerance in Tuscany models processors
> -------------------------------------------------
>
> Key: TUSCANY-2631
> URL: https://issues.apache.org/jira/browse/TUSCANY-2631
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-1.3
> Reporter: Raymond Lai
> Assignee: Ramkumar Ramalingam
> Fix For: Java SCA-1.3.3
>
> Attachments: TUSCANY-2631-Part1.patch, TUSCANY-2631-Part2.patch
>
>
> Currently, the Contribution model's StAXProcessor doesn't tolerate
> Contribution XML document that doesn't conform to the specification. For
> example,
> <?xml version="1.0" encoding="UTF-8"?>
> <contribution xmlns="http://www.osoa.org/xmlns/sca/1.0";>
> <deployable composite="ns1:dfsdf" xmlns:ns1=""></deployable>
> <deployable xmlns:ns1="http://temp";></deployable>
> <deployable composite="ns1:aaaa" xmlns:ns1="http://temp";></deployable>
> <deployable composite="ns1:dsfs" xmlns:ns1="http://temp";></deployable>
> </contribution>
> Note that the first <deployable> element has an empty string namespace while
> the second <deployable> is missing the composite attribute. These errors will
> choke the contribution StAXProcessor and its read method returns a NULL. So
> that the other valid deployable composites are not read.
> I think a more desirable approach to handle it is to read as much as possible
> and returns a Contribution object that contains both the valid composites and
> invalid composites which can be a sub-class of Composite, e.g.
> InvalidComposite. Also, the StAXProcessor should be able to write back the
> invalid composites.
> This behaviour might be needed by other StAXProcessors as well, e.g. the
> composite's.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
