I'm kind of surprised that the root element of the serialised document is in the target namespace of the Type, if you provide null as the input URI. So to check, the root element looks something like
<tns:Input xmlns:tns="http://abc.com/Sample";> as opposed to <Input xmlns:tns="http://abc.com/Sample"; xsi:type="tns:InputType"> .... yes? It's clear from the code path indicated by the exception you reported, that the metadata created during code generation due to the global elements in your schema are not being found at document creation time. I believe you should be supplying the namespace string to the CreateDocument call, and all will be well. Kelvin. On 15/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote: > > Hi Kelvin, let me clarify. > > The schemas used to generate the (static SDO) classes > all have their own targetnamespaces. E.g.: > <schema targetNamespace="http://abc.com/Sample";> > <element name="Input" type="MyType"/> > <complexType name="MyType"> > .... > </complexType> > </schema> > > I convert an sdo object to XML this way: > MyType mySdo = … > > HelperContext hc = HelperProvider.getDefaultContext(); > XMLDocument xmldoc = > > hc.getXMLHelper().createDocument((DataObject)mySdo, > null, "Input"); > > … > hc.getXMLHelper().save(xmldoc, os, options); > > > When I pass null as rootElementUri as shown above, > then the targetNamespace as defined in the schema is > used in the produced XML. > Does the tuscany/emf code internally behave different > with regard to potential concurrency problems, if the > targetnamespace defined in the schema is explicitly > passed as rootElementUri argument? > > > Regards, Daniel. > > > --- kelvin goodson <[EMAIL PROTECTED]> > schrieb: > > > > So I think this is to do with the fact that you are > > not specifying a target > > namspace in the schema used to generate the classes. > > I see from the > > tools-test test case that uses the simpleNoTns.xsd > > schema, that the > > namespace URI for the generated artifacts is in fact > > the URI of the schema > > file on disk (not null or ""). So the global > > property created in the > > generated java won't be found with the lookup of > > (ns=null, name=Input) when > > calling XMLHelper.createDocument(dob, ns, name), > > hence the demand creation > > of the global property. Are you constrained to > > using a schema with no > > target namespace? If you had a namespace in your > > schema, and used it in > > the call to createDocument() then the underlying > > code would pick up the > > global property instance that is created by the > > generated factory, and you > > would then never hit this concurrency issue. > > > > Kelvin. > > > > > Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen > Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
