You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@xmlbeans.apache.org by Radu Preotiuc-Pietro <ra...@bea.com> on 2005/02/09 02:44:55 UTC
RE: ClassCastException using changeType()
Ok, we now have a sample for using abstract types and multiple jars. Here is the link:
http://xmlbeans.apache.org/samples/AbstractTypes.html
Radu
-----Original Message-----
From: Radu Preotiuc-Pietro
Sent: Thursday, January 20, 2005 4:25 PM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Ok, I will put together a sample on the wiki that tries to do what you are suggesting.
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Thursday, January 20, 2005 9:44 AM
To: user@xmlbeans.apache.org
Cc: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
I could get around my problems * if * I can get multiple concrete type extension from different schemas/namespaces to work during a changeType() to either concrete, by building a tool that would re-build all of the concrete data bindings, including the abstract, that could ever be needed at runtime when a new plugin is developed. This would not be ideal and not be very dynamic - but it would ok for now.
-----But is still seems I can not do this -
-How do I try running the schemacompiler across multiple schemas at the same time (not meaning pulling in imports, but giving the schema compiler essentially two starting concrete schemas that extend the same abstract type in the common abstract schema). I think this is what you suggested earlier, but I don't see how to do it.
I still have the situation where I can only changeType correctly to the last concrete schema compiled. Without some fix on this, I can not use XML Beans.....
hope someone can help.
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com>
"Radu Preotiuc-Pietro" <ra...@bea.com>
01/19/2005 01:49 PM Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Agreed, what you want to do makes sense and should be possible. Now to why doesn't it work for you .... I think either you put together a stripped-down repro so I can take a look at it, or I try to put together an example that hopefully will work. It's either a bug that we need to fix or some detail in what you're doing.
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Wednesday, January 19, 2005 9:34 AM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Radu,
>When you first compile SchemaConcreteA,B,C you automatically pull in SchemaAbstractBase, because it is needed in order to resolve the base type references. That >creates some SchemaTypes with an identity (set a)
>When you subsequently compile SchemaReferencesAbstractBase you automatically pull SchemaAbstractBase in again, because it is needed. This creates another set >of types, including the types in SchemaAbstractBase, but with a different identity (set b). Now, unfortunately the SchemaAbstractBase types in (a) are different than >SchemaAbstractBase types in (b), therefore your SchemaConcreteA,B,C don't extend the latter.
yes that it what appears is happening.
>There are good reasons for this design decision. Basically, when you have a reference to a type that can be found either in the set of current Schemas that you compile >or in a set of already compiled Schemas, we always resolve the reference internally. Also, if you want to declare a new type with a name equal to that of another type >that was compiled previously, we let you do it, we have to.
yes good logic, but. I have now rebuilt the abstract set into its own jar file. -what I am trying to do is to allow somebody to later on use the abstract schema and define a concrete type of it, use the already-built abstract jar (and set A types I guess) and build a concrete jar. All of this works at build time. at runtime, what I want to do is to dynamically changeType() on an abstract instance to his new class (using a class loader to load his schema-compiler generated concrete class type). this is what does not work........Think what I am doing is building an an XML Framework with a concrete plugins........
>Have you confirmed that the problem still occurs if all the Schemas are compiled simultaneously? If it still does, all I said earlier is just general info.
have not tried it.
>As to why you can use only the last SchemaConcrete in your other case, it must be some peculiarity which I can't detect from the set of information you provide in this >e-mail. In any case, xsb files are never clobbered, though it is the case that a runtime QName lookup for a particular entity will find the first entity with that name and kind >(element, type etc) available on the classpath, just as in Java, so there is an obscuring effect going on, which you would expect.
I think it comes down to the ability to changeType() in code using a different identity set than the code being to changed to. this may not be able to work under the current design of XMLBeans.............or is there some other suggestion on how to do this?
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com>
"Radu Preotiuc-Pietro" <ra...@bea.com>
01/11/2005 07:22 PM
Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Hm, I think I know what's happening, I'll try to guess based on the information that you provide:
When you first compile SchemaConcreteA,B,C you automatically pull in SchemaAbstractBase, because it is needed in order to resolve the base type references. That creates some SchemaTypes with an identity (set a)
When you subsequently compile SchemaReferencesAbstractBase you automatically pull SchemaAbstractBase in again, because it is needed. This creates another set of types, including the types in SchemaAbstractBase, but with a different identity (set b). Now, unfortunately the SchemaAbstractBase types in (a) are different than SchemaAbstractBase types in (b), therefore your SchemaConcreteA,B,C don't extend the latter. There are good reasons for this design decision. Basically, when you have a reference to a type that can be found either in the set of current Schemas that you compile or in a set of already compiled Schemas, we always resolve the reference internally. Also, if you want to declare a new type with a name equal to that of another type that was compiled previously, we let you do it, we have to.
Have you confirmed that the problem still occurs if all the Schemas are compiled simultaneously? If it still does, all I said earlier is just general info.
As to why you can use only the last SchemaConcrete in your other case, it must be some peculiarity which I can't detect from the set of information you provide in this e-mail. In any case, xsb files are never clobbered, though it is the case that a runtime QName lookup for a particular entity will find the first entity with that name and kind (element, type etc) available on the classpath, just as in Java, so there is an obscuring effect going on, which you would expect.
Hope this makes sense
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Tuesday, January 11, 2005 8:13 AM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Radu and folks,
This story is not over yet. The ClassCastException I am having with my real code comes from the order I am executing the SchemaCompiler on my schemas.
My fleet of schemas is organized such:
SchemaReferencesAbstractBase imports SchemaAbstractBase (which has the abstract type) in order to reference the abstract type (classic polymorphism - reference the base type).
3 concrete schemas, SchemaConcreteA,B,C provide concrete extensions the abstract type in SchemaAbstractBase, and they also import the SchemaAbstractBase in order
to force instance documents to always use the top level element of SchemaAbstractBase.
If I execute the SchemaCompiler on SchemaReferencesAbstractBase after compiling the SchemaConcretes I get the Cast exception.
Also, running the SchemaReferenceAbstractBase first, only the last SchemaConcrete allows casting. I believe xsb's are getting clobbered.
Does anyone have any suggestion on dependencies/abstract types, etc, for compiling the bindings - and specifically not clobbering xsb's ?
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
Scott Hinkelman/Austin/IBM@IBMUS
Scott Hinkelman/Austin/IBM@IBMUS
01/11/2005 08:54 AM
Please respond to
user
To
user@xmlbeans.apache.org
cc
Subject
RE: ClassCastException using changeType()
Thanks Radu.
Apparently in my larger code I have a build problem causing this to take place.
I put together a simple test case which does indeed behave correctly. - so it looks like my problem.
For example sake, here is my simple example of abstract complex-type to concrete type using changeType().
The objective is to build aninstance document using the top A element that includes a concrete xsi type of the abstract type in the A namespace, and utilized both the extension element in the concrete extension.
Feel free to use this in documentation, as I think there could be an example like this.
Abstract complex type schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://namespace.a" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:a="http://namespace.a">
<xs:element name="ATop" type="a:ATopType"/>
<xs:complexType name="ATopType">
<xs:sequence>
<xs:element name="A" type="a:AType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AType" abstract="true">
<xs:sequence>
<xs:element name="ADescription" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
Concrete extension schema of "AType". Seperate namespace.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://namespace.b" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:b="http://namespace.b" xmlns:a="http://namespace.a">
<xs:import namespace="http://namespace.a" schemaLocation="./a.xsd"/>
<xs:complexType name="BType">
<xs:complexContent>
<xs:extension base="a:AType">
<xs:sequence>
<xs:element name="BDescription" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Test driver:
package xmlbeanstest;
import a.namespace.*;
import b.namespace.*;
import org.apache.xmlbeans.*;
public class Test{
public static void main(String args[]) {
ATopDocument _d=ATopDocument.Factory.newInstance();
ATopType atop_type=_d.addNewATop();
AType a_type=atop_type.addNewA();
System.out.println("a_type before: "+a_type.schemaType());
//a_type=(AType)a_type.changeType(BType.type);
BType b_type=(BType)a_type.changeType(BType.type);
System.out.println("a_type after: "+a_type.schemaType());
b_type.setADescription("adescription");
b_type.setBDescription("bdescription");
System.out.println(_d.toString());
}
}
Output:
a_type before: T=AType@http://namespace.a
a_type after: T=AType@http://namespace.a
<ATop xmlns="http://namespace.a" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<A xsi:type="nam:BType" xmlns:nam="http://namespace.b">
<ADescription>adescription</ADescription>
<nam:BDescription>bdescription</nam:BDescription>
</A>
</ATop>
Again, I am still having trouble with my real code, but now convinced it should work.
thanks for your time and keep up the good work on this.
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com> "Radu Preotiuc-Pietro" <ra...@bea.com>
01/10/2005 07:03 PM
Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Hi Scott,
I have reviewed my post ([1]) and indeed I don't know why I used .schemaType() in there, it should have been .type, apologies (.type will return the static SchemaType associated to the class in question, while .schemaType() will return rhe runtime SchemaType of an object instance).
But beyond that, I just tried the example again, and it works for me. Can you share the code that you are using?
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Friday, January 07, 2005 11:23 AM
To: user@xmlbeans.apache.org
Subject: Re: ClassCastException using changeType()
Girish/all,
Again thanks. But I after fully qualifying everything with the names generated from the namespaces I still have the problem. I am very certain that I don't have dup .xsb's or .class in the classpath..........
I can get by the cast exception by changing the casted return type to the base abstract type (not surprising in of itself) - even while leaving the parameter type on changetype() as it is (type to the concrete).......instanceof then reveals the result to only be of the abstract type and not concrete.........
I can new up a concrete independently using it's factory with no problem.......but can't get changeType() to work on the abstract.....
The generated concrete interface does indeed extend the abstract interface.......
?
Scott
Girish Bhatia <bh...@gmail.com> Girish Bhatia <bh...@gmail.com>
01/07/2005 12:20 PM
Please respond to
user
To
user@xmlbeans.apache.org
cc
Subject
Re: ClassCastException using changeType()
I have the similar error of ClassCastException. In my case, my jar
included two class files for the same type in two different
namespaces. My issue was resolved, when I used the full package name
with the class. for example. com.girsh.schema.Order order.
- Girish
On Fri, 7 Jan 2005 13:06:22 -0500, Murphy, Eric
<er...@pfc.cfs.nrcan.gc.ca> wrote:
>
> Scott -
>
> I had this problem which was caused by the situation described in my earlier
> email titled ' Generated .jar files cause conflict' sent to the list on
> Jan.5. Essentially there were two objects of the same name and same
> namespace in two different jar files. I was asking for an object in one
> package but an object with the same name but different package was being
> returned.
>
> Eric
>
>
> ________________________________
> From: Scott Hinkelman [mailto:srh@us.ibm.com]
> Sent: Thursday, January 06, 2005 11:55 AM
> To: user@xmlbeans.apache.org
> Subject: ClassCastException using changeType()
>
>
>
>
> Hello XMLBeans experts.
> I essentially have the same situation discussed in the post [1] concerning
> polymorphism.
> However, I get a runtime ClassCastExecption during the operation containing
> changeType().
> Also, I have seen several uses of changeType() with parameters of
> <class>.type, <class>.type(),
> and as in the post <class>.schemaType(). The only one I can get to compile
> is <class>.type, which
> is where my exception occurs.
>
> I am using JDK 1.5 and a svn pull of Trunk on 1/6/05.
>
> If anyone can shed light on why I get that cast exception I would be very
> appreciative.
>
> [1]
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=user@xmlbeans.apache.org&msgId=1852352
>
> thanks,
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org
RE: ClassCastException using changeType()
Posted by Scott Hinkelman <sr...@us.ibm.com>.
Thanks Radu for doing this. I will pull it down. However, I am happy to
report that after pulling the latest cvs last week, my code with one
abstract type and multiple concrete type in different jars now *does* work
correctly.
thanks again,
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu
Preotiuc-Pietro"
<ra...@bea.com> To
<us...@xmlbeans.apache.org>
02/08/2005 07:44 cc
PM
Subject
RE: ClassCastException using
Please respond to changeType()
user
Ok, we now have a sample for using abstract types and multiple jars. Here
is the link:
http://xmlbeans.apache.org/samples/AbstractTypes.html
Radu
-----Original Message-----
From: Radu Preotiuc-Pietro
Sent: Thursday, January 20, 2005 4:25 PM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Ok, I will put together a sample on the wiki that tries to do what you are
suggesting.
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Thursday, January 20, 2005 9:44 AM
To: user@xmlbeans.apache.org
Cc: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
I could get around my problems * if * I can get multiple concrete type
extension from different schemas/namespaces to work during a changeType()
to either concrete, by building a tool that would re-build all of the
concrete data bindings, including the abstract, that could ever be needed
at runtime when a new plugin is developed. This would not be ideal and not
be very dynamic - but it would ok for now.
-----But is still seems I can not do this -
-How do I try running the schemacompiler across multiple schemas at the
same time (not meaning pulling in imports, but giving the schema compiler
essentially two starting concrete schemas that extend the same abstract
type in the common abstract schema). I think this is what you suggested
earlier, but I don't see how to do it.
I still have the situation where I can only changeType correctly to the
last concrete schema compiled. Without some fix on this, I can not use XML
Beans.....
hope someone can help.
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com>
"Radu Preotiuc-Pietro" <ra...@bea.com>
01/19/2005 01:49 PM Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Agreed, what you want to do makes sense and should be possible. Now to why
doesn't it work for you .... I think either you put together a
stripped-down repro so I can take a look at it, or I try to put together an
example that hopefully will work. It's either a bug that we need to fix or
some detail in what you're doing.
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Wednesday, January 19, 2005 9:34 AM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Radu,
>When you first compile SchemaConcreteA,B,C you automatically pull in
SchemaAbstractBase, because it is needed in order to resolve the base type
references. That >creates some SchemaTypes with an identity (set a)
>When you subsequently compile SchemaReferencesAbstractBase you
automatically pull SchemaAbstractBase in again, because it is needed. This
creates another set >of types, including the types in SchemaAbstractBase,
but with a different identity (set b). Now, unfortunately the
SchemaAbstractBase types in (a) are different than >SchemaAbstractBase
types in (b), therefore your SchemaConcreteA,B,C don't extend the latter.
yes that it what appears is happening.
>There are good reasons for this design decision. Basically, when you have
a reference to a type that can be found either in the set of current
Schemas that you compile >or in a set of already compiled Schemas, we
always resolve the reference internally. Also, if you want to declare a new
type with a name equal to that of another type >that was compiled
previously, we let you do it, we have to.
yes good logic, but. I have now rebuilt the abstract set into its own jar
file. -what I am trying to do is to allow somebody to later on use the
abstract schema and define a concrete type of it, use the already-built
abstract jar (and set A types I guess) and build a concrete jar. All of
this works at build time. at runtime, what I want to do is to dynamically
changeType() on an abstract instance to his new class (using a class loader
to load his schema-compiler generated concrete class type). this is what
does not work........Think what I am doing is building an an XML Framework
with a concrete plugins........
>Have you confirmed that the problem still occurs if all the Schemas are
compiled simultaneously? If it still does, all I said earlier is just
general info.
have not tried it.
>As to why you can use only the last SchemaConcrete in your other case, it
must be some peculiarity which I can't detect from the set of information
you provide in this >e-mail. In any case, xsb files are never clobbered,
though it is the case that a runtime QName lookup for a particular entity
will find the first entity with that name and kind >(element, type etc)
available on the classpath, just as in Java, so there is an obscuring
effect going on, which you would expect.
I think it comes down to the ability to changeType() in code using a
different identity set than the code being to changed to. this may not be
able to work under the current design of XMLBeans.............or is there
some other suggestion on how to do this?
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com>
"Radu Preotiuc-Pietro" <ra...@bea.com>
01/11/2005 07:22 PM
Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Hm, I think I know what's happening, I'll try to guess based on the
information that you provide:
When you first compile SchemaConcreteA,B,C you automatically pull in
SchemaAbstractBase, because it is needed in order to resolve the base type
references. That creates some SchemaTypes with an identity (set a)
When you subsequently compile SchemaReferencesAbstractBase you
automatically pull SchemaAbstractBase in again, because it is needed. This
creates another set of types, including the types in SchemaAbstractBase,
but with a different identity (set b). Now, unfortunately the
SchemaAbstractBase types in (a) are different than SchemaAbstractBase types
in (b), therefore your SchemaConcreteA,B,C don't extend the latter. There
are good reasons for this design decision. Basically, when you have a
reference to a type that can be found either in the set of current Schemas
that you compile or in a set of already compiled Schemas, we always resolve
the reference internally. Also, if you want to declare a new type with a
name equal to that of another type that was compiled previously, we let you
do it, we have to.
Have you confirmed that the problem still occurs if all the Schemas are
compiled simultaneously? If it still does, all I said earlier is just
general info.
As to why you can use only the last SchemaConcrete in your other case, it
must be some peculiarity which I can't detect from the set of information
you provide in this e-mail. In any case, xsb files are never clobbered,
though it is the case that a runtime QName lookup for a particular entity
will find the first entity with that name and kind (element, type etc)
available on the classpath, just as in Java, so there is an obscuring
effect going on, which you would expect.
Hope this makes sense
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Tuesday, January 11, 2005 8:13 AM
To: user@xmlbeans.apache.org
Subject: RE: ClassCastException using changeType()
Radu and folks,
This story is not over yet. The ClassCastException I am having with my real
code comes from the order I am executing the SchemaCompiler on my schemas.
My fleet of schemas is organized such:
SchemaReferencesAbstractBase imports SchemaAbstractBase (which has the
abstract type) in order to reference the abstract type (classic
polymorphism - reference the base type).
3 concrete schemas, SchemaConcreteA,B,C provide concrete extensions the
abstract type in SchemaAbstractBase, and they also import the
SchemaAbstractBase in order
to force instance documents to always use the top level element of
SchemaAbstractBase.
If I execute the SchemaCompiler on SchemaReferencesAbstractBase after
compiling the SchemaConcretes I get the Cast exception.
Also, running the SchemaReferenceAbstractBase first, only the last
SchemaConcrete allows casting. I believe xsb's are getting clobbered.
Does anyone have any suggestion on dependencies/abstract types, etc, for
compiling the bindings - and specifically not clobbering xsb's ?
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
Scott Hinkelman/Austin/IBM@IBMUS
Scott Hinkelman/Austin/IBM@IBMUS
01/11/2005 08:54 AM
Please respond to
user
To
user@xmlbeans.apache.org
cc
Subject
RE: ClassCastException using changeType()
Thanks Radu.
Apparently in my larger code I have a build problem causing this to take
place.
I put together a simple test case which does indeed behave correctly. - so
it looks like my problem.
For example sake, here is my simple example of abstract complex-type to
concrete type using changeType().
The objective is to build aninstance document using the top A element that
includes a concrete xsi type of the abstract type in the A namespace, and
utilized both the extension element in the concrete extension.
Feel free to use this in documentation, as I think there could be an
example like this.
Abstract complex type schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://namespace.a"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:a="
http://namespace.a">
<xs:element name="ATop" type="a:ATopType"/>
<xs:complexType name="ATopType">
<xs:sequence>
<xs:element name="A" type="a:AType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AType" abstract="true">
<xs:sequence>
<xs:element name="ADescription" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
Concrete extension schema of "AType". Seperate namespace.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://namespace.b"
elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:b="http://namespace.b"
xmlns:a="http://namespace.a">
<xs:import namespace="http://namespace.a" schemaLocation="./a.xsd"/>
<xs:complexType name="BType">
<xs:complexContent>
<xs:extension base="a:AType">
<xs:sequence>
<xs:element name="BDescription" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Test driver:
package xmlbeanstest;
import a.namespace.*;
import b.namespace.*;
import org.apache.xmlbeans.*;
public class Test{
public static void main(String args[]) {
ATopDocument _d=ATopDocument.Factory.newInstance();
ATopType atop_type=_d.addNewATop();
AType a_type=atop_type.addNewA();
System.out.println("a_type before: "+a_type.schemaType());
//a_type=(AType)a_type.changeType(BType.type);
BType b_type=(BType)a_type.changeType(BType.type);
System.out.println("a_type after: "+a_type.schemaType());
b_type.setADescription("adescription");
b_type.setBDescription("bdescription");
System.out.println(_d.toString());
}
}
Output:
a_type before: T=AType@http://namespace.a
a_type after: T=AType@http://namespace.a
<ATop xmlns="http://namespace.a" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
<A xsi:type="nam:BType" xmlns:nam="http://namespace.b">
<ADescription>adescription</ADescription>
<nam:BDescription>bdescription</nam:BDescription>
</A>
</ATop>
Again, I am still having trouble with my real code, but now convinced it
should work.
thanks for your time and keep up the good work on this.
Scott
------------
Scott R. Hinkelman, Senior Software Engineer
IBM Software Group / Emerging Technologies
Cross-Industry Foundation Standards Strategy
Office: 512.823.8097 (TL 793.8097)
Cell: 512.415.8490
"Radu Preotiuc-Pietro" <ra...@bea.com> "Radu Preotiuc-Pietro"
<ra...@bea.com>
01/10/2005 07:03 PM
Please respond to
user
To
<us...@xmlbeans.apache.org>
cc
Subject
RE: ClassCastException using changeType()
Hi Scott,
I have reviewed my post ([1]) and indeed I don't know why I used
.schemaType() in there, it should have been .type, apologies (.type will
return the static SchemaType associated to the class in question, while
.schemaType() will return rhe runtime SchemaType of an object instance).
But beyond that, I just tried the example again, and it works for me. Can
you share the code that you are using?
Radu
-----Original Message-----
From: Scott Hinkelman [mailto:srh@us.ibm.com]
Sent: Friday, January 07, 2005 11:23 AM
To: user@xmlbeans.apache.org
Subject: Re: ClassCastException using changeType()
Girish/all,
Again thanks. But I after fully qualifying everything with the names
generated from the namespaces I still have the problem. I am very certain
that I don't have dup .xsb's or .class in the classpath..........
I can get by the cast exception by changing the casted return type to the
base abstract type (not surprising in of itself) - even while leaving the
parameter type on changetype() as it is (type to the
concrete).......instanceof then reveals the result to only be of the
abstract type and not concrete.........
I can new up a concrete independently using it's factory with no
problem.......but can't get changeType() to work on the abstract.....
The generated concrete interface does indeed extend the abstract
interface.......
?
Scott
Girish Bhatia <bh...@gmail.com> Girish Bhatia
<bh...@gmail.com>
01/07/2005 12:20 PM
Please respond to
user
To
user@xmlbeans.apache.org
cc
Subject
Re: ClassCastException using changeType()
I have the similar error of ClassCastException. In my case, my jar
included two class files for the same type in two different
namespaces. My issue was resolved, when I used the full package name
with the class. for example. com.girsh.schema.Order order.
- Girish
On Fri, 7 Jan 2005 13:06:22 -0500, Murphy, Eric
<er...@pfc.cfs.nrcan.gc.ca> wrote:
>
> Scott -
>
> I had this problem which was caused by the situation described in my
earlier
> email titled ' Generated .jar files cause conflict' sent to the list on
> Jan.5. Essentially there were two objects of the same name and same
> namespace in two different jar files. I was asking for an object in one
> package but an object with the same name but different package was being
> returned.
>
> Eric
>
>
> ________________________________
> From: Scott Hinkelman [mailto:srh@us.ibm.com]
> Sent: Thursday, January 06, 2005 11:55 AM
> To: user@xmlbeans.apache.org
> Subject: ClassCastException using changeType()
>
>
>
>
> Hello XMLBeans experts.
> I essentially have the same situation discussed in the post [1]
concerning
> polymorphism.
> However, I get a runtime ClassCastExecption during the operation
containing
> changeType().
> Also, I have seen several uses of changeType() with parameters of
> <class>.type, <class>.type(),
> and as in the post <class>.schemaType(). The only one I can get to
compile
> is <class>.type, which
> is where my exception occurs.
>
> I am using JDK 1.5 and a svn pull of Trunk on 1/6/05.
>
> If anyone can shed light on why I get that cast exception I would be very
> appreciative.
>
> [1]
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=user@xmlbeans.apache.org&msgId=1852352
>
> thanks,
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org