Hi Simon, The validations for this fix is not available as part of the patches. I believe its good to have them in place. I will put some validations for the same by Friday if possible, otherwise I can take it up after the vacation once I come back on 29/10/2008. Thanks.
On Wed, Oct 22, 2008 at 4:18 PM, Simon Laws (JIRA) <dev@tuscany.apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/TUSCANY-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Simon Laws updated TUSCANY-2631: > -------------------------------- > > Fix Version/s: (was: Java-SCA-Next) > Java SCA-1.3.3 > > Hi Ram > > Am just looking at this now. Quick question while it compiles. Is there a > validation test that goes with it? > > Simon > > > 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. > > -- Thanks & Regards, Ramkumar Ramalingam
