[JAXB-929] DOMForest.getOneDocument() should only return documents from "rootDocuments" Set and not from "core" Map Created: 16/Nov/12  Updated: 08/Sep/14

Status: In Progress
Project: jaxb
Component/s: xjc
Affects Version/s: not determined, JWSDP1.1 (JAXB1.0), JWSDP1.2 (JAXB1.0.1), JWSDP1.3 (JAXB1.0.2), JWSDP1.4 (JAXB1.0.3), JWSDP1.5 (JAXB1.0.4), JWSDP1.6 (JAXB1.0.5), 2.0 FCS, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12, 2.1.13, 2.1.14, 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.3u1, 2.2.3u2, 2.2.4, 2.2.4u1, 2.2.4u2, 2.2.5, 2.2.6, 2.2.7, 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eugenio De Hoyos (IBM) Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Ant Builder, Windows

Attachments: Zip Archive JAXB-929 - 4 test cases.zip    
Tags: JAXB, globalBindings, xjc


JAXB fails to generate correct schema 100% of the time because it sometimes fails to interpret the bindings file that we specify. Given an identical startup environment (including input files and build sequence), the output of our JAXB generated java-source code is not consistent from one run to the next.

We debugged the problem using the JAXB source code and we determined that getOneDocument() inside com.sun.tools.xjc.reader.internalizer.DOMForest sometimes returns a document that is not specified as a root document but that is instead referenced by a root document. Such indirectly specified document is an xsd:include in our root documents, and we deliberately decided not to specify a target namespace for it as part of our design. As a result of this document not having a target namespace, Internalizer.move() fails to correctly bind the globalBindings file to the schema forest by arbitrarily choosing a document from the forest. Whenever JAXB tries to look for the global bindings at a later point in time, the schema cannot be found in the forest.

Whenever getOneDocument() returns an object that can be found in the rootDocuments Set of DOMForest, the global bindings file is correctly attached, and JAXB generates java source code correctly as expected. Whenever getOneDocument() returns an object not in rootDocuments but that is part of the core Map of DOMForest, the bindings file is not correctly attached, and the java source code is not correctly generated. In the current code, the document selected is not predictable because getOneDocument() iterates over a HashSet, which does not specify iteration order by design, thus explaining why the generator is not consistent in its failures. That is, in some runs a root schema is chosen, and in other runs a non-root schema is chosen.

We suggest changing line 225 of DOMForest.java inside getOneDocument() from

for (Document dom : core.values())

{ . . . }


for (String k : rootDocuments)

{ Document dom = core.get(k); . . . }

Comment by Iaroslav Savytskyi [ 19/Nov/12 ]

Hi, Eugenio,

Thanks for submission. Can you please provide some simple test to reproduce this issue?

Thank you.


Comment by Eugenio De Hoyos (IBM) [ 19/Nov/12 ]

Hi Iaroslav,

I provided 4 simple tests that demonstrate when the issue occurs.

As I generated the simplified code for these tests I found some more details that I did not find before. The issue only occurs when there's an xsd:annotation element directly inside xsd:schema. Having an xsd:annotation element inside other nested elements does not trigger the problem.

For instance, the sample tests show that removing either the xsd:include or the xsd:annotation element from the following file results in the bindings file being correctly handled.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.1" targetNamespace="http://www.example.org/" xmlns="http://www.example.org/" >

<xsd:include schemaLocation="include1.xsd"/>


<xsd:complexType name="TestClass.Type"/>


Also, note that the information that I gave in the original description concerning target namespaces is not relevant. The problem occurs with include files regardless of the declared target namespace.

However, the fact that the problem occurs when getOneDocument() selects an include file rather than a "root" file is still true.

I hope this helps debug the issue.

Generated at Sun Dec 11 05:36:25 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.