tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Budinsky <fra...@ca.ibm.com>
Subject RE: SDO (Types) Registry
Date Mon, 12 Feb 2007 19:37:05 GMT
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" <Christian.Landbo.Frederiksen@ementor.dk> 
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:kelvingoodson@gmail.com] 
> 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 <
> Christian.Landbo.Frederiksen@ementor.dk> wrote:
> >
> > Is there no way to 'undefine' types if you have to modify existing
> types?
> >
> > /Chr
> >
> > ________________________________
> >
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > 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"
> <Christian.Landbo.Frederiksen@ementor.dk>
> > 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:Christian.Landbo.Frederiksen@ementor.dk]
> > > 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:Christian.Landbo.Frederiksen@ementor.dk]
> > > 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:leiwang.yangzhong@gmail.com]
> > > 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 <
> > > Christian.Landbo.Frederiksen@ementor.dk> 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: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org


Mime
View raw message