|
|
RE: ClassCastException using changeType(): msg#00115
text.xml.xmlbeans.user
|
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.
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
|
|
