I have created https://issues.apache.org/jira/browse/TUSCANY-1113
-----Original Message----- From: kelvin goodson [mailto:[EMAIL PROTECTED] Sent: 14. februar 2007 19:03 To: tuscany-user@ws.apache.org Subject: Re: SDO (Types) Registry Hi Christian, it would be good to get to a stage where we can exchange code and replicate issues in quick turnaround and attack this together. I haven't had a chance to work with the code you attached earlier yet. Frank suggested attaching the sources you are having problems with to a JIRA. If you were able to do that that would be really helpful. Just go to http://issues.apache.org/jira/browse/TUSCANY and create a new issue as an "Improvement" and paste your scenario into the description. Then I can try and replicate your issues in an eclipse 3.2 workspace. It would be good to get you up and running with subversion so that you could attach patches rather than files. It's tempting to suggest that we have an IRC chat on the Tuscany channel and really interactively pursue this (there's some info on IRC connection here http://incubator.apache.org/tuscany/get-involved.html) . We could also use pasetbin (http://pastebin.com/) in conjunction with IRC to quickly share code snippets. Unfortunately I have to leave the office in about 15 minutes (working in UK), but I'll see if I can get back to this later this evening. I assume you are in Denmark, yes? I'll make it a priority to try to support you interactively either later this evening or in the morning. If you fancy this then please let me know when is convenient for you. Best Regards, Kelvin. On 14/02/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote: > > Im pretty sure version 7 (which I am using) is based on 3.2 but > otherwise you are right :) > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 14. februar 2007 18:02 > To: tuscany-user@ws.apache.org > Subject: RE: SDO (Types) Registry > > Chr: > > Actually, Rational App. Dev is based on Eclipse 3.0, not the bleeding > edge > 3.2. This is a pain for us as well, as we would like to use at least 3.1 > > plug-ins for our developers, but it's never a good idea to install > Eclipse > plug-ins in to RAD (we've had a lot of problems with that, particularly > the Maven plug-in) > > - > Brandon Werner > > > > > > "Christian Landbo Frederiksen" <[EMAIL PROTECTED]> > > 02/14/2007 11:30 AM > Please respond to > tuscany-user@ws.apache.org > > > To > <tuscany-user@ws.apache.org> > cc > > Subject > RE: SDO (Types) Registry > > > > > > > > I too believe they are related. > > I am currently using Rational App. Dev. which is based on Eclipse 3.2 so > it ought to be able to do what you mention, otherwise I'll download and > set it up in Eclipse. > > A guide to setting it up with regards to patch files would be great. > I'll look into submitting this issue via JIRA. > > Btw. clearing xsdComponentToEModelElementMap didn't help. > > /Chr > > > -----Original Message----- > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > Sent: 14. februar 2007 16:04 > To: tuscany-user@ws.apache.org > Subject: RE: SDO (Types) Registry > > Hi Christian, > > My guess is that both of these problems are related. Unfortunately, I > don't have time to look at it myself right now, but my guess is that you > > probably need to make sure the cached mapping (Yang mentioned below) is > updated. Maybe something like this is needed: > > public void generate(XSDSchema xsdSchema, boolean forceOverwrite) > { > if (forceOverwrite) xsdComponentToEModelElementMap.clear(); > super.generate(xsdSchema); > } > > Yang has volunteered to help get this working, but I think that we need > a > better way to collaborate. Maybe you can open a JIRA request for this > feature and then attach the test case and a patch to it (sending your > changes in emails is very difficult to work with). > > Are you using Eclipse? If so, you should be able to easily create > patch > files and apply patch files that Yang (or I) send you. You should also > be > able to debug the code (including into the EMF code) to understand where > > things are going wrong. Let us know if you need help setting up an > effective development environment. > > Thanks, > Frank > > > "Christian Landbo Frederiksen" <[EMAIL PROTECTED]> > > wrote on 02/14/2007 07:46:23 AM: > > > Yep those are my 2 problems (at the moment) > > > > My problem is that I am looking and debugging in the source and can't > > seem to find out where these things take place. > > > > /Chr > > > > > > -----Original Message----- > > From: Yang ZHONG [mailto:[EMAIL PROTECTED] > > Sent: 13. februar 2007 23:18 > > To: tuscany-user@ws.apache.org > > Subject: Re: SDO (Types) Registry > > > > Very nice to see you participate, it'll be my pleasure to assist you > > through. > > > > If I understand correctly, there're two problems: > > > > 2-1. propertyX, propertyX1, propertyX11 > > > > EMF records original element/attribute name from XML schema; let's > call > > it > > XML name. > > XML name local part may be not unique, Java identifier has different > > syntax, and CodeGen may need some convention, etc, > > so EMF also assigns unique eCore name to > properties/EStructuralFeatures. > > > > EMF derives eCore name from the XML one, and appending 1s to assure > > uniqueness, > > so before addToSortedList/addOrReplaceInSortedList, you may want to > > bypass > > the 1s appending if XML name matches. > > ExtendedMetaData#getNamespace and ExtendedMetaData#getName can give > you > > the > > XML name. > > > > 2-2. null eClass.getEPackage() > > > > EMF contains EClass(complex type) and EDataType(simple type) into > > EPackage. > > Being kicked out of the List by "set" within addOrReplaceInSortedList > > will > > make the EClass/EDataType *not* contained by the EPackage. > > Let me know if you want me to explain more the difference between > > containment and non-containment. > > EMF/SDO EPackage may have a cache mapping from name to > EClass/EDataType, > > and EMF/SDO EClass/Type may also have a cache mapping from name to > > EStructuralFeature/Property whose type is EClass/EDataType used by > code > > such > > as createDataObject. > > You may want to assure those cache are updated accordingly so that the > > kicked-out EClass/EDataType won't be used since whose getEPackage() is > > null. > > > > > > On 2/13/07, Christian Landbo Frederiksen < > > [EMAIL PROTECTED]> wrote: > > > > > > Arghhh just ignore the last one. > > > > > > I was testing with different namespaces :( > > > > > > I still have the nullpointer! > > > > > > Sorry for all the spamming - I'm getting pretty frustrated now. I > > think > > > I'll go to bed.... > > > > > > /Chr > > > > > > > > > -----Original Message----- > > > From: Christian Landbo Frederiksen > > > [mailto:[EMAIL PROTECTED] > > > Sent: 13. februar 2007 22:40 > > > To: tuscany-user@ws.apache.org > > > Subject: RE: SDO (Types) Registry > > > > > > Further info: > > > > > > If I remove the extensibleNamespaces I added to XSDHelperImpl so it > > > again looks like this: > > > > > > if (ePackage == null || > > > TypeHelperImpl.getBuiltInModels().contains(ePackage)) > > > > > > The nullpointerexception does not occur but then the existing types > of > > a > > > namespace does not seem to respond to changes... > > > > > > Ought the extensibleNamespaces change stay in: > > > > > > if (extensibleNamespaces || ePackage == null || > > > TypeHelperImpl.getBuiltInModels().contains(ePackage)) > > > > > > /Chr > > > > > > -----Original Message----- > > > From: Christian Landbo Frederiksen > > > [mailto:[EMAIL PROTECTED] > > > Sent: 13. februar 2007 21:24 > > > To: tuscany-user@ws.apache.org > > > Subject: RE: SDO (Types) Registry > > > > > > Hi Frank > > > > > > I tried adding your code very brute forcely by pulling down > > > computeEClass and computeEDataType from XSDEcoreBuilder to > > > SDOXSDEcoreBuilder, giving these two methods new names and calling > > them > > > from the already existing computeEClass and computeEDataType in > > > SDOXSDEcoreBuilder. In the two pulled down methods I call the > > > addOrReplaceInSortedList instead of addToSortedList. > > > > > > When I debug it it seems to do the trick in the > > addOrReplaceInSortedList > > > method - but once I run it it fails somehow. > > > > > > The XSDHelper.INSTANCE.define method completes fine using the new > > code, > > > but afterward I execute the following (where 'rootElement' is set to > > the > > > root I seek in the particular invocation): > > > > > > DataObject documentDataObject = > > > DataFactory.INSTANCE.create(namespace, "DocumentRoot"); > > > List documentProperties = > > > documentDataObject.getInstanceProperties(); > > > Property rootProperty = null; > > > for (Iterator i = > > documentProperties.iterator(); > > > i.hasNext();) { > > > Property p = (Property) i.next(); > > > // point 1 > > > if (rootElement.equals(p.getName())) > { > > > rootProperty = p; > > > continue; > > > } > > > } > > > > > > if (rootProperty == null) { > > > throw new RuntimeException("FOUND NO > > > ROOT"); > > > } > > > > > > if (!rootProperty.isContainment()) { > > > throw new RuntimeException("ROOT IS > NOT > > > CONTAINMENT: " + rootProperty); > > > } else { > > > // point 2 > > > DataObject rootDataObject = > > > documentDataObject.createDataObject(rootProperty); > > > > > > CompositeXmlElement xmlElement = new > > > CompositeXmlElement(rootDataObject, rootProperty); > > > handleRootDataObject(xmlElement); > > > return xmlElement; > > > } > > > > > > > > > At point 1 I get propertyX, propertyX1, propertyX11 even with the > new > > > code that ought to replace propertyX?? > > > > > > At point 2 I now get: > > > > > > java.lang.NullPointerException > > > at org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2970) > > > at > > > > > > org.apache.tuscany.sdo.util.DataObjectUtil.create(DataObjectUtil.java:24 > > > 72) > > > at > > > > > > org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt > > > il.java:434) > > > at > > > > > > org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt > > > il.java:463) > > > at > > > > > > org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm > > > pl.java:1216) > > > > > > Any ideas (if you can interpret this mail)? > > > > > > /Chr > > > > > > -----Original Message----- > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > > > Sent: 13. februar 2007 18:23 > > > To: tuscany-user@ws.apache.org > > > Subject: RE: SDO (Types) Registry > > > > > > Hi Christian, > > > > > > To replace an existing type, you need to override the behavior of > > > XSDEcoreBuilder methods: createEClass() and createEDataType() to not > > add > > > a > > > duplicate, but instead replace it when found. I noticed that they > both > > > call this method to add the new type: > > > > > > public static void addToSortedList(List eNamedElements, > ENamedElement > > > eNamedElement) > > > { > > > int index = Collections.binarySearch(eNamedElements, > eNamedElement, > > > Comparator.INSTANCE); > > > if (index < 0) > > > { > > > eNamedElements.add(-(index + 1), eNamedElement); > > > } > > > else if (eNamedElements.get(index) != eNamedElement) > > > { > > > eNamedElements.add(index, eNamedElement); > > > } > > > } > > > > > > What you want is to do is something like this instead: > > > > > > public static void addOrReplaceInSortedList(List eNamedElements, > > > ENamedElement eNamedElement) > > > { > > > int index = Collections.binarySearch(eNamedElements, > eNamedElement, > > > Comparator.INSTANCE); > > > if (index < 0) > > > { > > > eNamedElements.add(-(index + 1), eNamedElement); > > > } > > > else if (eNamedElements.get(index) != eNamedElement) > > > { > > > eNamedElements.set(index, eNamedElement); // overwrite existing > > > element > > > } > > > } > > > > > > The only question, is how best to optionally turn on this behavior. > I > > > think that adding something like this in SDOXSDEcoreBuilder: > > > > > > protected boolean overwrite = false; > > > > > > and setting it to true in XSDHelperImpl, when you want this > behavior. > > > > > > Anyway, that's where I'd start. Then you can try to figure out where > > > best > > > to check the variable and change to the alternate > > > addOrReplaceInSortedList() behavior. > > > > > > Let me know how it goes, and if you have any other questions. > > > > > > Frank. > > > > > > > > > "Christian Landbo Frederiksen" > > <[EMAIL PROTECTED]> > > > > > > wrote on 02/12/2007 03:15:52 PM: > > > > > > > Hi Frank et. al. > > > > > > > > First I'll summarize my use case as Yang Zhong requested: > > > > > > > > An xml schema is uploaded and SDO is used to generate a form for > > > > submitting data as xml-instances of the schema. > > > > New schemas in the same namespace may be added often resulting in > > new > > > > forms (this is the first issue where I need to extend existing > > > > namespaces). > > > > > > > > Xml instances may later be edited again. > > > > This is the most common use case and SDO seems to support this > very > > > > well. > > > > > > > > BUT xml schemas may be modified, even individual types. > > > > > > > > This of course flagged some warning signs and schema versions were > > > > considered. > > > > But 'use at own risk' was chosen because of its simplicity. To > > support > > > > this strategy a status/mode will be introduced so xml-instances > > cannot > > > > be edited while schema is in 'administration'-mode. This ought to > > > handle > > > > the case with instances at schema-modification time. > > > > > > > > With regards to serialized xml instances any data that is rendered > > > > invalid with type changes will be reset/deleted as of design. > > > > > > > > I sure like the fact that you say it would not be difficult to > > > implement > > > > replacing existing types and I would greatly appreciate any help > in > > > that > > > > direction. > > > > > > > > /Chr > > > > > > > > > > > > -----Original Message----- > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > > > > Sent: 12. februar 2007 20:37 > > > > To: tuscany-user@ws.apache.org > > > > Subject: RE: SDO (Types) Registry > > > > > > > > Christian, > > > > > > > > I don't think your scenario is beyond the purpose of SDO - In > fact, > > I > > > > see > > > > it as a "real world" example that we should try to accommodate. > > > > > > > > To provide an option that allows you to overwrite/replace existing > > > > types, > > > > would not be difficult to do - but it would be dangerous to use > if, > > > for > > > > example, you have instances of the types at the time you change > > them. > > > > Also, you could end up with corrupt models if, for example, you > > delete > > > a > > > > > > > > type that is referenced by another. What about serialized XML > > > instances? > > > > > > > > If you change a type and then try to load a serialized XML, unless > > the > > > > > > > types are a compatible extension (i.e., only new things added), it > > may > > > > no > > > > longer conform to the schema. What level of versioning does this > > > > requirement imply? > > > > > > > > Would it be acceptable if this option was a "use at own risk" > > feature > > > - > > > > the user needs to be very careful when using it? > > > > > > > > I realize that, as an SDO/EMF novice, you may have a hard time > > finding > > > > the > > > > right places in the code that need to change, so we can help with > > > that, > > > > if > > > > we agree exactly what we're trying to implement. > > > > > > > > Frank. > > > > > > > > "Christian Landbo Frederiksen" > > > <[EMAIL PROTECTED]> > > > > > > > > wrote on 02/12/2007 01:40:25 PM: > > > > > > > > > > > > > > > > > > > Let me first say, I don't not have very much insight into how > > > Tuscany > > > > is > > > > > built up. > > > > > > > > > > I am dealing with a situation where the xsd's, that define the > > > format > > > > of > > > > > a generic data publishing sysem, can be added and changed > > > dynamically > > > > - > > > > > even the individual types of a namespace can be changed > (probably > > > not > > > > > very often). I first looked into EMF XSD and then found Tuscany, > > and > > > > it > > > > > has looked very promising. > > > > > > > > > > Except that I ran into the fact that namespaces cannot be > altered > > > once > > > > > defined. Frank Budinsky came up with a solution where namespaces > > can > > > > be > > > > > extended, but the types that exist already in a namespace cannot > > be > > > > > redefined. > > > > > > > > > > Perhaps this scenario is way beyond the purpose of SDO, but > > besides > > > > > these two issues I find it very useful to work with runtime xml > > > > schemas. > > > > > > > > > > So as you might guess I think an option to totally redefine > > > namespaces > > > > > or to extend them with new types and just overwrite the existing > > > ones, > > > > > would be fine. > > > > > > > > > > This is in fact something I am trying to look into implement > > myself, > > > > but > > > > > at the understanding I'm at now I am having difficulties > > maneuvering > > > > in > > > > > the EMF. I have no idea where defined schemas are currently kept > > in > > > > the > > > > > VM and therefore don't know where to put in the code to allow > > types > > > of > > > > a > > > > > namespace to be redefined. > > > > > > > > > > Any pointers to where this code would go would be GREAT... > > > > > > > > > > /Chr > > > > > > > > > > -----Original Message----- > > > > > From: kelvin goodson [mailto:[EMAIL PROTECTED] > > > > > Sent: 10. februar 2007 13:27 > > > > > To: tuscany-user@ws.apache.org > > > > > Subject: Re: SDO (Types) Registry > > > > > > > > > > Christian, > > > > > > > > > > unfortunately not. The only open JIRA we have in this area is > > > > > http://issues.apache.org/jira/browse/TUSCANY-761 for > unregistering > > > all > > > > > the > > > > > types in a namespace. Perhaps we could collect together some > info > > > on > > > > > what's > > > > > really useful here and have some design discussions on how to > > handle > > > > > type > > > > > lifecycle. There have previously been discussions on forming > > > > > associations > > > > > between HelperContexts so that one HC can have dependencies on > > > > > another/others. This might allow for example dropping type > > > > definitions > > > > > by > > > > > dropping all references to a given HelperContext. It would be > > good > > > to > > > > > know > > > > > exactly which operations would be the most valuable to you in > > order > > > to > > > > > help > > > > > make good design decisions. > > > > > > > > > > Regards, Kelvin. > > > > > > > > > > > > > > > > > > > > On 10/02/07, Christian Landbo Frederiksen < > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Is there no way to 'undefine' types if you have to modify > > existing > > > > > types? > > > > > > > > > > > > /Chr > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > > > > > > Sent: Fri 2/9/2007 5:10 PM > > > > > > To: tuscany-user@ws.apache.org > > > > > > Subject: RE: SDO (Types) Registry > > > > > > > > > > > > > > > > > > > > > > > > If the requirement is just to add new types to a namespace, as > > > > opposed > > > > > to > > > > > > modifying existing types (which is nasty), I don't think it > > would > > > be > > > > > hard > > > > > > to add this support. > > > > > > > > > > > > This is open source, maybe you want to help :-) > > > > > > > > > > > > Initially, I would suggest adding a new instance variable in > > > > > XSDHelperImpl > > > > > > - extensibleNamespaces (false by default, but can be set to > > true) > > > - > > > > > and > > > > > > then change this line in XSDHelperImpl.define(): > > > > > > > > > > > > if (ePackage == null || > TypeHelperImpl.getBuiltInModels > > > > > > ().contains(ePackage)) > > > > > > > > > > > > to this: > > > > > > > > > > > > if (extensibleNamespaces || ePackage == null || > > > > > TypeHelperImpl. > > > > > > getBuiltInModels().contains(ePackage)) > > > > > > > > > > > > Then, it's a matter of debugging to make sure that in > > > > > SDOXSDEcoreBuilder, > > > > > > when a type is requested that already exists, it just uses the > > > > > existing > > > > > > type and moves on. New types would get added in the usual way. > > > > > > > > > > > > I think this may be related to, and helped by, the work that > > will > > > be > > > > > done > > > > > > in TUSCANY-1085 (not the patch provided by Fuhwei, but the > > proper > > > > fix > > > > > that > > > > > > needs to be done), which needs to ensure that previously > loaded > > > > types > > > > > are > > > > > > found in SDOXSDEcoreBuilder. > > > > > > > > > > > > Frank. > > > > > > > > > > > > > > > > > > "Christian Landbo Frederiksen" > > > > > <[EMAIL PROTECTED]> > > > > > > wrote on 02/09/2007 08:36:35 AM: > > > > > > > > > > > > > Hmmm. I just found this in the Dev list: > > > > > > > > > > > > > > "In the future, we may want to look at allowing new types to > > be > > > > > added to > > > > > > > an > > > > > > > existing namespace, but currently that is not supported." - > > > Frank > > > > > > > Budinsky > > > > > > > > > > > > > > If this is not coming up real soon - is there a way to > > > circumvent > > > > > this > > > > > > > using the underlying EMF or something? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christian Landbo Frederiksen > > > > > > > [mailto:[EMAIL PROTECTED] > > > > > > > Sent: 9. februar 2007 14:29 > > > > > > > To: tuscany-user@ws.apache.org > > > > > > > Subject: RE: SDO (Types) Registry > > > > > > > > > > > > > > And then again - that way I can't define from my xsd. > > > > > > > > > > > > > > Dang. How do I solve this? > > > > > > > > > > > > > > /Chr > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christian Landbo Frederiksen > > > > > > > [mailto:[EMAIL PROTECTED] > > > > > > > Sent: 9. februar 2007 14:27 > > > > > > > To: tuscany-user@ws.apache.org > > > > > > > Subject: RE: SDO (Types) Registry > > > > > > > > > > > > > > I have just run into calling define(...) for a schema with > > > > namespace > > > > > > > that has already been defined by another schema does NOT add > > the > > > > > types > > > > > > > from the new schema. > > > > > > > > > > > > > > I suppose I have to register each seperately on its own > > > > typehelper? > > > > > > > > > > > > > > Is there a way to see if a namespace is already defined? > > > > > > > > > > > > > > /Chr > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yang ZHONG [mailto:[EMAIL PROTECTED] > > > > > > > Sent: 27. januar 2007 20:15 > > > > > > > To: tuscany-user@ws.apache.org > > > > > > > Subject: Re: SDO (Types) Registry > > > > > > > > > > > > > > SDO spec seems not addressing the issues yet, here's what I > > know > > > > for > > > > > > > Tuscany > > > > > > > implementation. > > > > > > > > > > > > > > 1. connection between XSDHelper#define and XMLHelper#load > > > > > > > The assumption is right: XSDHelper#define stores Types > into > > > > > > > (Package/Types) Registry and XMLHelper#load uses the Types > > from > > > > > > > the (Package/Types) Registry > > > > > > > > > > > > > > 2. How XMLHelper#load uses Types > > > > > > > Assuming a XML: > > > > > > > <root:stock xmlns:root="NS" ... > > > > > > > XMLHelper#load looks for the Type of the global Property > > with > > > > > > > NameSpace > > > > > > > "NS" and name "stock", and uses the Type to create > DataObject > > > > > instance > > > > > > > then > > > > > > > loads the rest of the XML. > > > > > > > The Type can be dynamic from XSDHelper#define, where the > > > > > DataObject is > > > > > > > an > > > > > > > instance of DataObjectImpl. > > > > > > > The Type can also be static from code generation, where > the > > > > > DataObject > > > > > > > is > > > > > > > an instance of generated class such as MyStock. > > > > > > > If no Type available, XMLHelper#load creates an instance > of > > > > > > > AnyTypeDataObject and loads data without any metadata. > > > > > > > > > > > > > > 3. (Package/Types) Registry Garbage Collection > > > > > > > Types are weakly referenced by ClassLoader. If a (J2EE) > > > > > application > > > > > > > stops, > > > > > > > Types can be Garbage Collected unless a system library (live > > > > > > > ClassLoader) > > > > > > > holds a strong reference. > > > > > > > > > > > > > > 4. (Package/Types) Registry Thread Safety > > > > > > > No Thread Safety for the moment. However it could be done; > > the > > > > > > > previous > > > > > > > SDO implementation I worked on supports Thread Safety for > > > example. > > > > > > > > > > > > > > 5. Two XSDHelper#define for same XSD(s) > > > > > > > The later one overwrites the earlier one if same > > > > > > > scope/application/ClassLoader. If concurrent, slower thread > > > "wins" > > > > > :-) > > > > > > > If different scope/application/ClassLoader, multiple > copies > > > for > > > > > the > > > > > > > moment. However it could be optimized to save both storage > and > > > > > > > defining/loading time; the previous SDO implementation I > > worked > > > on > > > > > > > defines/loads same XSD(s) only once if no modification and > > makes > > > > > Types > > > > > > > available to multiple scopes/applications/ClassLoaders, for > > > > example. > > > > > > > > > > > > > > On 1/27/07, Christian Landbo Frederiksen < > > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > I was wondering what goes on in the background, since SDO > > can > > > be > > > > > used > > > > > > > > the way is is used. > > > > > > > > > > > > > > > > In the example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.tuscany.samples.sdo.specCodeSnippets.CreateDataObjectFromXsdA > > > > > > > > ndXmlFiles > > > > > > > > > > > > > > > > types are defined in one static method like this: > > > > > > > > XSDHelper.INSTANCE.define(is, null); > > > > > > > > > > > > > > > > and then in another static method xml is loaded: > XMLDocument > > > > > xmlDoc = > > > > > > > > XMLHelper.INSTANCE.load(is); > > > > > > > > > > > > > > > > What is the connection between these two separate method > > > > > invocations? > > > > > > > > How does the loading of xml use the types defined above? I > > > > assume > > > > > > > > something is stored somewhere but how does this relate to > > > > garbage > > > > > > > > collection and thread safety? I meas somebody could call > > > > > > > > XSDHelper.INSTANCE.define(is, null); with another xsd > > > somewhere > > > > > else > > > > > > > in > > > > > > > > the same VM? > > > > > > > > > > > > > > > > /Chr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Yang ZHONG > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > -- > > > > Yang ZHONG > > > > --------------------------------------------------------------------- > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ----------------------------------------- > CONFIDENTIALITY STATEMENT: > This e-mail transmission contains information that is intended to > be confidential. It is intended only for the addressee named > above. If you receive this e-mail in error, please do not read, > copy, or disseminate it. If you are not the intended recipient, > any disclosure, copying, distribution or use of the contents of > this information is prohibited. Please reply to the message > immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer > system. Your assistance in correcting this error is appreciated. > > --------------------------------------------------------------------- > 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]
