|
|
RE: ClassCastException using changeType(): msg#00127
text.xml.xmlbeans.user
|
Subject: |
RE: ClassCastException using changeType() |
Ok, I
will put together a sample on the wiki that tries to do what you are
suggesting.
Radu
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"
<radup@xxxxxxx>
"Radu Preotiuc-Pietro"
<radup@xxxxxxx>
01/19/2005 01:49 PM
|
|
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@xxxxxxxxxx]
Sent: Wednesday, January 19,
2005 9:34 AM
To: user@xxxxxxxxxxxxxxxxxxx
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" <radup@xxxxxxx>
"Radu Preotiuc-Pietro"
<radup@xxxxxxx>
01/11/2005 07:22 PM
|
|
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@xxxxxxxxxx]
Sent: Tuesday,
January 11, 2005 8:13 AM
To:
user@xxxxxxxxxxxxxxxxxxx
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
|
|
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
|
|
