In Java SDO, when generating types dynamically from xsd, if you want to include an element from the base SDO type system then to have a valid XSD you must import sdoModel.xsd. My scenario is when including an element in my schema of type sdo:ChangeSummaryType.
<xsd:schema xmlns:sdo="commonj.sdo" xmlns:simpleCS=" http://www.example.com/simpleCS"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; targetNamespace=" http://www.example.com/simpleCS";> <xsd:import namespace="commonj.sdo" schemaLocation="sdoModel.xsd"/> <xsd:complexType name="QuoteBase"> <xsd:complexContent> <xsd:extension base="simpleCS:Quote"> <xsd:sequence> <xsd:element name="changes" type="sdo:ChangeSummaryType"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> As an eclipse user the absence of this import statement means my eclipse project permanently has errors. A side effect of the import is that new versions of the sdo model types are created and registered within the scope of the TypeHelper that is used during the import. These mask the generated class versions of these types created during SDO runtime initialization. In many cases this isn't going to cause a failure, it will just mean that all the underlying SDO stuff is using DynamicDataObjectImpl where it would have been using for example org.apache.tuscany.sdo.model.Type; but I have hit situations where it does cause failure. I think this may be a cross language issue, and maybe one to refer back to the spec group. Now in the java world here's a nasty catch, one side effect of this which, given the way we run things, only occurs in a maven test run, and not when running junits in eclipse is that one unit test can affect a later one. In maven the tests are all run within one process invocation, and therefore share static variables, whereas we haven't as yet created top level tests that use the Junit suite approach to aggreating test case runs, so we don't see this symptom when running the tests individually. So a late test in maven might see an instance of TypeHelper.INSTANCE with a dynamic version of the SDO model created as a side effect of a previous test. I can see a few things we could do here, either specific to this case and/or as general project guidelines. - change the way we create types to avoid this masking behaviour in general - put a special case catch into the XSD converter to permit inclusion of sdoModel.xsd and avoid this side effect? - create an SDOUtil.reset(TypeHelper) method or some such, which could be called in the tear down method of test cases - more generally implement classes that don't match the maven filename rule for test cases, which mimic the merging behaviour of the maven test case run, and then use this when running test cases outside of maven. what do you think? -- Best Regards Kelvin Goodson
