This seemed to do the trick as it does extend the namespace. If I define a schema twice the types are added again so when I later extract properties I see propertyX, propertyX1, propertyX2 and so on one for each time I called define with the same schema. Is there a way to check for the presence of a type so it is not added twice - perhaps one could decide if the existing type should be overridden during the new define? I guess from your answer that one shold look within the SDOXSDEcoreBuilder? /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]
