I prototyped some work in that area for Tuscany ( http://issues.apache.org/jira/browse/TUSCANY-677), see the email thread if interested ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg07197.html). It was very long :-)
It was paused due to only one client (Fuhwei) and Tuscany (SDO) wasn't convinced such a requirement. This's open source, is it possble for you to contribute your Use Case? Maybe others have better solution(s) than loading/refreshing on demand... On 2/12/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote:
Yes! That sounds right. Any pointers as to how one could do that :) ? /Chr -----Original Message----- From: Yang ZHONG [mailto:[EMAIL PROTECTED] Sent: 12. februar 2007 20:03 To: tuscany-user@ws.apache.org Subject: Re: SDO (Types) Registry (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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Yang ZHONG
