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:[EMAIL PROTECTED] Sent: Friday, October 03, 2008 3:03 PM To: [email protected] 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 <[EMAIL PROTECTED]> 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
