RE: Generated .jar files cause conflict

Eric,
this is also a question of what it is that you want to use to determine what is 
the version of your document, in order to map the correct Schema. As Kevin 
explains, XmlBeans can't use anything but the QName internally.
1) is probably not acceptable to you.
Here's my suggestion:
Build a list of SchemaTypeLoaders (using different classloaders or using the 
SchemaTypeLoader APIs) ordered by your preference of Schema versions. Load the 
document into memory and then validate it against each of the Schemas in the 
list until it validates correctly. I don't know how efficient this would be, 
but you see the idea.

Radu

-----Original Message-----
From: Kevin Krouse 
Sent: Thursday, January 06, 2005 12:06 PM
To: user@xxxxxxxxxxxxxxxxxxx
Subject: RE: Generated .jar files cause conflict


Yes, this is a known "problem" with how xmlbeans looks up schema information.  
When xmlbeans builds the jar, all the schema information for elements goes into 
the 'schema/elements' directory, the attribute information goes into 
'schema/attributes', etc.  Under those directories, the meta information filed 
using the QName, for example 'schema/element/someNamespace/myElement.xsb'.  In 
your case you have two jars compiled from schemas with the same target 
namespace and have elements of the same name.  The result is the element .xsb 
files in the second jar on the classpath is being masked by the .xsb files from 
the first jar on the classpath.

The reason XmlBeans needs to use this lookup technique is clear when you think 
about an instance that has an xsi:type attribute to change the element type, 
eg. <myElement xsi:type="ns2:otherType" xmlns:ns2="otherNamespace"/>.  You must 
be able to lookup everything in the schema type system by QName to find what 
"otherType" is.

There are only two solutions that I can see to your current situation: 1) is to 
use a different namespace for each schema which, 2) is to put the conflicting 
jars into two different classloaders.

Hope that helps!

--k

-----Original Message-----
From: Murphy, Eric [mailto:erimurph@xxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, January 05, 2005 1:25 PM
To: 'user@xxxxxxxxxxxxxxxxxxx'
Subject: Generated .jar files cause conflict

XmlBeans -

We are implementing different versions of a specification which are based on
very similar schemas. Many of the tags in these schemas have the same names.
The specification authors have not used any namespaces.

We would like to use one servlet to evaluate the request then pass it to the
API that handles that version. We have compiled the XmlBeans classes into
different packages using a xsdconfig file and deploy the classes in separate
jars.  

gdas090.jar and gdas091.jar are both in the class path.

Unfortunately when marshalling the main XML document we don't always get the
correct version returned from the Factory class. Example:

Org.nfis.gdas.v091.GdasCapabilitiesDocument doc =
GDASCapabilitiesDocument.Factory.parse(in);

The above line can throw a ClassCastException from the generated code from
at this line:

public static org.nfis.gdas.v091.GDASCapabilitiesDocument
parse(java.io.InputStream is) 
        throws org.apache.xmlbeans.XmlException, java.io.IOException {
 return (org.nfis.gdas.v091.GDASCapabilitiesDocument)
org.apache.xmlbeans.XmlBeans.getContextTypeLoader().parse( is, type, null );
}

Debugging I discovered the returned class was actually
org.nfis.gdas.v090.GDASCapabilitiesDocument (the incorrect version) which
resulted in the ClassCastException.

While we can put these versions in separate web containers to resolve this
problem we would rather not do this.  Any thoughts about why this is
occurring?

Eric Murphy
Software Developer (NFIS)

erimurph@xxxxxxxxxxxxxxx
tel/tél: 250-363-6038
fax / télécopieur 250-363-6004

Natural Resources Canada
Pacific Forestry Centre
506 West Burnside Road
Victoria BC V8Z 1M5

Ressources naturelles Canada
Centre de foresterie du Pacifique
506 rue Burnside ouest
Victoria, Colombie-Britanique V8Z 1M5

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx