And that was not a consequense of the DocumentRoot issue?
-----Original Message----- From: Yang ZHONG [mailto:[EMAIL PROTECTED] Sent: 14. februar 2007 22:00 To: tuscany-user@ws.apache.org Subject: Re: SDO (Types) Registry My previous email has mentioned two "TestElementXType", the old and the new one. Do you want to check it out? The new TestElementXType instance is *not* an instance of the old TestElementXType, just like a class instance is not an instance of a class loaded by different ClassLoader from the same .class file. On 2/14/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote: > > Let me just follow up. > > When I don't create the DataObject using the property found on > DocumentRoot > > I get an error doing this: > > System.out.println(XMLHelper.INSTANCE.save(documentDataObject, > namespace, "TestElementX")); > > > java.lang.ClassCastException: The feature 'TestElementX's type > 'TestElementXType' does not permit a value of type 'TestElementXType' > at > org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$BasicFeatureMapEntry.v > alidate(EStructuralFeatureImpl.java:2843) > at > org.eclipse.emf.ecore.util.FeatureMapUtil.createEntry(FeatureMapUtil.jav > a:146) > at > org.eclipse.emf.ecore.util.BasicFeatureMap.createEntry(BasicFeatureMap.j > ava:94) > > /Chr > > -----Original Message----- > From: Christian Landbo Frederiksen > [mailto:[EMAIL PROTECTED] > Sent: 14. februar 2007 20:58 > To: tuscany-user@ws.apache.org > Subject: RE: SDO (Types) Registry > > > The way I read your answer here is that all my problems have been solved > with the changes done so far. > > I fact I did not know that I was trying to add or replace individual > properties in a single type :) > > Total redefinition is fine for me. > > Now I see it is the way I handle DocumentRoot that is the problem and > this is only due to that fact that I don't know how else to get the > correct property. > > If I call DataFactory.INSTANCE.create(namespace, "TestElementXType") I > actually get a dataobject but if I try to generate XML from it the > element isn't called <TestElementX>. That was why I first found the > TestElementX property from the DocumentRoot and the created DataObject > from that. > > Is there a way to create a DataObject using > DataFactory.INSTANCE.create(namespace, "TestElementXType") and then > generate XML with property name <TestElementX> ? > > /Chr > > P.S Is 'Patch' that GNU thing for Linux or is there an eclipse plugin or > something? > > > > -----Original Message----- > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > Sent: 14. februar 2007 20:26 > To: tuscany-user@ws.apache.org > Subject: RE: SDO (Types) Registry > > Looking at your test program, I can see that what you're trying to do is > > more than I thought, so it's going to be harder. Let me explain. > > In the FIRST part, you define a Type named "TestElementXType". Then in > SECOND, you add a second Type: "TestElementYType", which should work > with > the "true" added to XSDHelper.define(), which allows it to proceed. In > the > THIRD part, you redefine Type "TestElementXType", which should work with > > the addToSortedList() change. That's my theory, anyway :-) > > What isn't working, since we haven't done anything to support it, is > incremental addition/modification of the properties in a Type. Right > now, > all we have is the ability to add new types or completely replace a type > > with a new version (like you're doing for TestElementXType in part > THREE). > You can't add to or replace individual properties in a single type, > which > is what you're also trying to do with the global elements/properties in > the "DocumentRoot" Type. > > To test this theory, you could change the global element in the first > schema to something like this: > > <element name="RootElement" type="xsd:AnyType"/> > > and then delete the global elements in the second and third schemas. > > This way, you would define the "DocumentRoot" Type in the first call to > XSDHelper.define() and it would contain the property "RootElement". On > the > second and third calls to TypeHelper.define(), since you have no new > global elements, it won't change/replace the "DocumentRoot", which is > causing the problem. > > I think you should try to get this much working first, then we can think > > about how to specially handle the DocumentRoot. Note that if we just > change things to allow you to also add new properties or change > properties > in a Type, then it wouldn't be doing the right thing to > "TestElementXType" > in the THIRD part - you would have ended up with a "TestElementXType" > that > has 4 properties (2 double and 2 integer) instead of a redefinition. > > Frank. > > P.S. please try to get patch working, so that you can send us just the > delta for existing files that you change. > > > > "Christian Landbo Frederiksen" <[EMAIL PROTECTED]> > > wrote on 02/14/2007 01:30:41 PM: > > > 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] > > > > > --------------------------------------------------------------------- > 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]
