[jira] Updated: (TUSCANY-656) Maven javadoc plugin bug fixed allowing overview.html for javadoc to be created in a relative directory
[ http://issues.apache.org/jira/browse/TUSCANY-656?page=all ] Robbie Minshall updated TUSCANY-656: Attachment: assemblyPatch_draft.txt I attached a working draft for a patch that creates a sdo sample distribution that includes 1. source 2. binary 3. javadoc 4. dependancy libraries The assembly file is currently including all of these as fileSets rather than including the module source and binary. I did think in order to get things working as currently there seems to be a mismatch between the assembly plugin doc examples and the implementation. I would recomend that this patch be improved by copying the parents licence files etc both into the distribution and also into the doc-files/ directory for inclusion in the javadoc. I would also recommend that the overview be updated s.t it directs the user to use the dependancy lib rather than downloading dependancies themselves. I would be happy to complete these small remaining items but do not have time in the next few days. thanks, Robbie > Maven javadoc plugin bug fixed allowing overview.html for javadoc to be > created in a relative directory > --- > > Key: TUSCANY-656 > URL: http://issues.apache.org/jira/browse/TUSCANY-656 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Samples >Affects Versions: Java-M2 >Reporter: Robbie Minshall >Priority: Minor > Attachments: assemblyPatch_draft.txt, TUSCANY-656a.patch > > > In 2.0 beta 3 release of Maven javadoc plugin back slashes were removed when > processing the overview location for the javadoc. > In 2.0 release this was fixed. We can now include an initial description > and readme within the overview page for hte javadoc of the samples. -- 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]
[jira] Updated: (TUSCANY-987) Create maven project structure for community test suite
[ http://issues.apache.org/jira/browse/TUSCANY-987?page=all ] Robbie Minshall updated TUSCANY-987: Attachment: oldTestCases.zip Test cases needs javadoc work, has outstanding issues which have JIRA associated but not always linked in the code. There is an abstraction here between junit test cases and general tests ( scenarios ). This is so that the general scenarios can be run from other test harness. org.apache.tuscany.sdo.fvt.lib contains general scenarios org.apache.tuscany.sdo.fvt.tests contains junit test cases which call general scenarios passing in a created DataObject. The idea is that general test scnearios can be run on DataObject created dynamically, statically or mixed. Don't do much with this as I am going to work on converting these on 12/14 > Create maven project structure for community test suite > --- > > Key: TUSCANY-987 > URL: http://issues.apache.org/jira/browse/TUSCANY-987 > Project: Tuscany > Issue Type: Task > Components: Java SDO Community Test Suite >Affects Versions: Java-Mx >Reporter: Kelvin Goodson > Attachments: oldTestCases.zip > > > Create project structure for testing SDO 2.1 as per tuscany-dev mailing list > discussion thread "Proposal for a (Java) community test suite for SDO" > started 30th Nov '06. -- 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]
[jira] Updated: (TUSCANY-987) Create maven project structure for community test suite
[ http://issues.apache.org/jira/browse/TUSCANY-987?page=all ] Robbie Minshall updated TUSCANY-987: Attachment: convertedJunit41.zip Converted a single general scenario to junit 4.1 style as a proof of concept Created prototype JunitCore, listener to test ability to run within other environments ( such as app server ) Attempted to use paramatized test runner to use dataobjects of various construction but a current lack of scoping for TypeHelper cause this to break. Will be working on this on 12/14 and on 12/20 Robbie > Create maven project structure for community test suite > --- > > Key: TUSCANY-987 > URL: http://issues.apache.org/jira/browse/TUSCANY-987 > Project: Tuscany > Issue Type: Task > Components: Java SDO Community Test Suite >Affects Versions: Java-Mx >Reporter: Kelvin Goodson > Attachments: convertedJunit41.zip, oldTestCases.zip > > > Create project structure for testing SDO 2.1 as per tuscany-dev mailing list > discussion thread "Proposal for a (Java) community test suite for SDO" > started 30th Nov '06. -- 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]
[jira] Commented: (TUSCANY-987) Create maven project structure for community test suite
[ http://issues.apache.org/jira/browse/TUSCANY-987?page=comments#action_12460033 ] Robbie Minshall commented on TUSCANY-987: - Converted Brian's test cases to Junit 4.1 format. Uploaded as an attachment robbieBrianCTS_20061220.zip Still need to : - integrate within cts - typeHelper scoping test cases - test.sdo.TypeConversionTest.java and test.sdo.DateConversionTest.java can be simplified and written as paramatized tests - test cases could be refactored so that tests within each testCase are more modular ( right now there is usually just one test method per test case ) - static SDO generation - associate JIRAs with failures Sometime this week I should find some time to work on our app server test harness for testCases. Would you like me to integrate with cts ? Robbie > Create maven project structure for community test suite > --- > > Key: TUSCANY-987 > URL: http://issues.apache.org/jira/browse/TUSCANY-987 > Project: Tuscany > Issue Type: Task > Components: Java SDO Community Test Suite >Affects Versions: Java-Mx >Reporter: Kelvin Goodson > Attachments: convertedJunit41.zip, cts.zip, oldTestCases.zip > > > Create project structure for testing SDO 2.1 as per tuscany-dev mailing list > discussion thread "Proposal for a (Java) community test suite for SDO" > started 30th Nov '06. -- 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]
[jira] Updated: (TUSCANY-987) Create maven project structure for community test suite
[ http://issues.apache.org/jira/browse/TUSCANY-987?page=all ] Robbie Minshall updated TUSCANY-987: Attachment: robbieBrianCTS_20061220.zip uploading Brian's test cases converted to Junit 4.1. See prior attachment for more detailed status. > Create maven project structure for community test suite > --- > > Key: TUSCANY-987 > URL: http://issues.apache.org/jira/browse/TUSCANY-987 > Project: Tuscany > Issue Type: Task > Components: Java SDO Community Test Suite >Affects Versions: Java-Mx >Reporter: Kelvin Goodson > Attachments: convertedJunit41.zip, cts.zip, oldTestCases.zip, > robbieBrianCTS_20061220.zip > > > Create project structure for testing SDO 2.1 as per tuscany-dev mailing list > discussion thread "Proposal for a (Java) community test suite for SDO" > started 30th Nov '06. -- 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]
[jira] Created: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1048: - Attachment: tuscany-1048-paramatizedTests1.zip > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany-1048-paramatizedTests1.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Commented: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464024 ] Robbie Minshall commented on TUSCANY-1048: -- I have attached tuscany-1048-paramatizedTests1.zip This is a first attempt at converting Brian's and my test cases to a form more applicable to the cts. Please let me know what is good and what is bad. I have converted to the maven format though did not create a patch at this point becaues there is a lot of changes and I wanted some feedback before making this effort. - Created junit 4.1 paramatized tests rather than using the abstracted scenario method - Used TestHelper interface for non spec APIs ( this needs some improvement ) and for obtaining implementation specific helper classes etc. The DefaultTestHelper is not in this zip as I currently have it in a vendorSpecific subdirectory which I use for the tuscany implementation - Removed use of SDOUtil and INSTANCE for helper methods - Added @Suite Classes for paramatized and general tests - Made means and creation of population of DataObjects extendable by vendors ( good for using the same test cases for vendor specific static sdo etc ). I will add a seperate zip and screenshot for the application test harness. This is a simple servlet/jsp and junitCore modification which allows the user to execute test cases in application server environment and view results. It uses DOJO which may or may not be a problem. Since my use cases for SDO are based upon the execution of applications that use SDO within an application server this is very valuable to my testing but I am unsure whether or not the CTS will be interested. > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany-1048-paramatizedTests1.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1048: - Attachment: tuscanyHelper.zip > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Commented: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464846 ] Robbie Minshall commented on TUSCANY-1048: -- tuscany-1048-paramatizedTests1.zip is a replacement not an overlay for java/cts/sdo21. It is intended for general review of layout purposes and does not include an implementation of TestHelper which is necessary to execute the test cases. tuscanyHelper includes an implementation of TestHelper and replaces CTSGeneralSuite.java and CTSParamatizedSuite.java so that test caes that require static SDO are not executed. I have not included the static SDO as this topic complicates matters and should be discussed seperately. > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Commented: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467138 ] Robbie Minshall commented on TUSCANY-1048: -- Adding a patch to convert from scenarios to paramatized tests. I have attempted to remove references to test cases that rely on static SDO. I have not added a patch for a new project to house the tuscany test helper implementation. In order to use this to execute I have been using junit and our own custom application harness. the initialization reads an environment variable for the test helper implementation, for example: I will attempt to create a project to execute CTS and use the tuscany test helper when I get some time ( perhaps friday ) - if anyone else would like to do it that would be good. Robbie > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Fix For: Java-SDO-Mx > > Attachments: tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- 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-1093) isSet returning false when boolean set to false, or int set to 0
isSet returning false when boolean set to false, or int set to 0 Key: TUSCANY-1093 URL: https://issues.apache.org/jira/browse/TUSCANY-1093 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Robbie Minshall Priority: Critical when boolean property is set to false a call to isSet returns false ( should return true ). when an int property is set to 0 a call to isSet returns false ( should return true ). This causes DataObject serialization ( our scenario involves using the sca ws binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470267 ] Robbie Minshall commented on TUSCANY-1093: -- One possible solution is to change make EStructuralFeature.unsettable true. This will result in more memory consumpiton as it adds an additional possible value called unset. > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[
https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470606
]
Robbie Minshall commented on TUSCANY-1093:
--
I updated my tuscany version and it seems that some changes were made to modify
this behavior. Setting boolean attribute when the type is defined in an XSD is
now working. Setting dynamically defined Boolean property still seems to fail.
Can you see anything wrong with the following test case ?
public void testIsSet_DynamicTypeDef_commonjSdoBoolean_false() throws Exception
{
// define a type with two properties
DataObject typeDef = DataFactory.INSTANCE.create("commonj.sdo", "Type");
typeDef.set("uri", "");
typeDef.set("name", "myBooleanType");
typeDef.set("open", true);
DataObject propertyDef = typeDef.createDataObject("property");
propertyDef.set("name", "b1");
Type propertyType = TypeHelper.INSTANCE.getType("commonj.sdo",
"Boolean");
propertyDef.set("type",propertyType );
propertyDef.set("many", false);
propertyDef.set("containment", false);
TypeHelper.INSTANCE.define( typeDef );
// create a DataObject that uses this type
DataObject testDO = DataFactory.INSTANCE.create( "", "myBooleanType" );
Property p = testDO.getProperty("b1");
System.out.println("testIsSet_DynamicTypeDef_Boolean_false: sdoBoolean
field type : " + p.getType());
testDO.unset(p);
assertFalse("testing that property is unset after unset is called",
testDO.isSet(p));
testDO.set(p, false);
System.out.println("Set booleanField via property: " + testDO.get(p) +
", isSet " + testDO.isSet(p) + " default " + p.getDefault());
assertTrue(
"testing that property is set after setting to false, value
of property is "
+ testDO.get(p), testDO.isSet(p));
}
> isSet returning false when boolean set to false, or int set to 0
>
>
> Key: TUSCANY-1093
> URL: https://issues.apache.org/jira/browse/TUSCANY-1093
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Reporter: Robbie Minshall
>Priority: Critical
>
> when boolean property is set to false a call to isSet returns false ( should
> return true ).
> when an int property is set to 0 a call to isSet returns false ( should
> return true ).
> This causes DataObject serialization ( our scenario involves using the sca ws
> binding ) to be missing values that have been set.
--
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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470636 ] Robbie Minshall commented on TUSCANY-1093: -- I am guessing that this code path for creating the EStructuralFeature for the property does not have the attribute unsettable equal to true . . . but that is just a guess. > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471132 ] Robbie Minshall commented on TUSCANY-1093: -- patch worked great. > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > Attachments: patch > > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471371 ] Robbie Minshall commented on TUSCANY-1093: -- This surprised me also. There was a definate change in behavior from my m2 shapshot and the current version of tuscany ( previously neither xsd or dynamic displayed 2.1 spec behavior ). Also demonstrated by fuhwei and yang not being able to reproduce the behavior. I can probably look into this more late next week if someone else does not get to it. > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > Attachments: patch > > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1117) Updates to CTS test suite
Updates to CTS test suite - Key: TUSCANY-1117 URL: https://issues.apache.org/jira/browse/TUSCANY-1117 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Providing some updates to the CTS test suite. These updates make some modifications to existing test cases such as formatting ( eclipse code style ) and some test additions. -- 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-1117) Updates to CTS test suite
[ https://issues.apache.org/jira/browse/TUSCANY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1117: - Attachment: tuscany117_generalUpdatesToCTS_patch1.txt There are some formatting and changes and test additions in this patch. I am uncertain how commiters would like these updates to be contributed. I have attached a single patch file with all my current updates with the intent of reducing the work involved in creating and applying these patches. Please advise if the patch is not formatted well or if there are other issues ( [EMAIL PROTECTED] ). If people would prefer a set of more modular then we can do that also. It would be more controlled but also significantly more work. thanks, Robbie > Updates to CTS test suite > - > > Key: TUSCANY-1117 > URL: https://issues.apache.org/jira/browse/TUSCANY-1117 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany117_generalUpdatesToCTS_patch1.txt > > > Providing some updates to the CTS test suite. > These updates make some modifications to existing test cases such as > formatting ( eclipse code style ) and some test additions. -- 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-1117) Updates to CTS test suite
[ https://issues.apache.org/jira/browse/TUSCANY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1117: - Attachment: tuscany117_patch2.zip This patch is intended for a replacement of the first. It adds the concept of adopted test suite vrs underReview test suite for the CTS.The idea here is that we need to get people writing test cases for their JIRA and provide the means to test specific function but we also need some level of control about what is included in the CTS jar default test cases. The tuscany impl just calls the CTSSuite which includes the adopted test cases. The user can optionally execute the other test cases using hte mvn -Dtest.sdo21.vendor.tuscany.tests.OptionalCtsTestSuite.java test if people think that this is a good thing I will write up a document for how to : How to test/execute a new test case How to add a new test case to tuscany How to ignore a specific test case How to execute non adopted test cases How to get a new test case adopted into the CTS > Updates to CTS test suite > - > > Key: TUSCANY-1117 > URL: https://issues.apache.org/jira/browse/TUSCANY-1117 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany117_generalUpdatesToCTS_patch1.txt, > tuscany117_patch2.zip > > > Providing some updates to the CTS test suite. > These updates make some modifications to existing test cases such as > formatting ( eclipse code style ) and some test additions. -- 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-1117) Updates to CTS test suite
[ https://issues.apache.org/jira/browse/TUSCANY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473745 ] Robbie Minshall commented on TUSCANY-1117: -- Sorry certainly I intended this for inclusion. If a commiter deletes the attachment I will upload it again with the licence permissions. Robbie > Updates to CTS test suite > - > > Key: TUSCANY-1117 > URL: https://issues.apache.org/jira/browse/TUSCANY-1117 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany117_generalUpdatesToCTS_patch1.txt, > tuscany117_patch2.zip > > > Providing some updates to the CTS test suite. > These updates make some modifications to existing test cases such as > formatting ( eclipse code style ) and some test additions. -- 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-1127) ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content
[
https://issues.apache.org/jira/browse/TUSCANY-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474539
]
Robbie Minshall commented on TUSCANY-1127:
--
Samples should also not be using the TypeHelper.INSTANCE etc.
I will provide a patch towards the end of the week.
> ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing
> xsd:any content
> -
>
> Key: TUSCANY-1127
> URL: https://issues.apache.org/jira/browse/TUSCANY-1127
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Samples
>Affects Versions: Java-SDO-M3
>Reporter: Frank Budinsky
> Fix For: Java-SDO-M3
>
>
> The ObtainingDataGraphFromXml sample includes the following:
> // Obtain the company DataObject from the DataObject representing
> the datagraph
> Sequence mySeq = (Sequence)
> dataObjectRepresentingDataGraph.getSequence("any");
> company = (DataObject) mySeq.getValue(0);
> 1) the "any" property is an EMF-specific thing that was never defined in the
> SDO spec.
> 2) TUSCANY-521 will be removing the special Sequence-type properties, which
> will break this sample.
> This needs to be change to use the proper SDO2 API:
> company =
> dataObjectRepresentingDataGraph.getDataObject("company");
> Any other samples that call get() and expect it to return a Sequence also
> need to be changed.
--
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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474710 ] Robbie Minshall commented on TUSCANY-1093: -- If not already being done can we commit this patch and close this JIRA. > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > Attachments: patch > > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474760 ] Robbie Minshall commented on TUSCANY-1093: -- Ok. Can Yang please include a test case which demonstrates what is currently not working with the existing patch. That way I can include it into the CTS updates. thanks, Robbie > isSet returning false when boolean set to false, or int set to 0 > > > Key: TUSCANY-1093 > URL: https://issues.apache.org/jira/browse/TUSCANY-1093 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Reporter: Robbie Minshall >Priority: Critical > Attachments: patch > > > when boolean property is set to false a call to isSet returns false ( should > return true ). > when an int property is set to 0 a call to isSet returns false ( should > return true ). > This causes DataObject serialization ( our scenario involves using the sca ws > binding ) to be missing values that have been set. -- 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-1117) Updates to CTS test suite
[ https://issues.apache.org/jira/browse/TUSCANY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475106 ] Robbie Minshall commented on TUSCANY-1117: -- Core, extended, undereview : I think that this would probably be a good idea. I have been working with SDO-X a little and will be helping them to utilize the work in the CTS to evaluate their implementation. I think that ( and any other vendor use ) would be the right time/place to create that distinction to meet their needs. This somewhat introduces the notion of a compliance level or measurement which I agree would be a good for a seperate discussion on the list. XMLEqualityChecker Sounds good. > Updates to CTS test suite > - > > Key: TUSCANY-1117 > URL: https://issues.apache.org/jira/browse/TUSCANY-1117 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany117_generalUpdatesToCTS_patch1.txt, > tuscany117_patch2.zip > > > Providing some updates to the CTS test suite. > These updates make some modifications to existing test cases such as > formatting ( eclipse code style ) and some test additions. -- 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-1117) Updates to CTS test suite
[ https://issues.apache.org/jira/browse/TUSCANY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1117: - Attachment: tuscany117_patch3.zip This renames the TestUtil and grants ASF licence. Does not extend the concept of underreview etc. > Updates to CTS test suite > - > > Key: TUSCANY-1117 > URL: https://issues.apache.org/jira/browse/TUSCANY-1117 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Attachments: tuscany117_generalUpdatesToCTS_patch1.txt, > tuscany117_patch2.zip, tuscany117_patch3.zip > > > Providing some updates to the CTS test suite. > These updates make some modifications to existing test cases such as > formatting ( eclipse code style ) and some test additions. -- 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-583) Add a method to SDOUtil to return all Types associated with a specific URI
[ http://issues.apache.org/jira/browse/TUSCANY-583?page=comments#action_12424142 ] Robbie Minshall commented on TUSCANY-583: - I am planning on working on this issue. Can someone please assign it to rjminsha. > Add a method to SDOUtil to return all Types associated with a specific URI > -- > > Key: TUSCANY-583 > URL: http://issues.apache.org/jira/browse/TUSCANY-583 > Project: Tuscany > Issue Type: New Feature > Components: Java SDO Implementation >Reporter: Brent Daniel >Priority: Minor > > The DAS needs a way to get a list of the Types for a specific URI. -- 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]
[jira] Updated: (TUSCANY-628) exceptions in SDO samples
[ http://issues.apache.org/jira/browse/TUSCANY-628?page=all ] Robbie Minshall updated TUSCANY-628: Attachment: tuscany-628a.txt Updated xpath examples to use SDO xpath like syntax rather than traditional xpath queries. The other exception is caused by the properties being in incorrect order. The code in the sample should be correct but will require that you are running on a recent tuscany implementation that pulls in EMF 2.2.1. Robbie > exceptions in SDO samples > - > > Key: TUSCANY-628 > URL: http://issues.apache.org/jira/browse/TUSCANY-628 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Samples >Affects Versions: Java-M2 >Reporter: Kelvin Goodson >Priority: Minor > Attachments: tuscany-628a.txt > > > A log was attached to tuscany 626 which was used to commit the new SDO > samples. This log shows two exceptions being raised during the execution of > the samples. This JIRA raised to cover fixing those exceptions. -- 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]
[jira] Created: (TUSCANY-656) Maven javadoc plugin bug fixed allowing overview.html for javadoc to be created in a relative directory
Maven javadoc plugin bug fixed allowing overview.html for javadoc to be created in a relative directory --- Key: TUSCANY-656 URL: http://issues.apache.org/jira/browse/TUSCANY-656 Project: Tuscany Issue Type: Improvement Components: Java SDO Samples Affects Versions: Java-M2 Reporter: Robbie Minshall Priority: Minor In 2.0 beta 3 release of Maven javadoc plugin back slashes were removed when processing the overview location for the javadoc. In 2.0 release this was fixed. We can now include an initial description and readme within the overview page for hte javadoc of the samples. -- 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]
[jira] Updated: (TUSCANY-656) Maven javadoc plugin bug fixed allowing overview.html for javadoc to be created in a relative directory
[ http://issues.apache.org/jira/browse/TUSCANY-656?page=all ] Robbie Minshall updated TUSCANY-656: Attachment: TUSCANY-656a.patch Adds overview to the pom.xml > Maven javadoc plugin bug fixed allowing overview.html for javadoc to be > created in a relative directory > --- > > Key: TUSCANY-656 > URL: http://issues.apache.org/jira/browse/TUSCANY-656 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Samples >Affects Versions: Java-M2 >Reporter: Robbie Minshall >Priority: Minor > Attachments: TUSCANY-656a.patch > > > In 2.0 beta 3 release of Maven javadoc plugin back slashes were removed when > processing the overview location for the javadoc. > In 2.0 release this was fixed. We can now include an initial description > and readme within the overview page for hte javadoc of the samples. -- 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]
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432874 ] Robbie Minshall commented on TUSCANY-153: - FYI. All very striaght forward but in order to apply the patch I had to perform the following 1. new files not versioned. -> add files by hand prior to applying patch : touch sdo/impl/src/test/java/org/apache/tuscany/sdo/test/ChangeSummaryOnDataObjectTestCase.java touch sdo/impl/src/test/resources/datagraph.xsd touch sdo/impl/src/test/resources/sdoJava.xsd touch sdo/impl/src/test/resources/sdoModel.xsd touch sdo/impl/src/test/resources/sdoXML.xsd touch sdo/impl/src/test/resources/simpleWithChangeSummary.xsd 2. Adjust fuzz factor to 7 to get matches of recently changed files 3. DataObjectImpl could not match patch due to import reordering. -> add imports by hand after patch applied import org.apache.tuscany.sdo.SDOFactory; import org.apache.tuscany.sdo.impl.ClassImpl; import org.apache.tuscany.sdo.impl.DataObjectImpl; 4. Delete ChangeSummaryTypeImpl as kelvin mentioned > ChangeSummary on root data object not supported > --- > > Key: TUSCANY-153 > URL: http://issues.apache.org/jira/browse/TUSCANY-153 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-Mx >Reporter: Kevin Williams > Fix For: Java-Mx > > Attachments: do_cs_2.patch, tuscany153.jar > > > The RDB DAS intends to produce data graphs without using a DataGraph instance > and this requires us to attach a change history to the root DataObject. It > seems that this capability is not yet implemented. -- 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]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432924 ] Robbie Minshall commented on TUSCANY-696: - I will take a look at this later this afternoon. > XMLStreamHelper usage > - > > Key: TUSCANY-696 > URL: http://issues.apache.org/jira/browse/TUSCANY-696 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation > Environment: Windows XP, java version "1.5.0_07" Java(TM) 2 Runtime > Environment, Standard Edition (build 1.5.0_07-b03) > Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) >Reporter: Scott Boag > Attachments: SimpleRun2.java, > XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml > > > Not sure if this is a bug or user problem or both. I am trying to work on a > generic lossless adapter from SDO to a XML data model, without intervening > serialization. > I'm running the following code: > XMLHelper xmlHelper = XMLHelper.INSTANCE; > XSDHelper xsdHelper = XSDHelper.INSTANCE; > TypeHelper typeHelper = TypeHelper.INSTANCE; > URL url = SimpleRun2.class.getClassLoader().getResource( > NNS_SCHEMA_LOCATION); > List xsdTypes = xsdHelper > .define(url.openStream(), url.toExternalForm()); > // InputStream is = new FileInputStream(TEST_XML_DOCUMENT); > URL testxmlURL = SimpleRun2.class.getClassLoader().getResource( > TEST_XML_DOCUMENT); > XMLDocument doc = xmlHelper.load(testxmlURL.openStream()); > DataObject rootobj = doc.getRootObject(); > // typeHelper.define(xsdTypes); > XMLStreamHelper xmlStreamHelper = SDOUtil > .createXMLStreamHelper(typeHelper); > XMLStreamReader streamReader = xmlStreamHelper > .createXMLStreamReader(rootobj); > xmlStreamReader2XmlText(streamReader, System.out); > (xmlStreamReader2XmlText is just a utility method I lifted from somewhere) > Raymond told me in a private exchange that I needed to do > "TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation); " > (though that implies that I know ahead of time the schema). Since TypeHelper > doesn't have a define that takes the schema, I assume the above is what he > meant. If I pass the result of the xsdHelper.define to typeHelper.define, it > crashes in spectacular ways. > When I run this code, the result is: > > Which is clearly wrong. I've included the complete program. -- 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]
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432954
]
Robbie Minshall commented on TUSCANY-153:
-
COMPANY WITH CHANGE SUMMARY PROPERTY
Rather than using a new type to wrap an existing type with a changeSummary I
have simply added a changeSummary property into the sequence of an existing
Type. Perhaps I did this incorrectly
I have put the xsd and the xml below and then some questions below that.
* * * XSD * * *
http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
targetNamespace="changeSummary_company.xsd">
* * * XML * * *
* * * Questions and issues * * *
1. Type for changes property should be ChangeSummaryType but was Object. I
obtained the name of the type using
DataObject.getProperty("changes").getType().getName()
junit.framework.ComparisonFailure: Asserting that the type for the changes
property is ChangeSummaryType expected: but was:
2. Obtaining ChangeSummary.
DataObject.get("changes") returns a null String
DataObject.getChangeSummary returns null where it should return a ChangeSummary
3. Obtaining Sequence
I am unable to get the sequence ( which is making me think the xml may be
incorrect ). .getSequence() is returning null.
> ChangeSummary on root data object not supported
> ---
>
> Key: TUSCANY-153
> URL: http://issues.apache.org/jira/browse/TUSCANY-153
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Kevin Williams
> Fix For: Java-Mx
>
> Attachments: do_cs_2.patch, tuscany153.jar
>
>
> The RDB DAS intends to produce data graphs without using a DataGraph instance
> and this requires us to attach a change history to the root DataObject. It
> seems that this capability is not yet implemented.
--
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]
[jira] Commented: (TUSCANY-153) ChangeSummary on root data object not supported
[ http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432955 ] Robbie Minshall commented on TUSCANY-153: - LOADING SIMPLE CHANGE SUMMARY When I attempt to load the simple change summary contained within the fix I get an exception when loading the XML. I will look into the causes tomorrow when I have more time but if you have any insights that would be great. public static final String CHANGESUMMARY_SIMPLE_XSD = "/simpleWithChangeSummary.xsd"; public static final String CHANGESUMMARY_SIMPLE_XML = "/simplechangesummary.xml"; . . . . // define simple Type XSDHelper.INSTANCE.define(getClass().getResourceAsStream( CHANGESUMMARY_SIMPLE_XSD), null); // get a DataObject DataObject simple = XMLHelper.INSTANCE.load( getClass().getResourceAsStream(CHANGESUMMARY_SIMPLE_XML)) .getRootObject(); ---> java.lang.ExceptionInInitializerError at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDocumentRoot(ModelFactoryImpl.java:313) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createGen(ModelFactoryImpl.java:106) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.create(ModelFactoryImpl.java:120) at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:784) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:1938) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(XMLHandler.java:1214) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1152) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1234) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:872) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:854) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:626) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(Unknown Source) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:264) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:235) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:213) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:72) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:66) at org.apache.tuscany.sdo.test.DataObjectChangeSummaryTestCase.testObtainChangeSummaryFromSimple(DataObjectChangeSummaryTestCase.java:174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.jun
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432980
]
Robbie Minshall commented on TUSCANY-696:
-
I just wrote a quick junit test that essentially does what you do with the
company xsd and xml files as well as with the ones you originally used.
public void testXMLStreamHelper(String xsd, String xml) {
try {
URL testxmlURLx = getClass().getResource(xml);
XMLStreamReader streamReaderx =
XMLInputFactory.newInstance()
.createXMLStreamReader(testxmlURLx.openStream());
xmlStreamReader2XmlText(streamReaderx, System.out);
System.out.println();
System.out.println("=");
System.out
.println("Now run the same file with
SDO to StaX adapter (XMLStreamHelper): ");
XMLHelper xmlHelper = XMLHelper.INSTANCE;
XSDHelper xsdHelper = XSDHelper.INSTANCE;
TypeHelper typeHelper = TypeHelper.INSTANCE;
// define types
List xsdTypes = xsdHelper.define(getClass()
.getResourceAsStream(xsd), null);
// obtain dataobject
DataObject rootobj = XMLHelper.INSTANCE.load(
getClass().getResourceAsStream(xml)).getRootObject();
System.out.println("Type of rootObject " +
rootobj.getType().getName() );
// obtain an xml stream helper
XMLStreamHelper xmlStreamHelper = SDOUtil
.createXMLStreamHelper(typeHelper);
XMLStreamReader streamReader = xmlStreamHelper
.createXMLStreamReader(rootobj);
xmlStreamReader2XmlText(streamReader, System.out);
System.out.println();
} catch (Exception e) {
System.out.println("Exception : " + e.toString());
e.printStackTrace();
fail(e.toString());
}
}
With the company xsd/xml file it ran without errors though I am unsure of the
quality of the output ( do you know where is the p0: is from )
With the XMLDocumentNoNamespaceSchemaLocation.xsd and XMLDocumentTestCase.xml I
got a java.lang.NullPointerException calling xsr.getEventType() in the switch
statement.The rootObject is getting returned as AnyTypeDataObject.
I hate xml so will need to read study the NoNameSpace xsd some more ( might get
to it tomorrow afternoon some time ) . . . are you wanting to pursue using
this xsd and xml or make some progress using another schema and data ?
Robbie
> XMLStreamHelper usage
> -
>
> Key: TUSCANY-696
> URL: http://issues.apache.org/jira/browse/TUSCANY-696
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Environment: Windows XP, java version "1.5.0_07" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_07-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
>Reporter: Scott Boag
> Attachments: SimpleRun2.java,
> XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml
>
>
> Not sure if this is a bug or user problem or both. I am trying to work on a
> generic lossless adapter from SDO to a XML data model, without intervening
> serialization.
> I'm running the following code:
> XMLHelper xmlHelper = XMLHelper.INSTANCE;
> XSDHelper xsdHelper = XSDHelper.INSTANCE;
> TypeHelper typeHelper = TypeHelper.INSTANCE;
> URL url = SimpleRun2.class.getClassLoader().getResource(
> NNS_SCHEMA_LOCATION);
> List xsdTypes = xsdHelper
> .define(url.openStream(), url.toExternalForm());
> // InputStream is = new FileInputStream(TEST_XML_DOCUMENT);
> URL testxmlURL = SimpleRun2.class.getClassLoader().getResource(
> TEST_XML_DOCUMENT);
> XMLDocument doc = xmlHelper.load(testxmlURL.openStream());
> DataObject rootobj = doc.getRootObject();
> // typeHelper.define(xsdTypes);
> XMLStreamHelper xmlStreamHelper = SDOUtil
> .createXMLStreamHelper(typeHelper);
> XMLStreamReader streamReader = xmlStreamHelper
> .createXMLStreamReader(rootobj);
> xmlStreamReader2XmlTex
[jira] Updated: (TUSCANY-696) XMLStreamHelper usage
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=all ] Robbie Minshall updated TUSCANY-696: Attachment: robbieResults_1.txt attached junit update for initial test run that I executed. > XMLStreamHelper usage > - > > Key: TUSCANY-696 > URL: http://issues.apache.org/jira/browse/TUSCANY-696 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation > Environment: Windows XP, java version "1.5.0_07" Java(TM) 2 Runtime > Environment, Standard Edition (build 1.5.0_07-b03) > Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) >Reporter: Scott Boag > Attachments: robbieResults_1.txt, SimpleRun2.java, > XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml > > > Not sure if this is a bug or user problem or both. I am trying to work on a > generic lossless adapter from SDO to a XML data model, without intervening > serialization. > I'm running the following code: > XMLHelper xmlHelper = XMLHelper.INSTANCE; > XSDHelper xsdHelper = XSDHelper.INSTANCE; > TypeHelper typeHelper = TypeHelper.INSTANCE; > URL url = SimpleRun2.class.getClassLoader().getResource( > NNS_SCHEMA_LOCATION); > List xsdTypes = xsdHelper > .define(url.openStream(), url.toExternalForm()); > // InputStream is = new FileInputStream(TEST_XML_DOCUMENT); > URL testxmlURL = SimpleRun2.class.getClassLoader().getResource( > TEST_XML_DOCUMENT); > XMLDocument doc = xmlHelper.load(testxmlURL.openStream()); > DataObject rootobj = doc.getRootObject(); > // typeHelper.define(xsdTypes); > XMLStreamHelper xmlStreamHelper = SDOUtil > .createXMLStreamHelper(typeHelper); > XMLStreamReader streamReader = xmlStreamHelper > .createXMLStreamReader(rootobj); > xmlStreamReader2XmlText(streamReader, System.out); > (xmlStreamReader2XmlText is just a utility method I lifted from somewhere) > Raymond told me in a private exchange that I needed to do > "TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation); " > (though that implies that I know ahead of time the schema). Since TypeHelper > doesn't have a define that takes the schema, I assume the above is what he > meant. If I pass the result of the xsdHelper.define to typeHelper.define, it > crashes in spectacular ways. > When I run this code, the result is: > > Which is clearly wrong. I've included the complete program. -- 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]
[jira] Created: (TUSCANY-708) Should TypeHelper.define return List of Types that includes DocumentRootType
Should TypeHelper.define return List of Types that includes DocumentRootType Key: TUSCANY-708 URL: http://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 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. - 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]
[jira] Commented: (TUSCANY-696) XMLStreamHelper usage
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12433204
]
Robbie Minshall commented on TUSCANY-696:
-
As Paul points out the XMLDocumentTestCase.xml defines the schema location for
http://www.example.com/xmlDocumentSchemaLocation as
/XMLDocumentSchemaLocation.xsd.
It seems that one good candidate for the issue you are facing here is that the
root data object is being defined as Type AnyTypeDataObject rather than
purchaseReport Type as defined in the XMLDocumentSchemaLocation.xsd.
If I define the types in this xsd explicidly ( hey there spelling ) prior to
running my junit test I get the following result
List xsdTypes = XSDHelper.INSTANCE.define(getClass()
.getResourceAsStream("/XMLDocumentSchemaLocation.xsd"), null);
***RESULT AFTER DEFINING TYPES
http://www.example.com/xmlDocumentSchemaLocation
/XMLDocumentSchemaLocation.xsd http://www.example.com/open/open.xsd"
xmlns:sl="http://www.example.com/xmlDocumentSchemaLocation";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
some string
another string
=
Now run the same file with SDO to StaX adapter (XMLStreamHelper):
xsd defined 2types
aNoNamespaceSchemaLocationElement
DocumentRoot
xsd defined 2types
DocumentRoot
purchaseReport
Type of rootObject purchaseReport
some
stringanother
string
**
This is looking way closer to what we want.
PROBLEM:
When an xml file inlines the definition of a schema for a uri the Types within
this schema shoudl get defined within the type helper. This is tricky as what
scope ( TypeHelper scope ) should this be defined on ?
ACTION:
I will post to the dev list to discuss this issue then provide a fix.
> XMLStreamHelper usage
> -
>
> Key: TUSCANY-696
> URL: http://issues.apache.org/jira/browse/TUSCANY-696
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Environment: Windows XP, java version "1.5.0_07" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_07-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
>Reporter: Scott Boag
> Attachments: robbieResults_1.txt, SimpleRun2.java,
> XMLDocumentNoNamespaceSchemaLocation.xsd, XMLDocumentTestCase.xml
>
>
> Not sure if this is a bug or user problem or both. I am trying to work on a
> generic lossless adapter from SDO to a XML data model, without intervening
> serialization.
> I'm running the following code:
> XMLHelper xmlHelper = XMLHelper.INSTANCE;
> XSDHelper xsdHelper = XSDHelper.INSTANCE;
> TypeHelper typeHelper = TypeHelper.INSTANCE;
> URL url = SimpleRun2.class.getClassLoader().getResource(
> NNS_SCHEMA_LOCATION);
> List xsdTypes = xsdHelper
> .define(url.openStream(), url.toExternalForm());
> // InputStream is = new FileInputStream(TEST_XML_DOCUMENT);
> URL testxmlURL = SimpleRun2.class.getClassLoader().getResource(
> TEST_XML_DOCUMENT);
> XMLDocument doc = xmlHelper.load(testxmlURL.openStream());
> DataObject rootobj = doc.getRootObject();
> // typeHelper.define(xsdTypes);
> XMLStreamHelper xmlStreamHelper = SDOUtil
> .createXMLStreamHelper(typeHelper);
> XMLStreamReader streamReader = xmlStreamHelper
> .createXMLStreamReader(rootobj);
> xmlStreamReader2XmlText(streamReader, System.out);
> (xmlStreamReader2XmlText is just a utility method I lifted from somewhere)
> Raymond told me in a private exchange that I needed to do
> "TypeHelper.INSTANCE.define(InputStream xsd, String schemaLocation); "
> (though that implies that I know ahead of time the schema). Since TypeHelper
> doesn't have a define that takes the schema, I assume the above is what he
> meant. If I pass the result of the xsdHelper.define to typeHelper.define, it
> crashes in spectacular ways.
> When I run this code, the result is:
>
> Which is clearly wrong. I've included the complete program.
--
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]
