You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlbeans-user@xml.apache.org by Arne Jacobs <ja...@tzi.de> on 2003/11/18 17:22:32 UTC
problem with SchemaTypeLoaders and xsi:type attributes
i'm using the XmlBeans.compileXsd() method to compile an XML schema at
runtime (i don't create a hierarchy of java classes).
if i now use the resulting SchemaTypeSystem to construct an xml document
at runtime (with the help of the XmlCursor class), i find that
everything works fine, except in the case where derived types should be
used with the xsi:type (from the xml instance schema) attribute.
the problem seems to be that, when resolving the given derived type in
the XmlObject.set() or the XmlObject.validate() methods, the only
SchemaTypeLoader which is searched for that type, is the built in type
system. XmlBeans also searches the file system for .xsb files, which i
do not have (compiled at runtime...).
when parsing the result of the xmlText() method of the said xml document
using a "typeloaderunion" of my compiled SchemaTypeSystem and the built
in type system, the document is found valid. in this case, both type
systems are search for the derived type and this found in my
runtime-compiled SchemaTypeSystem.
i know wonder how i can get the XmlBeans to search my own
SchemaTypeSystem when constructing the xml document at runtime, too.
i don't want to have to compile the java classes and .xsb-files each
time i use another schema...
hoping that you can help me,
jarne
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by Arne Jacobs <ja...@tzi.de>.
thank you very much! that solved my problem. i begin to understand how
that all works... ;)
jarne
David Bau schrieb:
>>- i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
>>xml schema i compile at runtime (i'm mapping it to a relational database
>>structure). this point is not critical, though: i think when i use
>>loadXsd() to compile the schema, i still have access to the underlying
>>typesystem through the SchemaType.getTypeSystem() method. is that right?
>
>
> The paragraph above is all correct.
>
> LoadXSD is a convenience wrapper for compileXsd and union.
>
> If you step into the code for loadXsd, you will see that all it does is
> (1) call compileXsd to get a SchemaTypeSystem out, using the context type
> loader as the "classpath" for compilation.
> (2) call unionTypeLoader on the result merge it with the context type
> loader.
>
> You can do the two steps by hand if you want, and hold on to the schema type
> system by hand, and then do the union by hand to make a schematypeloader
> that can actually create useful instances.
>
> Or if you do things by hand, you can use the builtin type system instead of
> the context type loader for linking and unioning. (Builtin == just the 46
> built-in types, context == those plus any types in JARs on your classpath.)
>
>
>
>>- i want to construct an xml document at runtime, from scratch, using
>
> ...
>
>>is it just that i have to make a union of my SchemaTypeSystem and the
>>built in typesystem _before_ constructing/validating my XmlObject? how
>>do the XmlBeans get to know that i want to use that union to
>>construct/validate my XmlObject?
>
>
> Yes.
>
> If starting from absolutely nothing, you can use
> SchemaTypeLoader.newInstance(sType, options) to create a completely empty
> document.
>
> For the schema type you will want to either pass:
>
> (1) XmlObject.type (the xs:anyType) if you want to apply anyType's open
> content rules.
> (2) Your own FooDocument.type (or a document type object that you've loaded
> from your schematypeloader) if you want to force the document to have a
> specific top-level element.
> (3) Or XmlBeans.NO_TYPE if you want validate() to always return "false".
>
> Or, if the root type is not something you can decide until later, you can
> just begin by using the NO_TYPE, and then when you figure out the proper
> root type to use, you can call xmlobj.changeType() to change the type at the
> root. (Be aware that changeType will return a new XmlObject instance, since
> it may have to change to a different underlying Java class.)
>
> David
>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by Arne Jacobs <ja...@tzi.de>.
thank you very much! that solved my problem. i begin to understand how
that all works... ;)
jarne
David Bau schrieb:
>>- i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
>>xml schema i compile at runtime (i'm mapping it to a relational database
>>structure). this point is not critical, though: i think when i use
>>loadXsd() to compile the schema, i still have access to the underlying
>>typesystem through the SchemaType.getTypeSystem() method. is that right?
>
>
> The paragraph above is all correct.
>
> LoadXSD is a convenience wrapper for compileXsd and union.
>
> If you step into the code for loadXsd, you will see that all it does is
> (1) call compileXsd to get a SchemaTypeSystem out, using the context type
> loader as the "classpath" for compilation.
> (2) call unionTypeLoader on the result merge it with the context type
> loader.
>
> You can do the two steps by hand if you want, and hold on to the schema type
> system by hand, and then do the union by hand to make a schematypeloader
> that can actually create useful instances.
>
> Or if you do things by hand, you can use the builtin type system instead of
> the context type loader for linking and unioning. (Builtin == just the 46
> built-in types, context == those plus any types in JARs on your classpath.)
>
>
>
>>- i want to construct an xml document at runtime, from scratch, using
>
> ...
>
>>is it just that i have to make a union of my SchemaTypeSystem and the
>>built in typesystem _before_ constructing/validating my XmlObject? how
>>do the XmlBeans get to know that i want to use that union to
>>construct/validate my XmlObject?
>
>
> Yes.
>
> If starting from absolutely nothing, you can use
> SchemaTypeLoader.newInstance(sType, options) to create a completely empty
> document.
>
> For the schema type you will want to either pass:
>
> (1) XmlObject.type (the xs:anyType) if you want to apply anyType's open
> content rules.
> (2) Your own FooDocument.type (or a document type object that you've loaded
> from your schematypeloader) if you want to force the document to have a
> specific top-level element.
> (3) Or XmlBeans.NO_TYPE if you want validate() to always return "false".
>
> Or, if the root type is not something you can decide until later, you can
> just begin by using the NO_TYPE, and then when you figure out the proper
> root type to use, you can call xmlobj.changeType() to change the type at the
> root. (Be aware that changeType will return a new XmlObject instance, since
> it may have to change to a different underlying Java class.)
>
> David
>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by David Bau <da...@bea.com>.
> - i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
> xml schema i compile at runtime (i'm mapping it to a relational database
> structure). this point is not critical, though: i think when i use
> loadXsd() to compile the schema, i still have access to the underlying
> typesystem through the SchemaType.getTypeSystem() method. is that right?
The paragraph above is all correct.
LoadXSD is a convenience wrapper for compileXsd and union.
If you step into the code for loadXsd, you will see that all it does is
(1) call compileXsd to get a SchemaTypeSystem out, using the context type
loader as the "classpath" for compilation.
(2) call unionTypeLoader on the result merge it with the context type
loader.
You can do the two steps by hand if you want, and hold on to the schema type
system by hand, and then do the union by hand to make a schematypeloader
that can actually create useful instances.
Or if you do things by hand, you can use the builtin type system instead of
the context type loader for linking and unioning. (Builtin == just the 46
built-in types, context == those plus any types in JARs on your classpath.)
> - i want to construct an xml document at runtime, from scratch, using
...
> is it just that i have to make a union of my SchemaTypeSystem and the
> built in typesystem _before_ constructing/validating my XmlObject? how
> do the XmlBeans get to know that i want to use that union to
> construct/validate my XmlObject?
Yes.
If starting from absolutely nothing, you can use
SchemaTypeLoader.newInstance(sType, options) to create a completely empty
document.
For the schema type you will want to either pass:
(1) XmlObject.type (the xs:anyType) if you want to apply anyType's open
content rules.
(2) Your own FooDocument.type (or a document type object that you've loaded
from your schematypeloader) if you want to force the document to have a
specific top-level element.
(3) Or XmlBeans.NO_TYPE if you want validate() to always return "false".
Or, if the root type is not something you can decide until later, you can
just begin by using the NO_TYPE, and then when you figure out the proper
root type to use, you can call xmlobj.changeType() to change the type at the
root. (Be aware that changeType will return a new XmlObject instance, since
it may have to change to a different underlying Java class.)
David
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by David Bau <da...@bea.com>.
> - i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
> xml schema i compile at runtime (i'm mapping it to a relational database
> structure). this point is not critical, though: i think when i use
> loadXsd() to compile the schema, i still have access to the underlying
> typesystem through the SchemaType.getTypeSystem() method. is that right?
The paragraph above is all correct.
LoadXSD is a convenience wrapper for compileXsd and union.
If you step into the code for loadXsd, you will see that all it does is
(1) call compileXsd to get a SchemaTypeSystem out, using the context type
loader as the "classpath" for compilation.
(2) call unionTypeLoader on the result merge it with the context type
loader.
You can do the two steps by hand if you want, and hold on to the schema type
system by hand, and then do the union by hand to make a schematypeloader
that can actually create useful instances.
Or if you do things by hand, you can use the builtin type system instead of
the context type loader for linking and unioning. (Builtin == just the 46
built-in types, context == those plus any types in JARs on your classpath.)
> - i want to construct an xml document at runtime, from scratch, using
...
> is it just that i have to make a union of my SchemaTypeSystem and the
> built in typesystem _before_ constructing/validating my XmlObject? how
> do the XmlBeans get to know that i want to use that union to
> construct/validate my XmlObject?
Yes.
If starting from absolutely nothing, you can use
SchemaTypeLoader.newInstance(sType, options) to create a completely empty
document.
For the schema type you will want to either pass:
(1) XmlObject.type (the xs:anyType) if you want to apply anyType's open
content rules.
(2) Your own FooDocument.type (or a document type object that you've loaded
from your schematypeloader) if you want to force the document to have a
specific top-level element.
(3) Or XmlBeans.NO_TYPE if you want validate() to always return "false".
Or, if the root type is not something you can decide until later, you can
just begin by using the NO_TYPE, and then when you figure out the proper
root type to use, you can call xmlobj.changeType() to change the type at the
root. (Be aware that changeType will return a new XmlObject instance, since
it may have to change to a different underlying Java class.)
David
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by Arne Jacobs <ja...@tzi.de>.
hi,
and thanks for your quick answer! i thought about that, but there are
two issues that prevent me from doing it like you suggest:
- i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
xml schema i compile at runtime (i'm mapping it to a relational database
structure). this point is not critical, though: i think when i use
loadXsd() to compile the schema, i still have access to the underlying
typesystem through the SchemaType.getTypeSystem() method. is that right?
- i want to construct an xml document at runtime, from scratch, using
the XmlCursor class. the parse() method only allows me to parse (ok, i
can't find a better description) an xml document from a string or
similar representation, which is not what i need :(
i stepped through the code and noticed that, when parsing the string
representation of my newly constructed xml document (with a union of my
SchemaTypeSystem and the built in typesystem), then validating it, the
XmlBeans are looking for the type specified with the xsi:type attribute
in my SchemaTypeSystem (what i find intuitive). when validating the
XmlObject constructed with the XmlCursor class, what do i have to do to
make the XmlBeans look in my own SchemaTypeSystem, too?
is it just that i have to make a union of my SchemaTypeSystem and the
built in typesystem _before_ constructing/validating my XmlObject? how
do the XmlBeans get to know that i want to use that union to
construct/validate my XmlObject?
hoping, that this is not a too lengthy and boring description ;),
jarne
David Bau schrieb:
> Yes. By default, you use the thread's context typeloader, which by default
> uses the context classloader to load types only from the JARs on your
> classpath.
>
> Instead, you'll want to use your own schematypeloader and create instances
> from that. You'll want to:
>
> 1. build a schematypeloader that includes your schematypesystem. (e.g., use
> XmlBeans.typeLoaderUnion to put it together with iether the builtin or
> context typeloader, or use loadXsd instead of copmileXsd, which does that
> for you). You just need to make sure your schematypeloader is
> self-consistent, i.e., it has all the builtin types etc.
>
> 2. use the .parse(..) methods that appear on SchemaTypeLoader instead of the
> *.Factory.parse methods. The only difference is that the *.Factory.parse
> methods use the context typeloader all the time, which loads schema types
> only off of the JARs on your classpath.
>
> That's it!
>
> David
>
> ----- Original Message -----
> From: "Arne Jacobs" <ja...@tzi.de>
> To: <xm...@xml.apache.org>
> Sent: Tuesday, November 18, 2003 11:22 AM
> Subject: [xmlbeans-dev] problem with SchemaTypeLoaders and xsi:type
> attributes
>
>
>
>>i'm using the XmlBeans.compileXsd() method to compile an XML schema at
>>runtime (i don't create a hierarchy of java classes).
>>
>>if i now use the resulting SchemaTypeSystem to construct an xml document
>>at runtime (with the help of the XmlCursor class), i find that
>>everything works fine, except in the case where derived types should be
>>used with the xsi:type (from the xml instance schema) attribute.
>>
>>the problem seems to be that, when resolving the given derived type in
>>the XmlObject.set() or the XmlObject.validate() methods, the only
>>SchemaTypeLoader which is searched for that type, is the built in type
>>system. XmlBeans also searches the file system for .xsb files, which i
>>do not have (compiled at runtime...).
>>
>>when parsing the result of the xmlText() method of the said xml document
>>using a "typeloaderunion" of my compiled SchemaTypeSystem and the built
>>in type system, the document is found valid. in this case, both type
>>systems are search for the derived type and this found in my
>>runtime-compiled SchemaTypeSystem.
>>
>>i know wonder how i can get the XmlBeans to search my own
>>SchemaTypeSystem when constructing the xml document at runtime, too.
>>
>>i don't want to have to compile the java classes and .xsb-files each
>>time i use another schema...
>>
>>hoping that you can help me,
>>
>>jarne
>>
>>
>>- ---------------------------------------------------------------------
>>To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
>>For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
>>Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>>
>>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: problem with SchemaTypeLoaders and xsi:type attributes
Posted by Arne Jacobs <ja...@tzi.de>.
hi,
and thanks for your quick answer! i thought about that, but there are
two issues that prevent me from doing it like you suggest:
- i need a SchemaTypeSystem, not only a SchemaTypeLoader, to examine the
xml schema i compile at runtime (i'm mapping it to a relational database
structure). this point is not critical, though: i think when i use
loadXsd() to compile the schema, i still have access to the underlying
typesystem through the SchemaType.getTypeSystem() method. is that right?
- i want to construct an xml document at runtime, from scratch, using
the XmlCursor class. the parse() method only allows me to parse (ok, i
can't find a better description) an xml document from a string or
similar representation, which is not what i need :(
i stepped through the code and noticed that, when parsing the string
representation of my newly constructed xml document (with a union of my
SchemaTypeSystem and the built in typesystem), then validating it, the
XmlBeans are looking for the type specified with the xsi:type attribute
in my SchemaTypeSystem (what i find intuitive). when validating the
XmlObject constructed with the XmlCursor class, what do i have to do to
make the XmlBeans look in my own SchemaTypeSystem, too?
is it just that i have to make a union of my SchemaTypeSystem and the
built in typesystem _before_ constructing/validating my XmlObject? how
do the XmlBeans get to know that i want to use that union to
construct/validate my XmlObject?
hoping, that this is not a too lengthy and boring description ;),
jarne
David Bau schrieb:
> Yes. By default, you use the thread's context typeloader, which by default
> uses the context classloader to load types only from the JARs on your
> classpath.
>
> Instead, you'll want to use your own schematypeloader and create instances
> from that. You'll want to:
>
> 1. build a schematypeloader that includes your schematypesystem. (e.g., use
> XmlBeans.typeLoaderUnion to put it together with iether the builtin or
> context typeloader, or use loadXsd instead of copmileXsd, which does that
> for you). You just need to make sure your schematypeloader is
> self-consistent, i.e., it has all the builtin types etc.
>
> 2. use the .parse(..) methods that appear on SchemaTypeLoader instead of the
> *.Factory.parse methods. The only difference is that the *.Factory.parse
> methods use the context typeloader all the time, which loads schema types
> only off of the JARs on your classpath.
>
> That's it!
>
> David
>
> ----- Original Message -----
> From: "Arne Jacobs" <ja...@tzi.de>
> To: <xm...@xml.apache.org>
> Sent: Tuesday, November 18, 2003 11:22 AM
> Subject: [xmlbeans-dev] problem with SchemaTypeLoaders and xsi:type
> attributes
>
>
>
>>i'm using the XmlBeans.compileXsd() method to compile an XML schema at
>>runtime (i don't create a hierarchy of java classes).
>>
>>if i now use the resulting SchemaTypeSystem to construct an xml document
>>at runtime (with the help of the XmlCursor class), i find that
>>everything works fine, except in the case where derived types should be
>>used with the xsi:type (from the xml instance schema) attribute.
>>
>>the problem seems to be that, when resolving the given derived type in
>>the XmlObject.set() or the XmlObject.validate() methods, the only
>>SchemaTypeLoader which is searched for that type, is the built in type
>>system. XmlBeans also searches the file system for .xsb files, which i
>>do not have (compiled at runtime...).
>>
>>when parsing the result of the xmlText() method of the said xml document
>>using a "typeloaderunion" of my compiled SchemaTypeSystem and the built
>>in type system, the document is found valid. in this case, both type
>>systems are search for the derived type and this found in my
>>runtime-compiled SchemaTypeSystem.
>>
>>i know wonder how i can get the XmlBeans to search my own
>>SchemaTypeSystem when constructing the xml document at runtime, too.
>>
>>i don't want to have to compile the java classes and .xsb-files each
>>time i use another schema...
>>
>>hoping that you can help me,
>>
>>jarne
>>
>>
>>- ---------------------------------------------------------------------
>>To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
>>For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
>>Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>>
>>
>
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re:problem with SchemaTypeLoaders and xsi:type attributes
Posted by David Bau <da...@bea.com>.
Yes. By default, you use the thread's context typeloader, which by default
uses the context classloader to load types only from the JARs on your
classpath.
Instead, you'll want to use your own schematypeloader and create instances
from that. You'll want to:
1. build a schematypeloader that includes your schematypesystem. (e.g., use
XmlBeans.typeLoaderUnion to put it together with iether the builtin or
context typeloader, or use loadXsd instead of copmileXsd, which does that
for you). You just need to make sure your schematypeloader is
self-consistent, i.e., it has all the builtin types etc.
2. use the .parse(..) methods that appear on SchemaTypeLoader instead of the
*.Factory.parse methods. The only difference is that the *.Factory.parse
methods use the context typeloader all the time, which loads schema types
only off of the JARs on your classpath.
That's it!
David
----- Original Message -----
From: "Arne Jacobs" <ja...@tzi.de>
To: <xm...@xml.apache.org>
Sent: Tuesday, November 18, 2003 11:22 AM
Subject: [xmlbeans-dev] problem with SchemaTypeLoaders and xsi:type
attributes
> i'm using the XmlBeans.compileXsd() method to compile an XML schema at
> runtime (i don't create a hierarchy of java classes).
>
> if i now use the resulting SchemaTypeSystem to construct an xml document
> at runtime (with the help of the XmlCursor class), i find that
> everything works fine, except in the case where derived types should be
> used with the xsi:type (from the xml instance schema) attribute.
>
> the problem seems to be that, when resolving the given derived type in
> the XmlObject.set() or the XmlObject.validate() methods, the only
> SchemaTypeLoader which is searched for that type, is the built in type
> system. XmlBeans also searches the file system for .xsb files, which i
> do not have (compiled at runtime...).
>
> when parsing the result of the xmlText() method of the said xml document
> using a "typeloaderunion" of my compiled SchemaTypeSystem and the built
> in type system, the document is found valid. in this case, both type
> systems are search for the derived type and this found in my
> runtime-compiled SchemaTypeSystem.
>
> i know wonder how i can get the XmlBeans to search my own
> SchemaTypeSystem when constructing the xml document at runtime, too.
>
> i don't want to have to compile the java classes and .xsb-files each
> time i use another schema...
>
> hoping that you can help me,
>
> jarne
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re:problem with SchemaTypeLoaders and xsi:type attributes
Posted by David Bau <da...@bea.com>.
Yes. By default, you use the thread's context typeloader, which by default
uses the context classloader to load types only from the JARs on your
classpath.
Instead, you'll want to use your own schematypeloader and create instances
from that. You'll want to:
1. build a schematypeloader that includes your schematypesystem. (e.g., use
XmlBeans.typeLoaderUnion to put it together with iether the builtin or
context typeloader, or use loadXsd instead of copmileXsd, which does that
for you). You just need to make sure your schematypeloader is
self-consistent, i.e., it has all the builtin types etc.
2. use the .parse(..) methods that appear on SchemaTypeLoader instead of the
*.Factory.parse methods. The only difference is that the *.Factory.parse
methods use the context typeloader all the time, which loads schema types
only off of the JARs on your classpath.
That's it!
David
----- Original Message -----
From: "Arne Jacobs" <ja...@tzi.de>
To: <xm...@xml.apache.org>
Sent: Tuesday, November 18, 2003 11:22 AM
Subject: [xmlbeans-dev] problem with SchemaTypeLoaders and xsi:type
attributes
> i'm using the XmlBeans.compileXsd() method to compile an XML schema at
> runtime (i don't create a hierarchy of java classes).
>
> if i now use the resulting SchemaTypeSystem to construct an xml document
> at runtime (with the help of the XmlCursor class), i find that
> everything works fine, except in the case where derived types should be
> used with the xsi:type (from the xml instance schema) attribute.
>
> the problem seems to be that, when resolving the given derived type in
> the XmlObject.set() or the XmlObject.validate() methods, the only
> SchemaTypeLoader which is searched for that type, is the built in type
> system. XmlBeans also searches the file system for .xsb files, which i
> do not have (compiled at runtime...).
>
> when parsing the result of the xmlText() method of the said xml document
> using a "typeloaderunion" of my compiled SchemaTypeSystem and the built
> in type system, the document is found valid. in this case, both type
> systems are search for the derived type and this found in my
> runtime-compiled SchemaTypeSystem.
>
> i know wonder how i can get the XmlBeans to search my own
> SchemaTypeSystem when constructing the xml document at runtime, too.
>
> i don't want to have to compile the java classes and .xsb-files each
> time i use another schema...
>
> hoping that you can help me,
>
> jarne
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/