[JAXB-420] XJC ignores external bindings if xsd contains annotation at schema level and includes another schema Created: 17/Sep/07  Updated: 23/Jul/15  Resolved: 21/Jan/09

Status: Resolved
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: schubertf Assignee: jaxb-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive external-customize.zip     GZip Archive sample.tar.gz    
Issuezilla Id: 420

 Description   

The XJC compiler ignores any global bindings if my XSD contains an xs:annotation
entry at schema level and also contains an xs:includes statement.

To reproduce...

File : included.xsd
--------------------

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="PurchaseOrderType">
<xs:sequence>
<xs:element name="shipTo" type="USAddress"/>
<xs:element name="billTo" type="USAddress"/>
<xs:element ref="comment" minOccurs="0"/>
<xs:element name="items" type="Items"/>
</xs:sequence>
<xs:attribute name="orderDate" type="xs:dateTime"/>
</xs:complexType>
</xs:schema>

File : po.xsd
----------------

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="included.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">This annotation entry causes JAXB to ignore
any global bindings in the external customisation file.</xs:documentation>
</xs:annotation>
<xs:element name="purchaseOrder" type="PurchaseOrderType"/>
<xs:element name="comment" type="xs:string"/>

<xs:complexType name="USAddress">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="street" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="state" type="USState"/>
<xs:element name="zip" type="ZipCodeType"/>
</xs:sequence>
<xs:attribute name="country" type="xs:NMTOKEN" fixed="US"/>
</xs:complexType>

<xs:complexType name="Items">
<xs:sequence>
<xs:element name="item" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="productName" type="xs:string"/>
<xs:element name="quantity" default="10">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:maxExclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="USPrice" type="xs:decimal"/>
<xs:element ref="comment" minOccurs="0"/>
<xs:element name="shipDate" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="partNum" type="SKU" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>

<!-- Stock Keeping Unit, a code for identifying products -->
<xs:simpleType name="SKU">
<xs:restriction base="xs:string">
<xs:pattern value="\d

{3}

-[A-Z]

{2}

"/>
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="USState">
<xs:restriction base="xs:string">
<xs:enumeration value="AK"/>
<xs:enumeration value="AL"/>
<xs:enumeration value="AR"/>
<xs:enumeration value="CA"/>
<xs:enumeration value="MA"/>
<!-- and so on ... -->
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="ZipCodeType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="10000"/>
<xs:maxInclusive value="99999"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

File 3: binding.xjb
----------------------
<jxb:bindings xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
jxb:version="2.0"
jxb:extensionBindingPrefixes="xjc">
<jxb:bindings>
<jxb:globalBindings>
<jxb:javaType name="org.joda.time.DateTime" xmlType="xs:dateTime"/>
</jxb:globalBindings>
</jxb:bindings>
</jxb:bindings>

With the <xs:annotation> element in po.xsd the orderDate instance variable in
the PurchaseOrderType class is generated as...

protected XMLGregorianCalendar orderDate;

Without the <xs:annotation> element it is generated as...

protected DateTime orderDate;

Note that this does not happen if you only have one schema and it does not
include any other schemas. It only happens when you have included schemas.



 Comments   
Comment by schubertf [ 17/Sep/07 ]

Created an attachment (id=205)
Zip containing files needed to reproduce

Comment by Pavel Bucek [ 21/Jan/09 ]

already fixed in 2.1.10

Comment by cristip32 [ 23/Jun/12 ]

The problem is still present in 2.1.10
It is difficult to reproduce because the behavior depends on the location of the schema and binding files.
For instance, when the input files are located in D:\1\2\ everything works fine, but when using path D:\1\2\3 it might fail.
For a given path the behavior is consistent, it will always work or it will always fail.

I found that com.sun.xml.internal.xsom.impl.SchemaImpl.setAnnotation() is called multiple times for the same SchemaImpl object. The XSAnnotation param for the first call contains the globalBindings and the next contains the schema-level documentation annotation, thus overwriting the global bindings.

Comment by Martin Grebac [ 25/Jun/12 ]

Hi, in case you can reproduce the failing case, would you please submit a reproducible testcase? Also, please verify with latest 2.2.x release.

Comment by Stillglade [ 13/Feb/13 ]

We also have been dealing with this issue for a long time. It is not just the path, but also the machine and JDK version. For example, I and another developer can have the exact same files in the same location using the same JDK version, but on one machine the binding file is picked up, and on the other it is ignored. Likewise, we have found that sometimes if you try a different JDK version, it will work or not work (there are some schemas where we have to run XJC with JDK 5 and others with JDK 6 to make it pick up the bindings file).

Comment by schubertf [ 21/Apr/15 ]

I raised this issue approx 8 years ago and have just encountered it again.
I had forgotten all about it and was searching the Internet looking for a reason why XJC would be completely ignoring an external bindings file, when I came upon this issue.
Please note that there is no point asking for a reproducible test case. This issue is not really reproducible. Our set up was working for 2 developers but not for the third. The setup on all 3 machines was identical, same version of JAXB and the JDK.
We removed any schema level <xs:annotation> elements and now the XSDs are compiled correctly on all 3 machines.

Comment by Iaroslav Savytskyi [ 21/Apr/15 ]

May be different OS? Ant/Maven version?

Comment by luismcv [ 23/Jul/15 ]

I was going crazy until I found this. I'm having the same issue.

I've been doing some tests and even just changing one single character of any of the directories in the path might change whether it ignores the bindings or not. For example, I try to build my project copying it under /tmp/build1 and it fails. If I rename the dir as build0 or build2, it works.

I'm using:
JAXB 2.2.7
Apache Maven 3.3.1
org.jvnet.jaxb2.maven2, maven-jaxb2-plugin, 0.8.3
Java version: 1.7.0_67, vendor: Oracle Corporation
OS name: "mac os x", version: "10.10.4", arch: "x86_64", family: "mac"

I made a script to test with "build" appended by different letters, but I can't see any obvious pattern:

A IGNORED
B IGNORED
C OK
D IGNORED
E IGNORED
F OK
G IGNORED
H OK
I OK
J IGNORED
K OK
L IGNORED
M OK
N OK
O OK
P IGNORED
Q IGNORED
R IGNORED
S IGNORED
T OK
U OK
V IGNORED
W OK
X IGNORED
Y OK
Z OK

a OK
b OK
c IGNORED
d IGNORED
e OK
f OK
g IGNORED
h OK
i IGNORED
j IGNORED
k OK
l IGNORED
m IGNORED
n OK
o OK
p OK
q OK
r OK
s OK
t OK
u OK
v OK
w OK
x OK
y OK
z OK

And then again by appending different letters to the actual subproject's directory (two levels below /tmp/build/)

A IGNORED
B IGNORED
C OK
D OK
E IGNORED
F OK
G OK
H IGNORED
I IGNORED
J OK
K OK
L IGNORED
M OK
N OK
O OK
P OK
Q IGNORED
R IGNORED
S IGNORED
T OK
U OK
V OK
W OK
X OK
Y OK
Z OK

a OK
b IGNORED
c IGNORED
d OK
e IGNORED
f IGNORED
g OK
h OK
i OK
j IGNORED
k OK
l IGNORED
m IGNORED
n OK
o IGNORED
p IGNORED
q OK
r OK
s IGNORED
t IGNORED
u IGNORED
v OK
w OK
x OK
y OK
z IGNORED





Generated at Tue Jul 28 09:29:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.