jaxb
  1. jaxb
  2. JAXB-929

DOMForest.getOneDocument() should only return documents from "rootDocuments" Set and not from "core" Map

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • 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
    • Component/s: xjc
    • Labels:
      None
    • Environment:

      Ant Builder, Windows

      Description

      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())

      { . . . }

      to

      for (String k : rootDocuments)

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

        Activity

        Hide
        Iaroslav Savytskyi added a comment -

        Hi, Eugenio,

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

        Thank you.


        Iaroslav

        Show
        Iaroslav Savytskyi added a comment - Hi, Eugenio, Thanks for submission. Can you please provide some simple test to reproduce this issue? Thank you. – Iaroslav
        Hide
        Eugenio De Hoyos (IBM) added a comment -

        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:annotation/>

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

        </xsd:schema>

        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.

        Show
        Eugenio De Hoyos (IBM) added a comment - 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:annotation/> <xsd:complexType name="TestClass.Type"/> </xsd:schema> 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.

          People

          • Assignee:
            Iaroslav Savytskyi
            Reporter:
            Eugenio De Hoyos (IBM)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: