|
|
RE: ClassCastException using changeType(): msg#00086
text.xml.xmlbeans.user
|
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
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
|
|
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"
<radup@xxxxxxx>
"Radu Preotiuc-Pietro" <radup@xxxxxxx>
01/10/2005 07:03 PM
|
|
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@xxxxxxxxxx]
Sent: Friday, January
07, 2005 11:23 AM
To:
user@xxxxxxxxxxxxxxxxxxx
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
<bhatiagirish@xxxxxxxxx>
Girish Bhatia
<bhatiagirish@xxxxxxxxx>
01/07/2005 12:20 PM
|
|
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
<erimurph@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxx]
> Sent: Thursday, January 06, 2005 11:55 AM
> To:
user@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx&msgId=1852352
>
> thanks,
>
Scott
>
---------------------------------------------------------------------
To
unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
For
additional commands, e-mail:
user-help@xxxxxxxxxxxxxxxxxxx
|
|
