Further info: If I remove the extensibleNamespaces I added to XSDHelperImpl so it again looks like this:
-----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]
