It would be good if you could send us a patch with the changes you made and a test case you're trying to run. Then we can look at it while we help you get it working.
Thanks, Frank "Christian Landbo Frederiksen" <[EMAIL PROTECTED]> wrote on 02/13/2007 04:47:11 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
