You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Yang ZHONG <le...@gmail.com> on 2007/01/27 20:14:53 UTC
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
RE: SDO (Types) Registry
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
That is not really an option.
I agree that it would work, but schemas may be defined dynamically using
the same namespace, so...
/Chr
-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com]
Sent: 9. februar 2007 15:07
To: tuscany-user@ws.apache.org
Subject: Re: SDO (Types) Registry
Christian,
what's the scenario here? Are you in control of the registration of
all
the schemata that contribute to the namespace? Can you create an
uber-schema that includes all the others and then define the types using
that? My guess is that there are other constraints that prevent you
from
doing that. I haven't tried it but I've a feeling that that would
work?
Regards Kelvin.
On 09/02/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> 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
Re: SDO (Types) Registry
Posted by kelvin goodson <ke...@gmail.com>.
Christian,
what's the scenario here? Are you in control of the registration of all
the schemata that contribute to the namespace? Can you create an
uber-schema that includes all the others and then define the types using
that? My guess is that there are other constraints that prevent you from
doing that. I haven't tried it but I've a feeling that that would work?
Regards Kelvin.
On 09/02/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> 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
>
>
Re: SDO (Types) Registry
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Frank Budinsky wrote:
> 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.
>
>
>
I'm interested in this support too for some SCA scenarios where a
namespace is defined across multiple files, or I when I come across
copies of the same XML schema element or type definitions inlined in
multiple WSDL files (for example 2 WSDL files defining
portType/operations flowing a <customer> element, and the schema
defining the <customer> element is inlined in the 2 WSDLs, this is a
very very common case as most WSDLs inline their schema definitions).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SDO (Types) Registry
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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" <Ch...@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
RE: SDO (Types) Registry
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
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
RE: SDO (Types) Registry
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
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
RE: SDO (Types) Registry
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
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