(Package/Types) Registry can be designed/implemented to load/refresh on demand to address your requirement, such as:
1. Runtime/user queries the Registry 2. If type wasn't loaded, load it; Otherwise, if source was updated, reload it The previous Registry version I worked on executed that way to support user to edit XSDs dynamically. On 2/12/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote:
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]
-- Yang ZHONG
