Substitution Groups and Abstract Types

[Jamie Johnson <je...@gmail.com>]

I am attempting to build a set of schemas that uses substitution groups and
abstract types which works flawlessly if I compile all the schemas together
(i.e. one big jar) but if I build them all separately by first building the
abstract type then building all the types that extend the abstract type with
the abstracttype on the classpath XmlBeans substitution doesn't seem to
work.  Do all objects that extend the AbstractType need to be available at
build time for XmlBeans to properly recognize the substitution groups?

What is strange is when looking at a class that extends the AbstractType it
clearly indicates that the AbstractType is it's base, but if I try to do
(Extended)AbstractType.substitute(ExtendedDocument.impl.type,
Extended.type); I received a class cast exception.  Any idea how to address
this without having to recompile the Abstract Schema everytime I want to add
a type that extends the AbstractType?

Jamie

RE: Substitution Groups and Abstract Types

[Cezar Andrei <ce...@oracle.com>]

Jamie,

 

Indeed there is a problem in your scenario. The problem is because of the substitution group uses and not because of type derivation. 

 

You can have base types and in your first schema and derived types in the second one, and you can compile them separately. Everything should work as if the were compiled at once.

 

This is no longer valid with substitution groups, and this is because the substituted element has to know all it valid substitution at the moment of compilation, I know this is a drawback but solving this the right way would have a big impact on performance. The short answer is that if you modify a substitution you need to also include in the compilation the file of the substituted element.

 

 

Hope this helps,

Cezar

 

________________________________

From: Jamie Johnson [mailto:jej2003@gmail.com] 
Sent: Friday, October 03, 2008 3:03 PM
To: user@xmlbeans.apache.org
Subject: Re: Substitution Groups and Abstract Types

 

I believe the answer to this is yes for anyone else that is interested.

On Fri, Oct 3, 2008 at 8:56 AM, Jamie Johnson <je...@gmail.com> wrote:

I am attempting to build a set of schemas that uses substitution groups and abstract types which works flawlessly if I compile all the schemas together (i.e. one big jar) but if I build them all separately by first building the abstract type then building all the types that extend the abstract type with the abstracttype on the classpath XmlBeans substitution doesn't seem to work.  Do all objects that extend the AbstractType need to be available at build time for XmlBeans to properly recognize the substitution groups?

What is strange is when looking at a class that extends the AbstractType it clearly indicates that the AbstractType is it's base, but if I try to do (Extended)AbstractType.substitute(ExtendedDocument.impl.type, Extended.type); I received a class cast exception.  Any idea how to address this without having to recompile the Abstract Schema everytime I want to add a type that extends the AbstractType?

Jamie

 

Re: Substitution Groups and Abstract Types

[Jamie Johnson <je...@gmail.com>]

I believe the answer to this is yes for anyone else that is interested.

On Fri, Oct 3, 2008 at 8:56 AM, Jamie Johnson <je...@gmail.com> wrote:

> I am attempting to build a set of schemas that uses substitution groups and
> abstract types which works flawlessly if I compile all the schemas together
> (i.e. one big jar) but if I build them all separately by first building the
> abstract type then building all the types that extend the abstract type with
> the abstracttype on the classpath XmlBeans substitution doesn't seem to
> work.  Do all objects that extend the AbstractType need to be available at
> build time for XmlBeans to properly recognize the substitution groups?
>
> What is strange is when looking at a class that extends the AbstractType it
> clearly indicates that the AbstractType is it's base, but if I try to do
> (Extended)AbstractType.substitute(ExtendedDocument.impl.type,
> Extended.type); I received a class cast exception.  Any idea how to address
> this without having to recompile the Abstract Schema everytime I want to add
> a type that extends the AbstractType?
>
> Jamie
>
>