There's a sample that shows the two approaches at [1]. This sample has changed a lot since the beta1 release, so I include the output of the sample below in case its not so easy for you to build from the trunk.
Kelvin [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/ObtainingDataGraphFromXml.java ----------------------------------------------------------------------------------------------------- - Tuscany SDO Java Sample org.apache.tuscany.samples.sdo.advanced.ObtainingDataGraphFromXml - - This sample is aimed at a advanced user - ----------------------------------------------------------------------------------------------------- ********************************************************************************************************** * SDO Sample org.apache.tuscany.samples.sdo.advanced.ObtainingDataGraphFromXml * * * * This sample touches an area of the SDO API where the emphasis has changed over the various * * version of the specification, and so it's important to be clear what's going on * * First off lets be sure of our terminology ... * * 1) A "data graph" is a just collection of DataObjects, all contained within a single * * containment hierarchy, with a single root object, and possibly having some non-containment * * references * * 2) A "DataGraph" is an instance of the SDO DataGraph class, used as a container for the root * * DataObject of a data graph, and providing a means to access a change summary for the data graph. * * * * More recent versions of the SDO specification have provided alternative means of containment * * of a data graph ... * * 3) The graph can be contained in a DataObject of a built-in SDO Type with namespace URI "commonj.sdo" * * and name "DataGraph": so this is a modeled version of the special DataGraph class. * * 4) The Graph can be contained in an XMLDocument instance, which provides for things such as * * naming the root element of an XML instance document * ********************************************************************************************************** ---------------------------------------------------------------------------------------------------- - Here we see the specification's example for obtaining dealing with - - loading a data graph which uses a method, XMLHelper.load(). This loads an XML instance document - - into an instance of XMLDocument ... - - - - XMLDocument doc = scope.getXMLHelper().load( - - ClassLoader.getSystemResourceAsStream( SdoSampleConstants.COMPANY_DATAGRAPH_XML)); - ---------------------------------------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <!-- * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either express or implied. See the License for the * specific language governing permissions and limitations * under the License. --> <sdo:datagraph xmlns:company="company.xsd" xmlns:sdo="commonj.sdo"> <company:company employeeOfTheMonth="E0002" name="ACME"> <departments location="NY" name="Advanced Technologies" number="123"> <employees name="John Jones" SN="E0001"/> <employees name="Jane Doe" SN="E0003"/> <employees manager="true" name="Al Smith" SN="E0004"/> </departments> </company:company> </sdo:datagraph> --------------------------------------------------------------------------------------------------- - Now we can get the wrapper for the data graph, which in this case is the DataObject - - of type commonj.sdo#DataGraph. Note how there's no magic here; no special class for - - DataGraph, no special handling, this is just a standard pattern of using a built in SDO Type. - - The wrapper is there purely because it was serialized - - into the XML document, using the standard serialization technique. - - - - DataObject dataObjectRepresentingDataGraph = doc.getRootObject(); - --------------------------------------------------------------------------------------------------- [EMAIL PROTECTED] (changeSummary: [EMAIL PROTECTED], anyAttribute: null) (any: [company:company= [EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: CompanyType) (instanceClassName: null) (abstract: false, interface: false))]) ----------------------------------------------------------------------------------------------- - If you are confused by the fact that what we really get is an instance of DataGraphTypeImpl - - This really is a DataObject, but it is a generated class extending DataObjectImpl - - +representing the DataGraph model. - ----------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------- - We've obtained a DataObject representing the data graph, and from that we have obtained - - the true root object of the business data - ------------------------------------------------------------------------------------------- [EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: CompanyType) (instanceClassName: null) (abstract: false, interface: false)) --------------------------------------------------------------------------------------------------------- - Using an instance of DataGraph can perhaps be seen as an older style pattern of wrapping a data graph - - and the first approach is likely to get more emphaissi and attention in future revisions of the spec. - - The SDO API has some limitations in the area of saving and loading instances of the - - Java DataGraph type, so Tuscany has an API for doing this ... - - - - DataGraph datagraph = SDOUtil.loadDataGraph( - - ClassLoader.getSystemResourceAsStream( SdoSampleConstants.COMPANY_DATAGRAPH_XML), null); - --------------------------------------------------------------------------------------------------------- [EMAIL PROTECTED] (resourceSet: [EMAIL PROTECTED] resources=[ [EMAIL PROTECTED]' all.datagraph', [EMAIL PROTECTED] uri=' root.xml']) --------------------------------------------------------------------------------------- - In this case we directly receive an instance of DataGraph and can retrieve the root - - business object from the DataGraph - - - - DataObject company = datagraph.getRootObject(); - --------------------------------------------------------------------------------------- [EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: CompanyType) (instanceClassName: null) (abstract: false, interface: false)) ------------------------------------------------------------------------------------------- - End of sample org.apache.tuscany.samples.sdo.advanced.ObtainingDataGraphFromXml - ------------------------------------------------------------------------------------------- On 06/07/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
Hi Erich, This sounds like a little fishy to me, since it looks like you are serializing your specialized DataGraph inside another DataGraph. The SDO spec says that you can't nest change summaries, which could be the problem. Note that in SDO 2.1, commonj.sdo.DataGraph and a DataObject-type DataGraph are two alternative ways of creating a graph of dataobjects.This is something that we'd like to clean up in SDO3. I think tere may be a Tuscany sample that explains the two approaches: is that right Kelvin? For your specialized DataObject-type MyDataGraph you should just serialize it using XMLHelper.save(). You shouldn't use a commonj.sdo.DataGraph in this case. This may be the problem, but then again, there may also be a bug. You say below, that you attached a test case, but I don't see any attachments? Thanks, Frank. Erich Rueede <[EMAIL PROTECTED]> wrote on 07/06/2007 10:21:26 AM: > Hi all > > I have created an XML Schema with a toplevel > dataobject and a contained datagraph as specified in > the webservice sample part of the SDO 2.1 spec (page > 132). > > I then generated static SDO code from the XML schema > which resulted in implementations for the toplevel > dataobject and the contained datagraph. > > The generated code for the static datagraph somehow > differs quite a lot from the dynamic programming model > using the commonj.sdo.DataGraph. > > When I turn on logging on the generated static > datagraph, I notice that no changes are getting > recorded. It contains a partial change summary without > any changes: > > <?xml version="1.0" encoding="ASCII"?> > <datagraph > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:tns="http://abc.com/services"; > xsi:type="tns:MyDataGraph"> > <changeSummary logging="true" /> > <NestedType> > <test1>test1_modified</test1> > <test2>test2_modified</test2> > </NestedType> > </datagraph> > > Using the dynamic programming model, it contains a > full change summary with recorded changes: > > <?xml version="1.0" encoding="ASCII"?> > <sdo:datagraph > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:sdo="commonj.sdo" > > xmlns:sdo_1="http://www.apache.org/tuscany/2005/SDO"; > xmlns:tns="http://abc.com/services";> > <changeSummary xmlns="" > logging="true"> > <objectChanges key="#//@eRootObject"> > <value xsi:type="sdo_1:ChangeSummarySetting" > featureName="test2" dataValue="test2"/> > <value xsi:type="sdo_1:ChangeSummarySetting" > featureName="test1" dataValue="test1"/> > </objectChanges> > </changeSummary> > <tns:NestedType> > <test1>test1_modified</test1> > <test2>test2_modified</test2> > </tns:NestedType> > </sdo:datagraph> > > Is the static approach of modelling a datagraph within > an XSD basically supported with the current TUSCANY > implementation? > > I attached a sample XSD and test implementation. > > Thanks > Erich > > > > > ____________________________________________________________________________________ > Choose the right car based on your needs. Check out Yahoo! Autos > new Car Finder tool. > http://autos.yahoo.com/carfinder/ > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
