[jira] Updated: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1397: Attachment: tuscany1397-v2.patch This patch replaces the previous version. This patch was created on the latest code. createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Attachments: tuscany1397-v2.patch, tuscany1397.patch Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517178 ] Andy Grove commented on TUSCANY-1397: - We discussed this issue in last week's SDO spec. call and decided that for now (SDO 2.1.1) we will leave this behaviour unspecified but there seemed to be general concensus that the correct behaviour (to be clarified for SDO 3.0) would be to on-demand create the property for consistency with other set() methods. createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512698 ] Andy Grove commented on TUSCANY-1397: - You're right, the spec doesn't currently cover this. Perhaps the spec should be amended to state that calling createDataObject() with a property that does not exist should throw an IllegalArgumentException ? Alternatively it could just demand-create the property using a vendor-specific open DataObject type. That seems more consistent with the behaviour of the setT() calls. I'm going to raise a JIRA against the spec, cross-referencing this JIRA. createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512700 ] Andy Grove commented on TUSCANY-1397: - Filed against the spec. as http://www.xcalia.com/support/browse/SDO-255 createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1410) DataHelperImpl.toCalendar() with null locale should use default locale
DataHelperImpl.toCalendar() with null locale should use default locale
--
Key: TUSCANY-1410
URL: https://issues.apache.org/jira/browse/TUSCANY-1410
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Andy Grove
Priority: Minor
DataHelperImpl.toCalendar() currently returns null if the locale parameter is
null. However, according to the published SDO API javadoc comments, if locale
is null then the default locale should be used. To resolve this, the following
code can be added at the start of the method.
if (locale == null) {
locale = Locale.getDefault();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1128) Support attribute and element with same name
[ https://issues.apache.org/jira/browse/TUSCANY-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509195 ] Andy Grove commented on TUSCANY-1128: - Out of interest, does Tuscany support the use of sdo:aliasName xsd annotations to distinguish between elements and attributes with the same name? Thanks, Andy. Support attribute and element with same name Key: TUSCANY-1128 URL: https://issues.apache.org/jira/browse/TUSCANY-1128 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Yang ZHONG Priority: Minor Fix For: Java-SDO-Next Attachments: 1128.patch, 1128.patch, DifferAttrFromElementTestCase.java, dupelement.xsd, DupElementTestCase.java To support attribute and element with same name within one Type such as complexType sequence element name=property type=int/ /sequence attribute name=property type=string/ /complexType and using @property to access attribute and property to access element. This is to support OTA standard schema used in the travel industry. @property notation comes from XPath: http://www.w3.org/TR/xpath#path-abbrev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1384) SequenceAddOpenTest.setUp() needs to check if type exists before creating it
SequenceAddOpenTest.setUp() needs to check if type exists before creating it Key: TUSCANY-1384 URL: https://issues.apache.org/jira/browse/TUSCANY-1384 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next SequenceAddOpenTest.setUp() needs to check if type exists before creating it so that the test does not fail against implementations that cannot provide a new HelperContext for each run. I intend to fix this in the next couple of days. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid
DataObjectListTest.testGetInvalidInstanceProperty is invalid Key: TUSCANY-1380 URL: https://issues.apache.org/jira/browse/TUSCANY-1380 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next The following callin DataObjectListTest.testGetInvalidInstanceProperty is invalid because getInstanceProperty() is not intended to work with xpath expressions, just property names. testObj.getInstanceProperty(aaa[1]); I don't have committer rights yet. Could someone please mark this test @Ignore for the moment. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid
[ https://issues.apache.org/jira/browse/TUSCANY-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507915 ] Andy Grove commented on TUSCANY-1380: - I should have added that the test is expecting this call to return null, since this is not a valid property. However, our implementation throws an IllegalArgumentException if an xpath expression is passed to getInstanceProperty and hence fails this test. DataObjectListTest.testGetInvalidInstanceProperty is invalid Key: TUSCANY-1380 URL: https://issues.apache.org/jira/browse/TUSCANY-1380 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next The following callin DataObjectListTest.testGetInvalidInstanceProperty is invalid because getInstanceProperty() is not intended to work with xpath expressions, just property names. testObj.getInstanceProperty(aaa[1]); I don't have committer rights yet. Could someone please mark this test @Ignore for the moment. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove closed TUSCANY-1351. --- Resolution: Fixed Thanks Kelvin. Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next Attachments: tuscany-1351-v2.patch, XMLDifferenceException.java A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: tuscany-1351-v2.patch Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351-v2.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: (was: tuscany-1351.patch) Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351-v2.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506112 ] Andy Grove commented on TUSCANY-1351: - I have made some more substantial changes to XMLHelperTest and XMLEqualityChecker: - XMLEqualityChecker now sets the parser to be namespace aware - XMLEqualityChecker now throws a meaningful exception when a difference is encountered, rather than returning false - Special handling for xsi:type now compares the type name but ignores the namespace prefix Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351-v2.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: XMLDifferenceException.java Attaching XMLDifferenceException.java required by patch. Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351-v2.patch, XMLDifferenceException.java A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Patch Info: [Patch Available] Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: tuscany-1351.patch Patch that resolves this issue by removing prefix-specific comparisons and instead just relies in comparison of namespace uri and local name. Also remove duplicate code that checked the namespace. Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: (was: tuscany-1351.patch) Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1351: Attachment: tuscany-1351.patch New version of patch that fixes another namespace assumption. Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: tuscany-1351.patch A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1234) New test for accessing mixed content
New test for accessing mixed content Key: TUSCANY-1234 URL: https://issues.apache.org/jira/browse/TUSCANY-1234 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor Attachments: jira-1234.patch Adding a new test for accessing mixed content in a complex element e.g. name lang=en_USAdam/name The test passes against Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1234) New test for accessing mixed content
[ https://issues.apache.org/jira/browse/TUSCANY-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1234: Attachment: jira-1234.patch New test for accessing mixed content Key: TUSCANY-1234 URL: https://issues.apache.org/jira/browse/TUSCANY-1234 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor Attachments: jira-1234.patch Adding a new test for accessing mixed content in a complex element e.g. name lang=en_USAdam/name The test passes against Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1235) CTS tests for Sequence support
CTS tests for Sequence support -- Key: TUSCANY-1235 URL: https://issues.apache.org/jira/browse/TUSCANY-1235 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove The attached java test cases need to be added in cts/sdo2.1/src/main/java/tests/sdo21/tests/api. They do not reference any resource files. The tests should be added to the UnderReviewTestSuite for now, since they currently fail when running against Tuscany, possibly due to a bug in Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1235) CTS tests for Sequence support
[ https://issues.apache.org/jira/browse/TUSCANY-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1235: Attachment: SequenceAddTypedTest.java SequenceAddOpenTest.java CTS tests for Sequence support -- Key: TUSCANY-1235 URL: https://issues.apache.org/jira/browse/TUSCANY-1235 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: SequenceAddOpenTest.java, SequenceAddTypedTest.java The attached java test cases need to be added in cts/sdo2.1/src/main/java/tests/sdo21/tests/api. They do not reference any resource files. The tests should be added to the UnderReviewTestSuite for now, since they currently fail when running against Tuscany, possibly due to a bug in Tuscany. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1232) XSDSimpleTypeTest (New CTS Test)
XSDSimpleTypeTest (New CTS Test) Key: TUSCANY-1232 URL: https://issues.apache.org/jira/browse/TUSCANY-1232 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDSimpleTypeTest.zip This test case checks for spec-compliance when creating SDO types derived from simple XSD types. The attached ZIP file contains the new test (XSDSimpleTypeTest.java) and the required XSD files. The ZIP file should be expanded in cts\sdo2.1\src. NOTE: the test will need to be added manually to the UnderReviewTestSuite or CTSGeneralSuite. All tests pass against Tuscany SDO apart from testDerived and testDerived2, which are currently excluded using the junit @Ignore annotation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1232) XSDSimpleTypeTest (New CTS Test)
[ https://issues.apache.org/jira/browse/TUSCANY-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1232: Attachment: XSDSimpleTypeTest.zip ZIP file as described above. XSDSimpleTypeTest (New CTS Test) Key: TUSCANY-1232 URL: https://issues.apache.org/jira/browse/TUSCANY-1232 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDSimpleTypeTest.zip This test case checks for spec-compliance when creating SDO types derived from simple XSD types. The attached ZIP file contains the new test (XSDSimpleTypeTest.java) and the required XSD files. The ZIP file should be expanded in cts\sdo2.1\src. NOTE: the test will need to be added manually to the UnderReviewTestSuite or CTSGeneralSuite. All tests pass against Tuscany SDO apart from testDerived and testDerived2, which are currently excluded using the junit @Ignore annotation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
Tuscany-specific assertions in DynamicTypesFromSchemaTestCase - Key: TUSCANY-1228 URL: https://issues.apache.org/jira/browse/TUSCANY-1228 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for Object types, such as: assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject)); There is nothing wrong with Tuscany creating this type with this name, but the naming of these Object types is not provided in the specification, so this test will fail on other implementations. I will provide a patch to remove these particular assertions. This is consistent with changes made to other test cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1228: Attachment: jira-1228.patch Patch file. Tuscany-specific assertions in DynamicTypesFromSchemaTestCase - Key: TUSCANY-1228 URL: https://issues.apache.org/jira/browse/TUSCANY-1228 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1228.patch DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for Object types, such as: assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject)); There is nothing wrong with Tuscany creating this type with this name, but the naming of these Object types is not provided in the specification, so this test will fail on other implementations. I will provide a patch to remove these particular assertions. This is consistent with changes made to other test cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1229) CTS contains duplicate copy of TypeConversion test
CTS contains duplicate copy of TypeConversion test -- Key: TUSCANY-1229 URL: https://issues.apache.org/jira/browse/TUSCANY-1229 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Trivial There are three tests named TypeConversionTest in the CTS: test.sdo21.paramatizedTests.conversion.TypeConversionTest test.sdo21.tests.conversion.TypeConversionTest test.sdo21.tests.typeconv.TypeConversionTest The last two are duplicates - a diff shows that they are almost identical, differing only in comments and format. We should simply delete test.sdo21.tests.typeconv.TypeConversionTest - it is not referenced anywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove resolved TUSCANY-1228. - Resolution: Invalid I had an old file on my local system that was not in subversion - this issue is invalid. Tuscany-specific assertions in DynamicTypesFromSchemaTestCase - Key: TUSCANY-1228 URL: https://issues.apache.org/jira/browse/TUSCANY-1228 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1228.patch DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for Object types, such as: assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject)); There is nothing wrong with Tuscany creating this type with this name, but the naming of these Object types is not provided in the specification, so this test will fail on other implementations. I will provide a patch to remove these particular assertions. This is consistent with changes made to other test cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1228) Tuscany-specific assertions in DynamicTypesFromSchemaTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491297 ] Andy Grove commented on TUSCANY-1228: - Ignore the previous comment - I posted this on the wrong JIRA. This issue is still valid. Tuscany-specific assertions in DynamicTypesFromSchemaTestCase - Key: TUSCANY-1228 URL: https://issues.apache.org/jira/browse/TUSCANY-1228 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1228.patch DynamicTypesFromSchemaTestCase.testDynamicTypeList contains assertions for Object types, such as: assertTrue(typeNameSet.contains(evenNumberOfOddOrEvenDigitsObject)); There is nothing wrong with Tuscany creating this type with this name, but the naming of these Object types is not provided in the specification, so this test will fail on other implementations. I will provide a patch to remove these particular assertions. This is consistent with changes made to other test cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1229) CTS contains duplicate copy of TypeConversion test
[ https://issues.apache.org/jira/browse/TUSCANY-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove closed TUSCANY-1229. --- Resolution: Invalid I had an old file on my system - the test case is not duplicated after all. CTS contains duplicate copy of TypeConversion test -- Key: TUSCANY-1229 URL: https://issues.apache.org/jira/browse/TUSCANY-1229 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Trivial There are three tests named TypeConversionTest in the CTS: test.sdo21.paramatizedTests.conversion.TypeConversionTest test.sdo21.tests.conversion.TypeConversionTest test.sdo21.tests.typeconv.TypeConversionTest The last two are duplicates - a diff shows that they are almost identical, differing only in comments and format. We should simply delete test.sdo21.tests.typeconv.TypeConversionTest - it is not referenced anywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1230) Improvements to TypeConversionTest
Improvements to TypeConversionTest -- Key: TUSCANY-1230 URL: https://issues.apache.org/jira/browse/TUSCANY-1230 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove The attached patch performs the following - Refactors test.sdo21.tests.conversion.TypeConversionTest to split out a subset of the tests into a new StringConversionTest class with a common base class of ConversionBase - Adds TypeConversionTest to the CTSGeneralSuite (all tests pass against Tuscany) - Adds StringConversionTest to the UnderReviewTestSuite (there are quite a few failures which need further investigation) This patch also fixes a number of tests that were testing that the implementation threw an exception when performing certain type conversions, such as byte - BigInteger, as these conversions are not listed as supported conversions in the data type conversion matrix in the specification. However, these conversions are completely valid and should have been included in the type conversion matrix. See JIRA SDO-188 (OSOA) for more information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1230) Improvements to TypeConversionTest
[ https://issues.apache.org/jira/browse/TUSCANY-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1230: Attachment: jira-1230.patch Patch for above. Improvements to TypeConversionTest -- Key: TUSCANY-1230 URL: https://issues.apache.org/jira/browse/TUSCANY-1230 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1230.patch The attached patch performs the following - Refactors test.sdo21.tests.conversion.TypeConversionTest to split out a subset of the tests into a new StringConversionTest class with a common base class of ConversionBase - Adds TypeConversionTest to the CTSGeneralSuite (all tests pass against Tuscany) - Adds StringConversionTest to the UnderReviewTestSuite (there are quite a few failures which need further investigation) This patch also fixes a number of tests that were testing that the implementation threw an exception when performing certain type conversions, such as byte - BigInteger, as these conversions are not listed as supported conversions in the data type conversion matrix in the specification. However, these conversions are completely valid and should have been included in the type conversion matrix. See JIRA SDO-188 (OSOA) for more information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1222) Incorrect assertions in XSDChoiceTest
Incorrect assertions in XSDChoiceTest - Key: TUSCANY-1222 URL: https://issues.apache.org/jira/browse/TUSCANY-1222 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Two of the tests in XSDChoiceTest were incorrectly asserting that the types were created with sequenced=false. After re-reading the specification, it is clear that these particular types should have sequenced=true because the choice definitions have maxOccurs 1. I am attaching a patch that resolves this issue and also promotes XSDChoiceTest to the AdoptedTestSuite. There is now a single test failure when running against Tuscany and this is due to a bug in Tuscany (see JIRA-1221). Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1221) Incorrect containment value when creating property from XSD
Incorrect containment value when creating property from XSD --- Key: TUSCANY-1221 URL: https://issues.apache.org/jira/browse/TUSCANY-1221 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove When creating an SDO type from the following XSD complexType, Tuscany is creating the property red with containment = false instead of containment = true. I have checked the specification and this contradicts the rules on page 90 of the SDO for Java 2.1.0 specification (see the table with the title XML Elements with Complex Type). This is highlighted by the CTS test XSDChoiceTest.testTC226_Choice. xs:complexType name=choiceType xs:choice xs:element name=red type=xs:string/ xs:element name=green/ xs:element name=blue/ /xs:choice /xs:complexType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1222) Incorrect assertions in XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1222: Attachment: jira-1222.patch Incorrect assertions in XSDChoiceTest - Key: TUSCANY-1222 URL: https://issues.apache.org/jira/browse/TUSCANY-1222 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1222.patch Two of the tests in XSDChoiceTest were incorrectly asserting that the types were created with sequenced=false. After re-reading the specification, it is clear that these particular types should have sequenced=true because the choice definitions have maxOccurs 1. I am attaching a patch that resolves this issue and also promotes XSDChoiceTest to the AdoptedTestSuite. There is now a single test failure when running against Tuscany and this is due to a bug in Tuscany (see JIRA-1221). Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1221) Incorrect containment value when creating property from XSD
[ https://issues.apache.org/jira/browse/TUSCANY-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove resolved TUSCANY-1221. - Resolution: Invalid Marking this JIRA as invalid. Incorrect containment value when creating property from XSD --- Key: TUSCANY-1221 URL: https://issues.apache.org/jira/browse/TUSCANY-1221 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove When creating an SDO type from the following XSD complexType, Tuscany is creating the property red with containment = false instead of containment = true. I have checked the specification and this contradicts the rules on page 90 of the SDO for Java 2.1.0 specification (see the table with the title XML Elements with Complex Type). This is highlighted by the CTS test XSDChoiceTest.testTC226_Choice. xs:complexType name=choiceType xs:choice xs:element name=red type=xs:string/ xs:element name=green/ xs:element name=blue/ /xs:choice /xs:complexType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1222) Incorrect assertions in XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1222: Attachment: jira-1222-v2.patch Attaching a new version of the patch file. Please disregard the previous one. This new patch fixes a further error in the test. After applying this patch, Tuscany passes all tests in XSDChoiceTest. JIRA-1221 has been closed as invalid. Incorrect assertions in XSDChoiceTest - Key: TUSCANY-1222 URL: https://issues.apache.org/jira/browse/TUSCANY-1222 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1222-v2.patch, jira-1222.patch Two of the tests in XSDChoiceTest were incorrectly asserting that the types were created with sequenced=false. After re-reading the specification, it is clear that these particular types should have sequenced=true because the choice definitions have maxOccurs 1. I am attaching a patch that resolves this issue and also promotes XSDChoiceTest to the AdoptedTestSuite. There is now a single test failure when running against Tuscany and this is due to a bug in Tuscany (see JIRA-1221). Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1223) XSD base64Binary type mapping to wrong SDO type
XSD base64Binary type mapping to wrong SDO type --- Key: TUSCANY-1223 URL: https://issues.apache.org/jira/browse/TUSCANY-1223 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Priority: Minor The XSD base64Binary type should map to the SDO type commonj.sdo#Bytes but Tuscany is mapping it to commonj.sdo#Base64Bytes which is not mentioned in the SDO specification. This is demonstrated in the CTS in XSDComplexTypeTest.testTC297ComplexTypeContainingElementsOfAllTypes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1224) XSDComplexTypeTest patch
XSDComplexTypeTest patch Key: TUSCANY-1224 URL: https://issues.apache.org/jira/browse/TUSCANY-1224 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1224.patch I have reviews the XSDComplexTypeTest and fixed a number of issues, such as: - Removed one test that was specific to Rogue Wave - Fixed errors in assertions that checked for sequenced=true or false (many of these were incorrect) - Removed assertions that tested how many types were created from each XSD (so the test now only mandates that those types required by the specification are created) After making these changes, there are 3 test failures when running against Tuscany. Two of these are related to an incorrect mapping of XSD base64Binary type in Tuscany, the other is due to isNullable not being implemented in Tuscany (an UnsupportedOperationException is thrown). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1224) XSDComplexTypeTest patch
[ https://issues.apache.org/jira/browse/TUSCANY-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1224: Attachment: jira-1224.patch Patch that fixes errors in test case, as described above, and also moved the test into the AdoptedTestSuite. XSDComplexTypeTest patch Key: TUSCANY-1224 URL: https://issues.apache.org/jira/browse/TUSCANY-1224 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: jira-1224.patch I have reviews the XSDComplexTypeTest and fixed a number of issues, such as: - Removed one test that was specific to Rogue Wave - Fixed errors in assertions that checked for sequenced=true or false (many of these were incorrect) - Removed assertions that tested how many types were created from each XSD (so the test now only mandates that those types required by the specification are created) After making these changes, there are 3 test failures when running against Tuscany. Two of these are related to an incorrect mapping of XSD base64Binary type in Tuscany, the other is due to isNullable not being implemented in Tuscany (an UnsupportedOperationException is thrown). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1209) Remove TestCase dependency from XSDChocieTest
Remove TestCase dependency from XSDChocieTest - Key: TUSCANY-1209 URL: https://issues.apache.org/jira/browse/TUSCANY-1209 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor The attached patch file updates XSDBaseTestCase / XSDChoice to use junit 4.1 annotations and removes the dependency on TestCase. It also improves the setup method to request a new testHelper class on each run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1209) Remove TestCase dependency from XSDChocieTest
[ https://issues.apache.org/jira/browse/TUSCANY-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1209: Attachment: patch.txt Remove TestCase dependency from XSDChocieTest - Key: TUSCANY-1209 URL: https://issues.apache.org/jira/browse/TUSCANY-1209 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Andy Grove Priority: Minor Attachments: patch.txt The attached patch file updates XSDBaseTestCase / XSDChoice to use junit 4.1 annotations and removes the dependency on TestCase. It also improves the setup method to request a new testHelper class on each run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1210) XSDComplexTypeTest
[ https://issues.apache.org/jira/browse/TUSCANY-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1210: Attachment: complexTypeXsdTests.zip ZIP file containing test case and xsd files. XSDComplexTypeTest -- Key: TUSCANY-1210 URL: https://issues.apache.org/jira/browse/TUSCANY-1210 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: complexTypeXsdTests.zip New test case to test spec-compliance of SDO types created from XSD complex types. The patch for JIRA 1209 must be applied first as it adds a new method to XSDBaseTestCase that this new test requires. The attached patch is simply a zip of the new files and should be extracted from the root of the cts module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1210) XSDComplexTypeTest
XSDComplexTypeTest -- Key: TUSCANY-1210 URL: https://issues.apache.org/jira/browse/TUSCANY-1210 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: complexTypeXsdTests.zip New test case to test spec-compliance of SDO types created from XSD complex types. The patch for JIRA 1209 must be applied first as it adds a new method to XSDBaseTestCase that this new test requires. The attached patch is simply a zip of the new files and should be extracted from the root of the cts module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1191) Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485133 ] Andy Grove commented on TUSCANY-1191: - Kelvin - yes, that was my intention. Thanks. Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property --- Key: TUSCANY-1191 URL: https://issues.apache.org/jira/browse/TUSCANY-1191 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XMLWithoutSchemaTest.java, XMLWithoutSchemaTest.java This test checks various compliance points relating to section 9.10 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1183) XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485134 ] Andy Grove commented on TUSCANY-1183: - Kelvin - yes, that was my intention. I'll be sure to add them in future. Thanks, Andy. XSDChoiceTest - Key: TUSCANY-1183 URL: https://issues.apache.org/jira/browse/TUSCANY-1183 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDChoiceTest-1183.zip, XSDChoiceTest-1183b.zip The attached zip contains a sample XSD test from Rogue Wave's test suite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1191) Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1191: Attachment: XMLWithoutSchemaTest.java Updated version of test with bugs fixed. Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property --- Key: TUSCANY-1191 URL: https://issues.apache.org/jira/browse/TUSCANY-1191 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XMLWithoutSchemaTest.java, XMLWithoutSchemaTest.java This test checks various compliance points relating to section 9.10 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1191) Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1191: Attachment: XMLWithoutSchemaTest.java Test case for 2.1 spec section 9.10 XML without Schema to SDO Type and Property --- Key: TUSCANY-1191 URL: https://issues.apache.org/jira/browse/TUSCANY-1191 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XMLWithoutSchemaTest.java This test checks various compliance points relating to section 9.10 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1183) XSDChoiceTest
XSDChoiceTest - Key: TUSCANY-1183 URL: https://issues.apache.org/jira/browse/TUSCANY-1183 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove The attached zip contains a sample XSD test from Rogue Wave's test suite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1183) XSDChoiceTest
[ https://issues.apache.org/jira/browse/TUSCANY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove updated TUSCANY-1183: Attachment: XSDChoiceTest-1183.zip XSDChoiceTest - Key: TUSCANY-1183 URL: https://issues.apache.org/jira/browse/TUSCANY-1183 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Reporter: Andy Grove Attachments: XSDChoiceTest-1183.zip The attached zip contains a sample XSD test from Rogue Wave's test suite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created
[ https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482093 ] Andy Grove commented on TUSCANY-1178: - I've spent some time looking at the spec and I think it would be useful to look an example in more detail. Lets look at the following example (note: in the test case none of the above types are used for nillable elements so this example is not exactly the same as the test case). xsd:element name=smallOddNumber nillable=true minOccurs=0 type=dtfs:smallOddNumber/ The spec says that for the element smallOddNumber we need to create an SDO Property called smallOddNumber with nullable=true. No problem so far. The spec then says that If the type of the element has Simple Content without attributes, a Java Type with an Object instance class is assigned. For example, IntObject instead of Int. My interpretation of this is that the SDO Property smallOddNumber should have an SDO Type commonj.sdo/java#IntObject assigned rather than commonj.sdo/Int. This implies that the property would never be assigned the type smallOddNumber, which doesn't seem correct. I think there are two conclusions from this: 1. The CTS should not expect the extra Object types to be created - this isn't required by the specification (but shouldn't be disallowed either) 2. This part of the specification needs reviewing / amending. Do you agree? If so, we should file a bug against the specification too. DynamicTypesFromSchemaTestCase expecting *Object types to be created Key: TUSCANY-1178 URL: https://issues.apache.org/jira/browse/TUSCANY-1178 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DynamicTypesFromSchemaTestCase expects the following types to be included in the list returned by XSDHelper.define() but there are no types with these names in the XSD (these types minus the Object suffix do exist though). Is there something in the spec that says these extra Object types must be created or is this Tuscany-specific implementation detail that should be excluded from the CTS? evenNumberOfOddOrEvenDigitsObject monthObject oddOrEvenDigitsObject smallIntObject smallOddNumberObject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created
[ https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482135 ] Andy Grove commented on TUSCANY-1178: - Thanks, Frank. I've filed the following bug against the specification: http://www.xcalia.com/support/browse/SDO-230 DynamicTypesFromSchemaTestCase expecting *Object types to be created Key: TUSCANY-1178 URL: https://issues.apache.org/jira/browse/TUSCANY-1178 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DynamicTypesFromSchemaTestCase expects the following types to be included in the list returned by XSDHelper.define() but there are no types with these names in the XSD (these types minus the Object suffix do exist though). Is there something in the spec that says these extra Object types must be created or is this Tuscany-specific implementation detail that should be excluded from the CTS? evenNumberOfOddOrEvenDigitsObject monthObject oddOrEvenDigitsObject smallIntObject smallOddNumberObject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1181) XSDSerializationTest is Tuscany-specific
XSDSerializationTest is Tuscany-specific Key: TUSCANY-1181 URL: https://issues.apache.org/jira/browse/TUSCANY-1181 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove XSDSerializationTest contains assertions like the following that expect 2 types to be created from simple.xsd, which just contains a single type called Quote. assertEquals(XSDHelper.define() did not create the expected number of Types, 2, types.size()); Presumably the current assertion is based on DocumentRoot being in the types list. It would be better to check that the Quote type is in the list rather than just checking the size of the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()
[ https://issues.apache.org/jira/browse/TUSCANY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481168 ] Andy Grove commented on TUSCANY-1177: - I agree that vendors should be free to return implementation-specific types and that the CTS should only be checking that define() returns all types that are required by the specification. Currently the tests are only checking the length of the returned list of types and are not checking the contents of the list so we'll need to tidy that up as part of this change. I'm happy to supply a patch if there are no objections to these changes. CTS should not expect DocumentRoot to be included in results from XSDHelper.define() Key: TUSCANY-1177 URL: https://issues.apache.org/jira/browse/TUSCANY-1177 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML documents without an XSD. All mentioned of DocumentRoot were removed from SDO 2.1 and the CTS should not be expecting DocumentRoot to be returned by XSDHelper.define(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1175) Tests for duration dates/times should not be in accepted test suite
Tests for duration dates/times should not be in accepted test suite - Key: TUSCANY-1175 URL: https://issues.apache.org/jira/browse/TUSCANY-1175 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove The SDO specification does not provide workable support for durations at present. This is documented in the following JIRAs opened against the specification: http://www.xcalia.com/support/browse/SDO-95 (Fixed in SDO 2.1) http://www.xcalia.com/support/browse/SDO-189 (Future SDO 3.0) The current SDO CTS duration tests (i.e. date formats starting with 'P') are passing against tuscany because the test (DateConversionTest.testToDateFormats) is only testing that the returned date is not null. The tuscany implementation of duration appears to be broken so it is misleading that the tests are passing. I propose that we move the duration tests to the UnderReview test suite for now. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1176) DynamicTypesFromSchemaTestCase should not expect mixed and text properties
DynamicTypesFromSchemaTestCase should not expect mixed and text properties -- Key: TUSCANY-1176 URL: https://issues.apache.org/jira/browse/TUSCANY-1176 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DynamicTypesFromSchemaTestCase currently fails if a call to getInstanceProperties does not return mixed or text properties. I see no mention of these properties in the SDO for Java 2.1 specification. The text property was mentioned in SDO 2.0.1 but then removed for SDO 2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1177) CTS should not expect DocumentRoot to be included in results from XSDHelper.define()
CTS should not expect DocumentRoot to be included in results from XSDHelper.define() Key: TUSCANY-1177 URL: https://issues.apache.org/jira/browse/TUSCANY-1177 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML documents without an XSD. All mentioned of DocumentRoot were removed from SDO 2.1 and the CTS should not be expecting DocumentRoot to be returned by XSDHelper.define(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-708) Should TypeHelper.define return List of Types that includes DocumentRootType
[ https://issues.apache.org/jira/browse/TUSCANY-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481053 ] Andy Grove commented on TUSCANY-708: DocumentRoot was mentioned in SDO 2.0.1 and was only relevant to XML documents *without* an XSD. All mentioned of DocumentRoot were removed from SDO 2.1 and XSDHelper.define() should not be returning DocumentRoot. I have filed a similar bug against the CTS as the current tests expect DocumentRoot to be created when parsing XSD. Should TypeHelper.define return List of Types that includes DocumentRootType Key: TUSCANY-708 URL: https://issues.apache.org/jira/browse/TUSCANY-708 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Robbie Minshall Priority: Minor Fix For: Java-SDO-Mx Attachments: 708.patch TypeHelper.define returns List of Types that includes the DocumentRoot Type Perhaps is shoudl only include Types that are deifned within the XSD ( i.e CompanyType, DeptartmentType etc ) SDOUtil.getTypes( scope, uri ) explicidly removes the DocumentRoot Type result.remove(((TypeHelperImpl) scope).getExtendedMetaData().getDocumentRoot(ePackage)); Should the Types returned by TypeHelper.define(...) and SDOUtil(scope, uri ) be consistent ? They probably should at least treat DocumentRoot Type consistently. FrankB says: Currently the DocumentRoot contains the global properties but he current SDO spec does not say how they are handled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1178) DynamicTypesFromSchemaTestCase expecting *Object types to be created
DynamicTypesFromSchemaTestCase expecting *Object types to be created Key: TUSCANY-1178 URL: https://issues.apache.org/jira/browse/TUSCANY-1178 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove DynamicTypesFromSchemaTestCase expects the following types to be included in the list returned by XSDHelper.define() but there are no types with these names in the XSD (these types minus the Object suffix do exist though). Is there something in the spec that says these extra Object types must be created or is this Tuscany-specific implementation detail that should be excluded from the CTS? evenNumberOfOddOrEvenDigitsObject monthObject oddOrEvenDigitsObject smallIntObject smallOddNumberObject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1079) Possible error in XSDSerialization tests
[ https://issues.apache.org/jira/browse/TUSCANY-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove resolved TUSCANY-1079. - Resolution: Fixed Thanks for clearing that up. I was forgetting about DocumentRoot. I'm marking this JIRA as fixed. Andy. Possible error in XSDSerialization tests Key: TUSCANY-1079 URL: https://issues.apache.org/jira/browse/TUSCANY-1079 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Affects Versions: Java-SDO-Mx Reporter: Andy Grove Fix For: Java-SDO-Mx The current test cases are expecting 2 types to be created from the following schema but does not contain assertions about what those types should look like. I would expect this schema to create only one type (http://www.example.com/simple#Quote) and one open content property (stockQuote) of that type. What other type should be created? Thanks, Andy. xsd:schema targetNamespace=http://www.example.com/simple; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:simple=http://www.example.com/simple; xsd:element name=stockQuote type=simple:Quote/ xsd:complexType name=Quote xsd:sequence xsd:element name=symbol type=xsd:string/ xsd:element name=companyName type=xsd:string/ xsd:element name=price type=xsd:decimal/ xsd:element name=open1 type=xsd:decimal/ xsd:element name=high type=xsd:decimal/ xsd:element name=low type=xsd:decimal/ xsd:element name=volume type=xsd:double/ xsd:element name=change1 type=xsd:double/ xsd:element name=quotes type=simple:Quote minOccurs=0 maxOccurs=unbounded/ /xsd:sequence /xsd:complexType /xsd:schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1079) Possible error in XSDSerialization tests
Possible error in XSDSerialization tests Key: TUSCANY-1079 URL: https://issues.apache.org/jira/browse/TUSCANY-1079 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove The current test cases are expecting 2 types to be created from the following schema but does not contain assertions about what those types should look like. I would expect this schema to create only one type (http://www.example.com/simple#Quote) and one open content property (stockQuote) of that type. What other type should be created? Thanks, Andy. xsd:schema targetNamespace=http://www.example.com/simple; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:simple=http://www.example.com/simple; xsd:element name=stockQuote type=simple:Quote/ xsd:complexType name=Quote xsd:sequence xsd:element name=symbol type=xsd:string/ xsd:element name=companyName type=xsd:string/ xsd:element name=price type=xsd:decimal/ xsd:element name=open1 type=xsd:decimal/ xsd:element name=high type=xsd:decimal/ xsd:element name=low type=xsd:decimal/ xsd:element name=volume type=xsd:double/ xsd:element name=change1 type=xsd:double/ xsd:element name=quotes type=simple:Quote minOccurs=0 maxOccurs=unbounded/ /xsd:sequence /xsd:complexType /xsd:schema -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec
[ http://issues.apache.org/jira/browse/TUSCANY-578?page=all ] Andy Grove updated TUSCANY-578: --- Attachment: DataObjectUtil.patch This patch file is for java/sdo/impl/src/main/java/org/apache/tuscany/sdo/util/DataObjectUtil.java and replaces the use of IllegalArgumentException with ClassCastException in type conversion methods. Exceptions thrown by SDO runtime not the same as defined in the spec Key: TUSCANY-578 URL: http://issues.apache.org/jira/browse/TUSCANY-578 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Brian Murray Priority: Minor Fix For: Java-Mx Attachments: DataObjectUtil.patch On page 27 of V2.01 of the spec, specific exceptions are listed for certain kinds of errors. In some cases, a different exception is thrown (each case will be added as a subtask). Either the specification or the implementation should be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
