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/02/10 19:28:52 UTC
[Java] StAX and EMF to build Tuscany in RAD
Java 6 has javax.xml.stream (StAX), otherwise you can search RAD for StAX
API and impl PlugIn/bundle. There're also free version(s) to download.
Tuscany SDO supports EMF 2.2.1 and 2.2.2(
http://issues.apache.org/jira/browse/TUSCANY-1102).
RAD may support different EMF version in different PlugIn/bundle, just need
to declare your dependency specifically. Eclipse newsgroup may be a resource
if help needed.
On 2/10/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> I have just checked out the latest build into my Rational Application
> Developer 7 (using jdk 1.5) and get some issues with 'javax.xml.stream'
> classes that are unknown plus some asm class that is missing.
>
> Also I have the EMF 2.3 files present but it seems it that they don't
> match the Tuscany source...
>
> Could somebody guide me a bit so that I'm able to build it in my RAD7?
>
> /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" <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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
--
Yang ZHONG
RE: [Java] StAX and EMF to build Tuscany in RAD
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
It seems it was some path issue with 'META-INF/services/commonj.sdo.impl.HelperProvider'.
I have solved it.
/Chr
________________________________
From: Christian Landbo Frederiksen [mailto:Christian.Landbo.Frederiksen@ementor.dk]
Sent: Sun 2/11/2007 10:17 AM
To: tuscany-user@ws.apache.org
Subject: RE: [Java] StAX and EMF to build Tuscany in RAD
Ok thanks.
Now I can build it, but when I run my code that functioned before I now get:
java.lang.NullPointerException
at commonj.sdo.impl.HelperProvider.getXSDHelper(HelperProvider.java:346)
at commonj.sdo.helper.XSDHelper.<clinit>(XSDHelper.java:192)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
I suppose there are some settings I am lacking??
Any ideas?
/Chr
________________________________
From: Yang ZHONG [mailto:leiwang.yangzhong@gmail.com]
Sent: Sat 2/10/2007 7:28 PM
To: tuscany-user@ws.apache.org
Subject: [Java] StAX and EMF to build Tuscany in RAD
Java 6 has javax.xml.stream (StAX), otherwise you can search RAD for StAX
API and impl PlugIn/bundle. There're also free version(s) to download.
Tuscany SDO supports EMF 2.2.1 and 2.2.2(
http://issues.apache.org/jira/browse/TUSCANY-1102).
RAD may support different EMF version in different PlugIn/bundle, just need
to declare your dependency specifically. Eclipse newsgroup may be a resource
if help needed.
On 2/10/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> I have just checked out the latest build into my Rational Application
> Developer 7 (using jdk 1.5) and get some issues with 'javax.xml.stream'
> classes that are unknown plus some asm class that is missing.
>
> Also I have the EMF 2.3 files present but it seems it that they don't
> match the Tuscany source...
>
> Could somebody guide me a bit so that I'm able to build it in my RAD7?
>
> /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" <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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
--
Yang ZHONG
RE: [Java] StAX and EMF to build Tuscany in RAD
Posted by Christian Landbo Frederiksen <Ch...@ementor.dk>.
Ok thanks.
Now I can build it, but when I run my code that functioned before I now get:
java.lang.NullPointerException
at commonj.sdo.impl.HelperProvider.getXSDHelper(HelperProvider.java:346)
at commonj.sdo.helper.XSDHelper.<clinit>(XSDHelper.java:192)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
I suppose there are some settings I am lacking??
Any ideas?
/Chr
________________________________
From: Yang ZHONG [mailto:leiwang.yangzhong@gmail.com]
Sent: Sat 2/10/2007 7:28 PM
To: tuscany-user@ws.apache.org
Subject: [Java] StAX and EMF to build Tuscany in RAD
Java 6 has javax.xml.stream (StAX), otherwise you can search RAD for StAX
API and impl PlugIn/bundle. There're also free version(s) to download.
Tuscany SDO supports EMF 2.2.1 and 2.2.2(
http://issues.apache.org/jira/browse/TUSCANY-1102).
RAD may support different EMF version in different PlugIn/bundle, just need
to declare your dependency specifically. Eclipse newsgroup may be a resource
if help needed.
On 2/10/07, Christian Landbo Frederiksen <
Christian.Landbo.Frederiksen@ementor.dk> wrote:
>
> I have just checked out the latest build into my Rational Application
> Developer 7 (using jdk 1.5) and get some issues with 'javax.xml.stream'
> classes that are unknown plus some asm class that is missing.
>
> Also I have the EMF 2.3 files present but it seems it that they don't
> match the Tuscany source...
>
> Could somebody guide me a bit so that I'm able to build it in my RAD7?
>
> /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" <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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
--
Yang ZHONG