[JAXB-1126] Option for unicode handling Created: 25/Mar/17  Updated: 25/Mar/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Muselgrusel Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7/10 x64



 Description   

Some non-ascii characters are converted into an unicode code points notation(for example µ into \u00b5) when generating JAXB classes with xjb in certain circumstances.

xjc -encoding UTF-8 test.xsd

test.xsd
[...]
<xs:simpleType name="MyType">
	<xs:restriction base="xs:string">
		<xs:enumeration value="µ-Type"/>
	</xs:restriction>
</xs:simpleType>
[...]
MyType.java
[...]
 * &lt;simpleType name="MyType">
 *   &lt;restriction base="{http://www.w3.org/2001/XMLSchema}string">
 *     &lt;enumeration value="µ-Type"/>
 *   &lt;/restriction>
 * &lt;/simpleType>
 * </pre>
 * 
 */
@XmlType(name = "MyType")
@XmlEnum
public enum MyType {

    @XmlEnumValue("\u00b5-Type")
    \u039c_TYPE("\u00b5-Type");
    private final String value;
[...]

This does not seem to break any java or JAXB functionality but can trigger problems with third party tools like checkstyle. The following part in the comments shows that it is possible to write symbols like µ uncoverted into *.java files.

 *     &lt;enumeration value="µ-Type"/>

If the described behaviour is the way xjc is supposed to work, it would be great to have an option changing this behaviour (xjc handling the µ character in java code like it does in the comments).






[JAXB-1125] XJC -Xlocator create class with internal imports Created: 22/Mar/17  Updated: 22/Mar/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dufgui Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I generate with XJC 2.2.8-b130911.1802.
Here is my args :
-b binding.xjb -extension -Xlocator -nv -d ../src/ -p mypackage index.xsd

And my generated class have the following imports:
import com.sun.xml.internal.bind.Locatable;
import com.sun.xml.internal.bind.annotation.XmlLocation;

So it's internal import, so I cannot compile this with maven tycho for example. And It's not a good idea to generate internal dependency.

Did this imported classes must be moved in public api in java itself ?
Or is there any existing public API to do this? And in this case, xjc must use it.

It seems to be already seen on SOF : http://stackoverflow.com/questions/2905930/jaxb-locator-missing-dependency

Thanks for your help



 Comments   
Comment by dufgui [ 22/Mar/17 ]

Hope this package is still accessible after Jigsaw...





[JAXB-1124] CLONE - wrong BIGlobalBinding#equals implementation Created: 16/Mar/17  Updated: 16/Mar/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2
Fix Version/s: 2.1.13

Type: Bug Priority: Major
Reporter: Mark Struberg Assignee: Martin Grebac
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Cloners
clones JAXB-687 random failure on globalBindings cust... Resolved
Issuezilla Id: 687

 Description   

When a (anonymous) schema document is (syntactically) included in more than one
other schema document, global bindings specified in a seperate binding document
can cause a failure:

>> only one globalBindings customization is allowed in a whole compilation
>> (related to above) but one is already given at this location

Moving the same set of schema files to another location can change the
behaviour.



 Comments   
Comment by Mark Struberg [ 16/Mar/17 ]

The very same bug with the error in the equals operation of BIGlobalBinding also happens in JAXB-2.2.
This is mandatory for JavaEE6 & 7 implementations and the fix should get applied here as well - txs!.





[JAXB-1123] JAXB don't encodes the url while marshalling but encodes the url while unmarshalling Created: 24/Feb/17  Updated: 24/Feb/17

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: shiva10162 Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While I am trying to marshall Java to xml .. JAXB don't encode the file path. Ex. if file path is /Users/Test/Development%20-%20SimplyFi xml file which is created is /Users/Test/Development%20-%20SimplyFi.xml.

Code:

public void marshal(Object jaxbElement, File output) throws JAXBException {
checkNotNull(jaxbElement, "jaxbElement", output, "output" );
try {
OutputStream os = new BufferedOutputStream(new FileOutputStream(output));
try

{ marshal( jaxbElement, new StreamResult(os) ); }

finally

{ os.close(); }

} catch (IOException e)

{ throw new JAXBException(e); }

}

But when I am trying to read the same xml , unmarshall it .. now the it passes the File to the Url constructor and decode the file path to /Users/Test/Development - SimplyFi.xml (All %20 has been replaced by spaces). So when I am trying to read the file with the name /Users/Test/Development%20-%20SimplyFi.xml I am getting FileNotFoundException.

Code:

public final Object unmarshal( File f ) throws JAXBException {
if( f == null )

{ throw new IllegalArgumentException( Messages.format( Messages.MUST_NOT_BE_NULL, "file" ) ); }

try

{ // copied from JAXP String path = f.getAbsolutePath(); if (File.separatorChar != '/') path = path.replace(File.separatorChar, '/'); if (!path.startsWith("/")) path = "/" + path; if (!path.endsWith("/") && f.isDirectory()) path = path + "/"; return unmarshal(new URL("file", "", path)); }

catch( MalformedURLException e )

{ throw new IllegalArgumentException(e.getMessage()); }

}






[JAXB-1122] JAXB API change list umbrella Created: 23/Feb/17  Updated: 23/Feb/17

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.3.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: roman.grigoriadi Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Bugfixes:
https://bugs.openjdk.java.net/browse/JDK-8072839
https://bugs.openjdk.java.net/browse/JDK-8157311
https://bugs.openjdk.java.net/browse/JDK-8150173
https://bugs.openjdk.java.net/browse/JDK-8175552

Javadoc issues:
https://bugs.openjdk.java.net/browse/JDK-8077332
https://bugs.openjdk.java.net/browse/JDK-8133651
https://bugs.openjdk.java.net/browse/JDK-8145545
https://bugs.openjdk.java.net/browse/JDK-8163266
https://bugs.openjdk.java.net/browse/JDK-8146061






[JAXB-1121] File path of wsdl/xsd files affecting output Created: 10/Feb/17  Updated: 10/Feb/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: westmc Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

We found when using CXF wsdl2java that the file path of the wsdl affected whether our custom bindings were applied.

For example, running "wsdl2java c:\foo\bar\blah.wsdl -b c:\foo\bar\bindings.xjb" and "wsdl2java c:\foo\blah.wsdl -b c:\foo\bindings.xjb" could result in the bindings.xjb being applied in one case and not the other. We found that the -b parameter did not affect it, only the location of the wsdl.

After a lot of searching, I think I tracked it down to a defect in jaxb-xjc. Specifically, DOMForest.java:102. I haven't had time to figure out the exact reason of the issue, but changing core from a HashMap to a LinkedHashMap fixes it. I noticed that there are 2 cases in that file of iterating through the Map and returning the 1st value that it finds. Since order becomes relevant, it should be changed to a LinkedHashMap.






[JAXB-1120] Order of generated code comments and annotations Created: 03/Feb/17  Updated: 03/Feb/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: nikdunn Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have a project that has very strict requirements for monitoring changes to compiled code. This project also makes use of xjc at compile time to generate java classes from schema files.

There are a few places in the code generation part of xjc that use HashMaps or HashSets to store the data structures that are later iterated over to generate the source code. This causes the java code to be generated differently from one run to the next which causes the compiled code to be different.



 Comments   
Comment by Pavel Bucek [ 03/Feb/17 ]

Ah, this one has been here for ages..

See https://java.net/jira/browse/JAXB-35 (just an example).

I know this was already fixed multiple times. Maybe there are some areas where it wasn't done properly. Please provide reproducible testcase to help narrow down the exact spot.

Thanks and regards,
Pavel





[JAXB-1119] JAnnotationUse.getAnnotationMembers throws if annotation has no members Created: 27/Jan/17  Updated: 27/Jan/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dschulten Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This implementation of JAnnotationUse.getAnnotationMembers() in codemodel 2.2.11:

    public Map<String, JAnnotationValue> getAnnotationMembers() {
        return Collections.unmodifiableMap(memberValues);
    }

Throws NullpointerException if the annotation has no values, like @XmlD. The memberValues are only initialized lazily if at least one annotation param has been added, otherwise they are null. Collections.unmodifiableMap throws NPE if null is passed to it.






[JAXB-1118] xjc-generated class for simple type gives javadoc warning about empty <p> tag Created: 24/Jan/17  Updated: 24/Jan/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: richardwalker Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8



 Description   

The xjc-generated code for a simple type includes a Javadoc header that begins:

/**
 * <p>Java class for <type name goes here>.
 *
 * <p>The following schema fragment specifies the expected content contained within this class.
 * <p>
 * <pre>

With JDK 8, running javadoc on the code gives this error for the <p> tag that precedes the <pre>:

warning: empty <p> tag

The code that generates the header is in xjc/src/main/java/com/sun/tools/xjc/reader/xmlschema/SimpleTypeBuilder.java, the method bindToTypeSafeEnum():

            javadoc += Messages.format( Messages.JAVADOC_HEADING, type.getName() )
                +"\n<p>\n<pre>\n"+out.getBuffer()+"</pre>";





[JAXB-1117] xjc-generated classes may have methods with missing @param or @return Created: 24/Jan/17  Updated: 24/Jan/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: richardwalker Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Further to commit 0fd1c105c992f77da451e6eb4143617cf85b5fc3 that has this commit comment:

8158221: Added missing javadoc for method parameter and returned value.

(See https://bugs.openjdk.java.net/browse/JDK-8158221 for the report)

This commit doesn't go far enough; it applies only to the generated ObjectFactory.java.

Classes generated by xjc for the users's schema may have getter methods with Javadoc that omits @return, and setter methods with Javadoc that omits @param.

For example, here is the generated code for the getter and setter for a field of type int:

    /**
     * Gets the value of the id property.
     *
     */
    public int getId() {
        return id;
    }

    /**
     * Sets the value of the id property.
     *
     */
    public void setId(int value) {
        this.id = value;
    }

Similarly, a generated getter for a value of List<T> type has Javadoc that omits @return.

Its seems that within xjc/src/main/java/com/sun/tools/xjc/generator/bean/field, some of the classes invoke .javadoc().addReturn() and .javadoc().addParam(), and some don't ...






[JAXB-1116] xjc:javaType doesn't properly override global binding Created: 13/Jan/17  Updated: 13/Jan/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Diego Nieto Cid Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

> xjc -version
xjc 2.2.8-b130911.1802
> java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)

Windows 10



 Description   

When there is a global binding that uses an xjc:javaType tag to assign a default Java type and adapter, property specific bindings that also provide an xjc:javaType configuration will not override the global binding unless the adapter changes.

This happens even if the Java type did actually change.

I set this as minor because there is a workaround:

  • Use a dummy class in the global binding that inherits from the default adapter you want.
  • When you need to override the type also set the adapter to the real class

This would introduce an adapter change and the right type will be used in the generated code.


Just in case I've used the binding language incorrectly, I cite below the main parts of the schema feed to xjc compiler. The full schema will be attached.

The global binding:

<schema ...>
  <annotation xmlns="http://www.w3.org/2001/XMLSchema">
    <appinfo>
      <jaxb:globalBindings>
        <xjc:javaType
            adapter="my.TwoDecimalsDoubleAdapter"
            name="java.lang.Double"
            xmlType="xs:double"/>
      </jaxb:globalBindings>
    </appinfo>
  </annotation>

The element that should be of primitive type but isn't.

  <!-- this field SHOULD be mapped as a primitive double property
     but it isn't. -->
  <xs:element name="plain_required_field" type="xs:double">
    <annotation xmlns="http://www.w3.org/2001/XMLSchema">
      <appinfo>
        <xjc:javaType
          adapter="my.TwoDecimalsDoubleAdapter"
          name="double"/>
      </appinfo>
    </annotation>
  </xs:element>

And this is the element that does get its type adjusted. But apparently it requires an adapter change.

  <!-- this field IS mapped as a primitive double property,
     apparently, because the adapter changed compared to
     the global binding. -->
  <xs:element name="high_precision_plain_required_field" type="xs:double">
    <annotation xmlns="http://www.w3.org/2001/XMLSchema">
      <appinfo>
        <xjc:javaType
          adapter="my.FourDecimalsDoubleAdapter"
          name="double"/>
      </appinfo>
    </annotation>
  </xs:element>


 Comments   
Comment by Diego Nieto Cid [ 13/Jan/17 ]

Sorry, I cannot attach files. Here's a dump of the schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    attributeFormDefault="unqualified"
    elementFormDefault="qualified"
    jaxb:extensionBindingPrefixes="xjc"
    jaxb:version="2.0"
    targetNamespace="http://test.schemas.my/">
  <annotation xmlns="http://www.w3.org/2001/XMLSchema">
    <appinfo>
      <jaxb:globalBindings>
        <xjc:javaType
          adapter="my.TwoDecimalsDoubleAdapter"
          name="java.lang.Double"
          xmlType="xs:double"/>
      </jaxb:globalBindings>
    </appinfo>
  </annotation>
  <xs:element name="echo_message">
    <xs:complexType>
      <xs:sequence>
        <!-- this field SHOULD be mapped as a primitive double property
             but it isn't. -->
        <xs:element name="plain_required_field" type="xs:double">
          <annotation xmlns="http://www.w3.org/2001/XMLSchema">
            <appinfo>
              <xjc:javaType
                adapter="my.TwoDecimalsDoubleAdapter"
                name="double"/>
            </appinfo>
          </annotation>
        </xs:element>
        <!-- this field IS mapped as a primitive double property,
             apparently, because the adapter changed compared to
           the global binding. -->
        <xs:element name="high_precision_plain_required_field" type="xs:double">
          <annotation xmlns="http://www.w3.org/2001/XMLSchema">
            <appinfo>
              <xjc:javaType
                adapter="my.FourDecimalsDoubleAdapter"
                name="double"/>
            </appinfo>
          </annotation>
        </xs:element>
        <!-- this field is mapped according to the global binding:
             its type is java.lang.Double and its adapter is also
           correctly set. -->
        <xs:element minOccurs="0" name="optional_restricted_field">
          <xs:simpleType>
            <xs:restriction base="xs:double">
              <xs:maxInclusive value="9999999999.99999"/>
              <xs:minInclusive value="0"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Also, the command-line I'm using to invoke the compiler is:

> mkdir output-dir
> xjc -d output-dir -extension -verbose schema.xml




[JAXB-1115] Support for catalog in binding files Created: 07/Jan/17  Updated: 07/Jan/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: mat013 Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am unsure if this is the right place to raise this item and whether it is a feature request or a bug.

I have a project, which uses a third party XML schemas and in that connection I am trying to generate some JAXB classes.

In addition to the XML schemas there is a binding file used together with it, which refers to the XML schemas using the schemaLocation attribute and it is using relative path e.g. ../../../../main/src/resources...

The organization of the third party project seems a bit non intuitively, and I decided to reorganize the location of the xsd and the binding file to be closer however when I try to generate the JAXB classes. I get an error
that the xsd file is not part of the compilation.

I thought by introducing a catalog file this should be fixed. However it didn't.

I have debugged the xjc generator and tracked down the error to the method
com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap

in the following code snippet.

try {
// TODO: use the URI class
// TODO: honor xml:base
URL loc = new URL(
new URL(forest.getSystemId(bindings.getOwnerDocument())), schemaLocation
);
schemaLocation = loc.toExternalForm();
target = forest.get(schemaLocation);
if ((target == null) && (loc.getProtocol().startsWith("file")))

{ File f = new File(loc.getFile()); schemaLocation = new File(f.getCanonicalPath()).toURI().toString(); }

} catch( MalformedURLException e ) {
} catch( IOException e )

{ Logger.getLogger(Internalizer.class.getName()).log(Level.FINEST, e.getLocalizedMessage()); }

target = forest.get(schemaLocation);
if(target==null)

{ reportError( bindings, Messages.format(Messages.ERR_INCORRECT_SCHEMA_REFERENCE, schemaLocation, EditDistance.findNearest(schemaLocation,forest.listSystemIDs()))); return; // abort processing this <jaxb:bindings> }

For me it seems like the catalog is not supported in the current implementation.

There are several workarounds for this issue, however the todo comment about to support xml:base seems to suggest that there should have been support for xml catalog.

I can't seem to find any reports on this issue so I am raising it. In case it is a feature that should have been in. I would be happy to try to contribute

My suggestion would be to use the entity resolver available an use that to resolve it.

As I wrote initially if this is not the right to place the feature request or bug, please point me to the right place. Thanks in advance






[JAXB-1114]  JAXB xjc CClassInfo constructor with fullname constructs wrong package Created: 21/Dec/16  Updated: 21/Dec/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dschulten Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CClassInfo has the below constructor which takes a JCodeModel and a fullName. The fullName parameter should be the FQCN of the class. However, if the fullName starts with a package having more than one name segment (like "com.example" which has two segments), the following code fails, because it puts the resulting CClassInfo into the package that is the first segment.
Assuming a fullName "com.example.MyClass", the code below will find that the indexOf '.' is 3, and from there everything goes wrong.
The constructor sets this.parent to the package "com" and it will use fullName.substring(idx+1) to determine the shortName, i.e. he shortName ends up being "example.MyClass".

{code title=com.sun.tools.xjc.model.CClassInfo|borderStyle=solid}

public CClassInfo(Model model,JCodeModel cm, String fullName, Locator location, QName typeName, QName elementName, XSComponent source, CCustomizations customizations) {
super(model,source,location,customizations);
this.model = model;
int idx = fullName.indexOf('.'); <-- must be lastIndexOf('.')
if(idx<0)

{ this.parent = model.getPackage(cm.rootPackage()); this.shortName = model.allocator.assignClassName(parent,fullName); }

else

{ this.parent = model.getPackage(cm._package(fullName.substring(0,idx))); this.shortName = model.allocator.assignClassName(parent,fullName.substring(idx+1)); }

this.typeName = typeName;
this.elementName = elementName;

model.add(this);
}


The line
int idx = fullName.indexOf('.');
should be
int idx = fullName.lastIndexOf('.');



 Comments   
Comment by dschulten [ 21/Dec/16 ]

Corrected code block:

com.sun.tools.xjc.model.CClassInfo

public CClassInfo(Model model,JCodeModel cm, String fullName, Locator location, QName typeName, QName elementName, XSComponent source, CCustomizations customizations) {
        super(model,source,location,customizations);
        this.model = model;
        int idx = fullName.indexOf('.');  <-- must be lastIndexOf('.')
        if(idx<0) {
            this.parent = model.getPackage(cm.rootPackage());
            this.shortName = model.allocator.assignClassName(parent,fullName);
        } else {
            this.parent = model.getPackage(cm._package(fullName.substring(0,idx)));
            this.shortName = model.allocator.assignClassName(parent,fullName.substring(idx+1));
        }
        this.typeName = typeName;
        this.elementName = elementName;

        model.add(this);
    }





[JAXB-1113] class com.sun.xml.bind.v2.runtime.output.Encoded severly limits use of large strings Created: 14/Dec/16  Updated: 14/Dec/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: demonti Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I ran into a problem transferring large strings (~480 MB) via SOAP. I got an ArrayIndexOutOfBounds exception in the "Encoded" class. Further investigation revealed that the "setEscape" method tries to allocate a byte array that is six times the length of the string. Due to a numeric overflow, the size results in a negative value for a string length of about 480 MB and the code believes that a previously allocated (much smaller) buffer would be sufficient, which, of course, isn't. This results later in the AIOOB exception.

While some problems near the 2G limit would be expectable, I believe that strings far beyond that limit need to be processed correctly.






[JAXB-1112] Inheritence on simple content does not work Created: 12/Dec/16  Updated: 12/Dec/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: robbyb Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following XSD-construct:

<xsd:complexType name="AbstractSimpleType" abstract="true">
<xsd:simpleContent>
<xsd:extension base="xsd:string" />
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="SimpleTypeRestricted">
<xsd:simpleContent>
<xsd:restriction base="AbstractSimpleType">
<xsd:enumeration value="Classic"/>
<xsd:enumeration value="Premium"/>
<xsd:enumeration value="Basis"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

used in XML like

<p:ProductAttribute xsi:type="p:SimpleTypeRestricted">Premium</p:ProductAttribute>

leads to an InstantiationException because the Unmarshaller ignores the xsi:type attribute and tries to instantiate the abstract base class.

This Problem does not occur when using complexContext in XSD. But I have to use xml schema that I must not change - so this would be a showstopper.

The seems somewhat related (but no duplicate of) to JAXB-619.



 Comments   
Comment by robbyb [ 12/Dec/16 ]

I could provide a simple project which illustrates the problem but I dont see any upload or attachment possibility here.





[JAXB-1111] Marshaller.marshall throws NPE if an adapter adapts a non-null bound value to null as XmlGregorianCalendar Created: 05/Dec/16  Updated: 05/Dec/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: daniel_s Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System:All



 Description   

This is a follow-up to JAXB-415. It's basically the same example, but with XmlGregorianCalendar instead of String as value type. With a similar result: a NullPointerException.

Bar.java
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Bar
{
  @XmlElement
  @XmlJavaTypeAdapter(TestAdapter.class)
  private LocalDate v;
  public Bar(final LocalDate v)  {this.v = v;}
  public Bar()  { }
}
TestAdapter.java
public class TestAdapter extends XmlAdapter<XMLGregorianCalendar, LocalDate>
{
  @Override
  public LocalDate unmarshal(final XMLGregorianCalendar v) throws Exception
  {    return null;  }
  @Override
  public XMLGregorianCalendar marshal(final LocalDate v) throws Exception
  {    return null;  }
}
Test.java
public class Test
{
  public static void main(final String[] args)
    throws JAXBException, DatatypeConfigurationException
  {
    Marshaller m = JAXBContext.newInstance(Bar.class).createMarshaller();
    m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
    m.marshal(new Bar(LocalDate.now()), System.out);
  }
}

This results in the following exception:

StackTrace

Exception in thread "main" java.lang.NullPointerException
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$12.print(RuntimeBuiltinLeafInfoImpl.java:587)
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$12.print(RuntimeBuiltinLeafInfoImpl.java:568)
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$StringImpl.writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:172)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:254)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:130)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
at ds.jaxb.Test.main(Test.java:29)






[JAXB-1110] Schemagen doesn't reference classes in generated episode file Created: 25/Oct/16  Updated: 19/Nov/16

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.5, 2.2.6, 2.2.7, 2.2.8 (JDK 8), 2.2.9, 2.2.10, 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: snakebyte Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If i launch schemagen to generate a schema and episode file from java classes, the schema files are generated without any problem but the episode file is empty as shown below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns1:bindings version="2.1" xmlns:ns1="http://java.sun.com/xml/ns/jaxb"/>

I tried different version of jaxb-ri, and i discovered that this problem affect all versions above 2.2.4. With 2.2.4 and below the episode file is generated with all reference to the selected java classes.

I tried first with a real domain application (about thirty java classes) and next with two example base java bean classes. With 2.2.4+ versions i tried every combination of JAXB annotation: all schema files are generated correctly, the episode file is empty every time.

This guy on stackoverflow had the same problem but received no answer:

http://stackoverflow.com/questions/36714142/jaxb-schemagen-doesnt-reference-classes-in-episode-file



 Comments   
Comment by snakebyte [ 19/Nov/16 ]

I made a preliminary fix and made a pull request here:

https://github.com/gf-metro/jaxb/pull/31

The problem was due to the nature of the Annotation Processor in java:

http://hannesdorfmann.com/annotation-processing/annotationprocessing101

As explained in "Processing Rounds" paragraph, the process method of com.sun.tools.jxc.ap.SchemaGenerator is called twice:

  • the first time it parse all the annotations and generates the schema files and the singole episode file if requested
  • the second time there is no input at all, it doesn't generate any schema file but it overwrites anyway the previous generated episode file with an empty one, as shown in the description of this jira issue.

The simple fix consists of skipping the second round





[JAXB-1109] BufferedReader is not closed properly Created: 24/Oct/16  Updated: 24/Oct/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kal0ian Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In ContextFinder class at line 345 there is BufferedReader that is not closed properly. It is closed on line 347 but if r.readLine() on line 346 throw an Exception then the Reader will remain open.






[JAXB-1108] NullPointerException in AbstractField.annotateReference():188 Created: 21/Oct/16  Updated: 24/Oct/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The given XSD

<?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"
	xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
	jaxb:version="2.1"
	jaxb:extensionBindingPrefixes="xjc"
	elementFormDefault="qualified">

	<xsd:annotation>
		<xsd:appinfo>
			<jaxb:globalBindings>
				<xjc:simple />
			</jaxb:globalBindings>
		</xsd:appinfo>
	</xsd:annotation>

	<xsd:complexType name="item">
		<xsd:attribute name="level" type="xsd:integer" use="required">
			<xsd:annotation>
				<xsd:appinfo>
					<jaxb:property>
						<jaxb:baseType name="int" />
					</jaxb:property>
				</xsd:appinfo>
			</xsd:annotation>
		</xsd:attribute>
	</xsd:complexType>

	<xsd:element name="comment" type="markup" />

	<xsd:complexType name="markup" mixed="true">
		<xsd:annotation>
			<xsd:appinfo>
				<jaxb:class name="Style" />
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element ref="comment" />
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

when compiled with XJC v2.2.11 (also tried v2.2.4 and v2.2.8) causes NPE:

D:\jaxb-ri\bin\xjc.bat -extension test.xsd

parsing a schema...
[WARNING] Cannot generate default value for primitive type "int".
  line 19 of file:/D:/test.xsd

compiling a schema...
Exception in thread "main" java.lang.NullPointerException
	at com.sun.tools.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:188)
	at com.sun.tools.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:161)
	at com.sun.tools.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:129)
	at com.sun.tools.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:112)
	at com.sun.tools.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:77)
	at com.sun.tools.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:82)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:777)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:558)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:261)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:169)
	at com.sun.tools.xjc.model.Model.generateCode(Model.java:288)
	at com.sun.tools.xjc.Driver.run(Driver.java:384)
	at com.sun.tools.xjc.Driver.run(Driver.java:221)
	at com.sun.tools.xjc.Driver._main(Driver.java:144)
	at com.sun.tools.xjc.Driver.access$000(Driver.java:82)
	at com.sun.tools.xjc.Driver$1.run(Driver.java:103)


 Comments   
Comment by Dmitry Katsubo [ 24/Oct/16 ]

Actually the problematic XSD is simpler:

<?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"
	xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
	jaxb:version="2.1"
	jaxb:extensionBindingPrefixes="xjc"
	elementFormDefault="qualified">

	<xsd:annotation>
		<xsd:appinfo>
			<jaxb:globalBindings>
				<xjc:simple />
			</jaxb:globalBindings>
		</xsd:appinfo>
	</xsd:annotation>

	<xsd:element name="comment" type="markup" />

	<xsd:complexType name="markup" mixed="true">
		<xsd:annotation>
			<xsd:appinfo>
				<jaxb:class name="Style" />
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element ref="comment" />
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

which means that problem occurs when there is a circular dependency in the type and type class name is customized.





[JAXB-1107] Text nodes are not unmarshalled for combination @XmlMixed + @XmlElementRefs + @XmlElementWrapper Created: 20/Oct/16  Updated: 20/Oct/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The issue is described here. In particular for the following model element:

@XmlRootElement(name = "any-text")
public class AnyText {

    @XmlElementWrapper(name = "fixed-text", required = true)
    @XmlElementRefs({
        @XmlElementRef(name = "year", namespace = "http://foo.org/", type = JAXBElement.class, required = false),
        @XmlElementRef(name = "title", namespace = "http://foo.org/", type = JAXBElement.class, required = false)
    })
    @XmlMixed
    protected List<Serializable> fixedText = new ArrayList<Serializable>();
...

the hanging text nodes are not unmarshalled/marshalled. Sample XML:

<any-text xmlns="http://foo.org/">
    <fixed-text>The story <title>Alice in Wonderland</title> was printed in <year>1865</year>.</fixed-text>
</any-text>

Sample XSD:

<xs:schema
	jaxb:version="2.0"
	targetNamespace="http://foo.org/"
	xmlns:foo="http://foo.org/"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"
>
	<xs:complexType name="fixed-text" mixed="true">
		<xs:choice maxOccurs="unbounded">
			<xs:element name="title" type="xs:string" />
			<xs:element name="year" type="xs:int" />
		</xs:choice>
	</xs:complexType>

	<xs:element name="any-text">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="fixed-text" type="foo:fixed-text" />
			</xs:sequence>
		</xs:complexType>
	</xs:element>
</xs:schema>





[JAXB-1106] Regression caused by jaxbJAXB-856 xs:import namespace="http://www.w3.org/2005/05/xmlmime" is not generated Created: 23/Sep/16  Updated: 23/Sep/16

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: RolandF Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I strongly assume that the fix for

jaxbJAXB-856 xs:import namespace="http://www.w3.org/2005/05/xmlmime" is not generated

is incorrect. Actually everything in the www.w3.org namespace should be well-known standard datatypes and/or their definition delivered in xsd files along with the jaxb/jax-ws APIs.

If the assumption to create an import for this namespace was correct, the same logic would have to be applied for e.g.

http://www.w3.org/2001/XMLSchema

as well - or the namespaces for webservice Security, reliable-messaging, etc. which is not the case.

This "new" import is causing issues for clients which don't have internet access. The import ist generated with a schemaLocation that equals the namespace and clients start to try and download this schema from www.w3.org although it should be available locally.

I haven't found a way so far to provide the schema locally and redirect the schemaLocation to the local copy instead and the schemaLocation keeps the client from working.

It is also interesting that these datatypes worked without import from 2005 until 2011 when suddenly this import was created. I assume the fix for the original problem should look different.



 Comments   
Comment by RolandF [ 23/Sep/16 ]

checking further

https://www.w3.org/TR/xml-media-types/

I do see that there are schema examples having this import as well and I am also aware that in theory the import requirement is correct.
However I don't see how to overcome the problem of clients not able to download this schema from the internet (e.g. client running on a server accessing another local server).

the clients which used to work without JAXB generating this import stopped working since JAXB-856 has been implemented.

https://issues.apache.org/jira/browse/ODE-213
https://community.hpe.com/t5/Service-Manager-Service-Center/SM7-11-How-to-make-Web-service-work-without-Internet-access/td-p/5421891

are just two samples describing how this import is creating problems for people.

The workaround to download everything locally, adjust the xsd and have the client pick it up from there seems not feasible on a large client deployment. If the fix has to be kept, are there ways to customize the "schemaLocation" pointing to an internet URL?

Comment by RolandF [ 23/Sep/16 ]

https://support.adeptia.com/hc/en-us/articles/207878443-Consumer-Server-returned-HTTP-response-code-403

adds yet another flavour to this topic:

"The webservice wsdl is referencing a publicly available xsd at http://www.w3.org/2005/05/xmlmime which is accessed each time the web service is called. Per w3 documentation, your IP will be blocked when they receive "at least 500 requests for the same resource (URI) from your IP address within a ten-minute time interval."

Reference link - http://www.w3.org/Help/abuse-info/re-reqs.html

Even though the spec samples mandate the import to be present, adding it seems highly impractical in a real life deployment. This amount of requests should easily be reached on a client set up in a server env (e.g. one stub per thread).

Is there an easier way to overcome these troubles and generate a WSDL/Schema which doesn't run into the issue?





[JAXB-1105] xjc mark-generated sometimes produces a wrong date value Created: 15/Sep/16  Updated: 15/Dec/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ghusta Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 8, JDK 7



 Description   

When using the parameter "-mark-generated" to generate the @Generated annotation, the content of the date attribute may be wrong.

In fact, the PM dates are wrong as they stay at the AM format.

It's because the date pattern used for generating the ISO-8601 string is wrong.
It's "yyyy-MM-dd'T'hh:mm:ssZ" but it should be "yyyy-MM-dd'T'HH:mm:ssZ"

The code to fix is in com.sun.tools.xjc.addon.at_generated.PluginImpl

    private String getISO8601Date() {
        if(date==null) {
            StringBuffer tstamp = new StringBuffer();
            tstamp.append((new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ssZ")).format(new Date()));
            // hack to get ISO 8601 style timezone - is there a better way that doesn't require
            // a bunch of timezone offset calculations?
            tstamp.insert(tstamp.length()-2, ':');
            date = tstamp.toString();
        }
        return date;
    }

Maven artifact : com.sun.xml.bind:jaxb-xjc:2.2.11

Thanks.



 Comments   
Comment by Michael Osipov [ 17/Sep/16 ]

There is also another issue here: If the timezone is UTC, there must be a Z and not +00:00, so there are two bugs here.

Comment by Michael Osipov [ 15/Dec/16 ]

The value has actually to be yyyy-MM-dd'T'HH:mm:ssXXX.





[JAXB-1104] Generate goal fails with JDK 1.8.0 - again Created: 19/Aug/16  Updated: 04/Oct/16

Status: Open
Project: jaxb
Component/s: maven-plugin, xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Dr4gon Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jaxb-xjc-2.2.8-b01
Apache Maven 3.2.5
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Windows 7



 Description   

I found this bug https://java.net/jira/browse/MAVEN_JAXB2_PLUGIN-85.
With the current version this problem still persists:

Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.mojo.jaxws.Invoker.main(Invoker.java:78)
caused by: java.lang.AssertionError: org.xml.sax.SAXParseException; systemId: jar:file:/C:/Users/diu/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.2.8-b01/jaxb-xjc-2.2.8-b01.jar!/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Schemadokument "xjc.xsd" konnte nicht gelesen werden, weil der "file"-Zugriff wegen der von der Eigenschaft accessExternalSchema festgelegten Einschränkung nicht zulässig ist.
at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:80)
at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:541)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:269)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:95)
at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:142)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2298)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:198)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:141)
at com.sun.tools.ws.wscompile.WsimportTool.buildWsdlModel(WsimportTool.java:444)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:205)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:183)
... 5 more
Caused by: java.lang.AssertionError: org.xml.sax.SAXParseException; systemId: jar:file:/C:/Users/diu/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.2.8-b01/jaxb-xjc-2.2.8-b01.jar!/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Schemadokument "xjc.xsd" konnte nicht gelesen werden, weil der "file"-Zugriff wegen der von der Eigenschaft accessExternalSchema festgelegten Einschränkung nicht zulässig ist.
at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:80)
at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:541)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:269)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:95)
at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:142)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2298)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:198)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:141)
at com.sun.tools.ws.wscompile.WsimportTool.buildWsdlModel(WsimportTool.java:444)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:205)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:183)
... 5 more
Caused by: org.xml.sax.SAXParseException; systemId: jar:file:/C:/Users/diu/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.2.8-b01/jaxb-xjc-2.2.8-b01.jar!/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88;schema_reference: Schemadokument "xjc.xsd" konnte nicht gelesen werden, weil der "file"-Zugriff wegen der von der Eigenschaft accessExternalSchema festgelegten
Einschränkung nicht zulässig ist.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:441)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4162)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaFatalError(XSDHandler.java:4141)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchema(XSDHandler.java:2078)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1008)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:620)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:575)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:541)
at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638)
at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:670)
at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:77)
... 16 more



 Comments   
Comment by Dr4gon [ 04/Oct/16 ]

This is really stupid. When you google in English it's the first solution you'll find (second comment is with a maven dependency I added as comment): http://stackoverflow.com/questions/23011547/webservice-client-generation-error-with-jdk8.

I can't close this ticket however it solves the JDK8 problem.





[JAXB-1103] Unmarshaling of bound generic Type fails Created: 16/Aug/16  Updated: 16/Aug/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: poseidonFS Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 10 / jdk1.8.0_91 / eclipse neon 4.6.0



 Description   

On a generic typed Bean-Class, an Element of that Generic type may be marshaled and unmarshaled - this works.
But if the Generic Type gets bound to an abstract class, the unmarshaling Fails.

In the following example, I need a boundary for any type of Number, but JAXB tries to unmarshal this by instantiating to Number, which is abstract.
Ommitting the boundary or changing it to an instantiable type (like Object) solves the issue, but weakens the generics.

JaxbTester.java
package de.panbytes.playground.jaxb;

import java.io.StringReader;
import java.io.StringWriter;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

public class JaxbTester {

  /*
   * AbstractContainer<T> -> works, but misses boundaries
   * AbstractContainer<T extends Object> -> works, but boundaries are too large
   * AbstractContainer<T extends Number> -> fails: "Exception in thread "main" javax.xml.bind.UnmarshalException: Unable to create an instance of java.lang.Number"
   */
  static abstract class AbstractContainer<T /* extends Number */> {

    @XmlElement
    T someNumber;

  }

  @XmlRootElement
  static class ContainerImpl<T extends Number> extends AbstractContainer<T> {

    @SuppressWarnings("unused")
    private ContainerImpl() {
      // for JAXB
    }

    public ContainerImpl(final T someNumber) {
      this.someNumber = someNumber;
    }

  }

  /**
   * @param args
   */
  public static void main(final String[] args) throws Exception {
    final AbstractContainer<Double> containerA = new ContainerImpl<>(42.5);

    final JAXBContext context = JAXBContext.newInstance(ContainerImpl.class);

    final Marshaller marshaller = context.createMarshaller();
    marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

    final StringWriter stringWriter = new StringWriter();
    marshaller.marshal(containerA, stringWriter);
    final String xmlString = stringWriter.toString();

    System.out.println(xmlString);

    final Unmarshaller unmarshaller = context.createUnmarshaller();
    unmarshaller.setEventHandler(event -> {
      System.err.println("!! " + event.getMessage() + " - " + event.getLocator() + "\n");
      return true;
    });

    final Object unmarshal = unmarshaller.unmarshal(new StringReader(xmlString));
    System.out.println("unmarshal: " + unmarshal.toString());
  }

}

The marshaled XML is the following, in each case containing the correct xsi:type="xs:double".

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<containerImpl>
    <someNumber xsi:type="xs:double" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">42.5</someNumber>
</containerImpl>





[JAXB-1102] nillable true element fails to generate a ref Created: 10/Aug/16  Updated: 11/Aug/16

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vakopian Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is a regression in jaxb 2.2.x compared to 2.1.17, and only happens if nillable=true is set in the @XmlElement annotation below.
When running schemagen against the following two classes

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "Parent")
public class Parent {
}


@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "Child")
public class Child {
    @XmlElement(name = "Parent", namespace = "http://journaltech.com/p", required = true , nillable = true)
    protected Parent parent;
}

the generated xsd for Child has the following incorrect element:

  <xs:complexType name="Child">
    <xs:sequence>
      <xs:element name="Parent" nillable="true" type="ns1:Parent"/>
    </xs:sequence>
  </xs:complexType>

The correct version (generated by 2.1.7) should be

  <xs:complexType name="Child">
    <xs:sequence>
      <xs:element ref="ns1:Parent"/>
    </xs:sequence>
  </xs:complexType>

where the nillable attribute should be set on the referenced element:

  <xs:element name="Parent" type="tns:Parent" nillable="true"/>

full example at https://github.com/sustain/jaxb-test



 Comments   
Comment by vakopian [ 11/Aug/16 ]

Turns out this is not a regression: 2.1.17 behaves the same way as 2.2.x. But the behavior did change from version 2.1.13 to 2.1.14.
Version 2.1.13 produces:

 <xs:complexType name="Child">
    <xs:sequence>
      <xs:element ref="ns1:Parent" nillable="true"/>
    </xs:sequence>
  </xs:complexType>

while version 2.1.14 produces:

<xs:complexType name="Child">
    <xs:sequence>
      <xs:element name="Parent" nillable="true" type="ns1:Parent"/>
    </xs:sequence>
  </xs:complexType>

The result from 2.1.13 is wrong based on the XSD specification: nillable is not allowed with ref. However, the fix should be to keep using a ref, but move the nillable attribute to the referenced element:

<xs:complexType name="Child">
    <xs:sequence>
      <xs:element ref="ns1:Parent"/>
    </xs:sequence>
  </xs:complexType>
...
<xs:element name="Parent" type="tns:Parent" nillable="true"/>




[JAXB-1101] JAXB nillable="true" Created: 08/Aug/16  Updated: 08/Aug/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: msqmava Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JAXB2.0



 Description   

I am getting xsd's from a 3rd party company, with which I am generating the JAXB objects. When I try to marshall the objects onto XML, the marshaller adds empty elements with nil="true".
Even if the xsd definition has element defined as nillable="true" or nillable="false", JAXB marshaller always adds empty element with nil="true". When I try to validate this marshaller xml against the xsd, I see validation errors even though the element is optional and a value is not passed to it.

Is there any way you can help me or point out a way by which I can skip the generation of this nil=true elements completely.

I don't want to manipulate the XML string by using String operations as it might be a bad practice.






[JAXB-1100] UnmarshallerImpl does not call clearResult() in all cases Created: 15/Jun/16  Updated: 15/Jun/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are certain flows during unmarshalling when clearResult() is called (see UnmarshallerImpl#unmarshal0(XMLStreamReader, JaxBeanInfo)), but sometimes it is not called (see UnmarshallerImpl#unmarshal0(XMLEventReader, JaxBeanInfo)).

Expected that it is called in all cases to allow GC to clean the result prior unmarshaller is GC'ed (or new unmarshalling operation is started).



 Comments   
Comment by Dmitry Katsubo [ 15/Jun/16 ]

The possible fix could be:

--- UnmarshallerImpl.java.orig	Tue Jun 14 11:32:30 2016
+++ UnmarshallerImpl.java	Tue Jun 14 11:49:15 2016
@@ -230,6 +230,7 @@
         // setting null upsets some parsers, so use a dummy instance instead.
         reader.setContentHandler(dummyHandler);
         reader.setErrorHandler(dummyHandler);
+        coordinator.clearResult();
 
         return result;
     }
@@ -410,7 +411,9 @@
             if(!isZephyr)
                 h = new InterningXmlVisitor(h);
             new StAXEventConnector(reader,h).bridge();
-            return h.getContext().getResult();
+            Object result = h.getContext().getResult();
+            h.getContext().clearResult();
+            return result;
         } catch (XMLStreamException e) {
             throw handleStreamException(e);
         }




[JAXB-1099] Binding Customizations errors when using Episode Created: 10/Jun/16  Updated: 08/Jul/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: flutter Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: customization, episode
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

Java 1.7, JAXB 2.2.11


Tags: customization, episode, error, multi-module, xjc

 Description   

When using the "episode" mechanism, all plugin customization elements directly embedded in XSD files referenced via the "episode" currently cause the error message "Compiler was unable to honor the ... customization.", regardless whether the respective plugin is actually activated or not.
Expected behavior would be to either ignore all customizations in referenced XSDs listed in the episode, or to make them available to activated plugins in the downstream module.



 Comments   
Comment by snilloc.bor [ 08/Jul/16 ]

This bug is annoying and it definitely should be fixed.

I have implemented a workaround that solves my current situation, and want to share it with others that might be bumping up against this bug.

Workaround:
I have added a step in the build during the prepare-package step of the maven lifecycle to execute the maven-replacer-plugin to remove (replace with empty) the jaxb:extensionBindingPrefixes attribute from the XSD files before they are packaged in the jar. In this way, when the XSD is imported in a downstream module (via the episode mechanism), the previously-processed customizations in the imported schema are not seen by xjc, thus side-stepping the bug.

This workaround is not suitable if the jaxb:extensionBindingPrefixes is needed by a consumer of the schema file from the packaged jar file for some other reason.





[JAXB-1098] Unable to generate sources Created: 21/Apr/16  Updated: 21/Apr/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: olaf_xso Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, jdk1.8.0_91



 Description   

Hi,

I am unable to generate source for a xml schema.
Am I doing something wrong or is the schema invalid... or is it a bug?

Here is my schema:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>W3Schools Note</xs:appinfo>
<xs:documentation xml:lang="en">
This Schema defines a W3Schools note!
</xs:documentation>
</xs:annotation>
</xs:schema>
This schema is saved in C:\test.xsd

I am calling xjc as follows:
xjc.exe C:\test.xsd -p -d C:\test\src-p nl.xso.test

the output is:
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location

I also tried to run it from a java application as follows:

public class Generate{
public static void main( String[] args ) {
try {
com.sun.tools.xjc.Driver.main( new String[]

{ "C:/test.xsd", "-verbose", "-d", "C:/test/src", "-p", "nl.xso.test" }

);
}
catch ( Exception e )

{ e.printStackTrace(); }

System.exit( 0 );
}
}

the output is:
parsing a schema...
Exception in thread "main" javax.xml.validation.SchemaFactoryConfigurationError: Provider for class javax.xml.validation.SchemaFactory cannot be created
at javax.xml.validation.SchemaFactoryFinder.findServiceProvider(SchemaFactoryFinder.java:414)
at javax.xml.validation.SchemaFactoryFinder._newFactory(SchemaFactoryFinder.java:218)
at javax.xml.validation.SchemaFactoryFinder.newFactory(SchemaFactoryFinder.java:145)
at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:213)
at com.sun.xml.bind.v2.util.XmlFactory.createSchemaFactory(XmlFactory.java:98)
at com.sun.tools.xjc.reader.xmlschema.parser.SchemaConstraintChecker.check(SchemaConstraintChecker.java:86)
at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:360)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:174)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
at com.sun.tools.xjc.Driver.run(Driver.java:354)
at com.sun.tools.xjc.Driver.run(Driver.java:221)
at com.sun.tools.xjc.Driver._main(Driver.java:144)
at com.sun.tools.xjc.Driver.access$000(Driver.java:82)
at com.sun.tools.xjc.Driver$1.run(Driver.java:103)
Caused by: java.util.ServiceConfigurationError: javax.xml.validation.SchemaFactory: Provider org.iso_relax.verifier.jaxp.validation.RELAXNGSchemaFactoryImpl could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232)
at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at javax.xml.validation.SchemaFactoryFinder$2.run(SchemaFactoryFinder.java:403)
at javax.xml.validation.SchemaFactoryFinder$2.run(SchemaFactoryFinder.java:399)
at java.security.AccessController.doPrivileged(Native Method)
at javax.xml.validation.SchemaFactoryFinder.findServiceProvider(SchemaFactoryFinder.java:399)
... 13 more
Caused by: java.lang.NoClassDefFoundError: org/iso_relax/verifier/VerifierConfigurationException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getConstructor0(Class.java:3075)
at java.lang.Class.newInstance(Class.java:412)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.iso_relax.verifier.VerifierConfigurationException
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 24 more



 Comments   
Comment by laune [ 21/Apr/16 ]

1. The xjc command line you have provided is incorrect.
2. A correct invocation does not produce any error messages.
3. What source code do you expect from this XML Schema anyway? Can you provide an XML file that agrees with this XML Schema?

Kindly refrain from asking for help on the JIRA site. It is provided for bugs.

Comment by olaf_xso [ 21/Apr/16 ]

Hi,

Sorry for the typo, it must be:
xjc.exe C:\test.xsd -d C:\test\src -p nl.xso.test

The output prints: unknown location. I was wondering why and what am I doing wrong or it could be a bug.

I actually want to generate sources for a bigger xsd file:
http://www.nltaxonomie.nl/10.0/report/bd/entrypoints/bd-rpt-ob-aangifte-2016.xsd

While trying to generate sources for this file it also prints the message 'unknown location'. And there are no sources generated.
So I have simplified the bigger file and the test xsd remains.. It still prints 'unknown location'.





[JAXB-1097] NPE with reference property referencing a CClassRef Created: 17/Apr/16  Updated: 17/Apr/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File one.xjb     XML File one.xsd     XML File two.xsd    

 Description   

I've encountered an XJC bug in the following report:

https://github.com/highsource/maven-jaxb2-plugin/issues/90

Minimal reproducing test case attached. Just run

xjc two.xsd -extension -b one.xjb

To get an NPE:

Caused by: java.lang.NullPointerException
	at com.sun.tools.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:198)
	at com.sun.tools.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:161)
	at com.sun.tools.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:129)
	at com.sun.tools.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:112)
	at com.sun.tools.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:77)
	at com.sun.tools.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:82)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:777)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:558)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:261)
	at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:169)
	at com.sun.tools.xjc.model.Model.generateCode(Model.java:288)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.generateCode(XJC22Mojo.java:66)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:41)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:28)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:505)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:328)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
	... 20 more

The problem is that when we have a reference property which references the element one. If this element is made a CClassRef via binding. The CClassRef returns null as elementName so this lines:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/xjc/src/main/java/com/sun/tools/xjc/generator/bean/field/AbstractField.java#L198-L200

are giving an NPE.

The solution would be to extract element name from the @XmlRootElement annotation of the CClassRef's class.






[JAXB-1096] Schemagen tool won't generate xsd if pojo contains java.time.LocalDate field Created: 16/Apr/16  Updated: 12/Jan/17

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Andy_K Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MS Windows 7



 Description   

I've tried generate xsd schema for POJO contains java.time.LocalDate field.

In case, if this field isn't annotated, I've got a message:

java.time.LocalDate is a non-static inner class, and JAXB can't handle those.

But, I've created adapter extending XmlAdapter<String,LocalDate> for LocalDate class and then annotated necessary field with next annotation:

@XmlJavaTypeAdapter(value = ...utils.LocalDateAdapter.class)

In this case xsd also will not generated, and output will be just "null"



 Comments   
Comment by slavb18 [ 12/Jan/17 ]

With package-level annotations (adaptors from com.migesok:jaxb-java-time-adapters)

@XmlJavaTypeAdapters(

{ @XmlJavaTypeAdapter(type = LocalDate.class, value = LocalDateXmlAdapter.class), @XmlJavaTypeAdapter(type = LocalTime.class, value = LocalTimeXmlAdapter.class), @XmlJavaTypeAdapter(type = LocalDateTime.class, value = LocalDateTimeXmlAdapter.class) }

)
@XmlSchemaTypes(

{ @XmlSchemaType(name = "date", type = LocalDate.class), @XmlSchemaType(name = "time", type = LocalTime.class), @XmlSchemaType(name = "dateTime", type = LocalDateTime.class) }

)

Schemagen generates schema with all LocalDate, LocalTime, LocalDateTime class fields reset to xs:string. How to fix schema generation ?

Comment by slavb18 [ 12/Jan/17 ]

Only field-level annotations work (e.g. @XmlSchemaType(name="dateTime") placed directly on field





[JAXB-1095] Unmarshalling of abstract/ fails if JAXBContext created with newInstance(Class.. classesToBeBound) Created: 14/Mar/16  Updated: 14/Mar/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.3, 2.2.7, 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mattias Jiderhamn Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When having generated classes with xjc from a schema with abstract + substitutionGroup, unmarshalling fail silently (ignores abstract elements) if JAXBContext is created using JAXBContext.newInstance(MyClass.class).

If works however when using JAXBContext.newInstance("mypackage") or JAXBContext.newInstance(mypackage.ObjectFactory.class).

Please see https://github.com/mjiderhamn/jaxb-unmarshal-abstract for a full test case demonstrating the issue. This is the test that fails.



 Comments   
Comment by Mattias Jiderhamn [ 14/Mar/16 ]

Possibly related to JAXB-797





[JAXB-1094] IndentingUTF8XmlOutput and DataWriter format XML differently Created: 11/Mar/16  Updated: 11/Mar/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If XML output formatting property is enabled, IndentingUTF8XmlOutput (used if output encoding is UTF-8) and DataWriter (used for other output encodings) produce different XML output for mixed-content XML tags:

<div>
    <p>text<br/></p>
</div>

v.s.

<div>
    <p>text
        <br/>
    </p>
</div>

In particular, IndentingUTF8XmlOutput tracks if text was already added to the body of the tag and if so, disables the indentation for following siblings, see usage of variable seenText.

Expected: regardless the encoding, the formatting behaves the same way.






[JAXB-1093] Publish U.S. ECCN for Jaxb compiler and support libraries Created: 04/Mar/16  Updated: 04/Mar/16

Status: Open
Project: jaxb
Component/s: runtime, xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Task Priority: Minor
Reporter: chrislott Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours


 Description   

Please publish an Export Control Classification Number (ECCN) for JAXB components including the xjc schema compiler in jaxb-xjc.jar and the runtime libraries jamb-api.jar and jaxb-impl.jar. Of course this requires reading the Commerce Control List (CCL) (Supplement No. 1 to Part 774 of the EAR), then trying to figure out where the software best fits. Oracle publishes a comprehensive list of ECCN information for the company's products, a recent list is http://www.oracle.com/us/products/export/eccn-matrix-software-412042.pdf but that document makes no statement about JAXB.

This may help:
https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn

Thanks for listening.






[JAXB-1092] JAXB sometimes does not preserve xsi:nil attribute Created: 24/Feb/16  Updated: 24/Feb/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ebiggers Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In some cases, an element given the "xsi:nil" attribute loses it after the XML document has been deserialized to a Java object, then serialized back to XML.

Example schema:

<?xml version="1.0"?>
<xsd:schema targetNamespace="http://example.com/TestSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/TestSchema">

    <xsd:complexType name="TestMessage">
        <xsd:sequence>
            <xsd:element name="nillableString" type="xsd:string"  minOccurs="0"  nillable="true" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="TestMessage"  type="TestMessage" />

</xsd:schema>

Example document, before sending it through JAXB:

<ns1:TestMessage xmlns:ns1="http://example.com/TestSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <nillableString xsi:type="xsd:string" xsi:nil="true"/>
</ns1:TestMessage>

Example document, after round trip through JAXB:

<TestMessage xsi:type="ns2:TestMessage" xmlns:ns2="http://example.com/TestSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <nillableString></nillableString>
</TestMessage>

As you can see, the "nillableString" element lost the "xsi:nil" attribute.

I do not see an option to attach files but I can attach a runnable example (with Java source) demonstrating the problem if needed.






[JAXB-1091] Elements classes are not added to episode file Created: 11/Feb/16  Updated: 11/Feb/16

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Artemik Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Generated classes that correspond to xsd elements (i.e. those that extend JAXBElement) are not added to episode file.
It leads to creating them again when reusing this schema with this episode.






[JAXB-1090] Classes for elements of the same type created every time in episodic generation Created: 10/Feb/16  Updated: 10/Feb/16

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Artemik Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have two xsd files. In the base xsd file I have two elements of the same type. Therefore one of them is not created with XmlRootAnnotation and is not written into episode.xjb file when generating schema for the base xsd.
It leads to creating this class again for the second xsd, since it is not presented in any way in the episode.xjb. It seems that it's not supported at all as for now.
Version tested: 2.2.11



 Comments   
Comment by Artemik [ 10/Feb/16 ]

Need to mention that they have the same namespace and the base xsd is xsd:include'ed in the second one.





[JAXB-1089] Missing generated property of extension type Created: 06/Feb/16  Updated: 06/Feb/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8), 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gtaffon Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux gtaffon-Lenovo-G50-45 3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)



 Description   

If I launch

xjc -d generated/src/ example.xsd

using the example.xsd below

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="http://www.clicksoftware.com" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.clicksoftware.com" elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:complexType name="ObjectReference" mixed="true">
        <xs:attribute name="DisplayString" type="xs:string"/>
        <xs:attribute name="Key" type="xs:int"/>
    </xs:complexType>
    <xs:complexType name="REFERENTReference" mixed="true">
        <xs:complexContent>
            <xs:extension base="tns:ObjectReference">
                <xs:sequence>
                    <xs:element name="UniqueID" type="xs:string" minOccurs="0"/>
                </xs:sequence>
           </xs:extension>
        </xs:complexContent>
    </xs:complexType>
</xs:schema>

I obtain this class without the expected property UniqueID:

REFERENTReference.java
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.8-b130911.1802 
// See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
// Any modifications to this file will be lost upon recompilation of the source schema. 
// Generated on: 2016.02.06 at 02:33:23 PM CET 
//


package com.clicksoftware;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for REFERENTReference complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * &lt;complexType name="REFERENTReference">
 *   &lt;complexContent>
 *     &lt;extension base="{http://www.clicksoftware.com}ObjectReference">
 *       &lt;sequence>
 *         &lt;element name="UniqueID" type="{http://www.w3.org/2001/XMLSchema}string" minOccurs="0"/>
 *       &lt;/sequence>
 *     &lt;/extension>
 *   &lt;/complexContent>
 * &lt;/complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "REFERENTReference")
public class REFERENTReference
    extends ObjectReference
{


}





[JAXB-1088] XmlAdapter invoked but its object manipulation is ignored. Created: 29/Jan/16  Updated: 29/Jan/16

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hafizullah Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: jaxb, xmladapter
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac


Tags: xmladapter

 Description   

Hi,
I have written an xml adapter that does a simple function:
checks the string if it is empty set the string to null

while this was fine to hook into jaxb, but when it was marshalling the adapter would get invoked all values set to null where they were empty string at the end the mashaller would not take any notice of it so it would print the same thing again






[JAXB-1087] Unmarshalling Wrapped elements with elementForName=qualified fails Created: 25/Jan/16  Updated: 25/Jan/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ray5 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

x64 Oracle JDK u72 on Win10



 Description   

Unmarshalling of Wrapped Collections seems to be problematic when combined with elementFormDefault=Qualified.

Excerpt from my Source Code:

package-info.java:
@XmlSchema(elementFormDefault = XmlNsForm.QUALIFIED)
@XmlAccessorType(XmlAccessType.NONE)

Class:
@XmlRootElement(name = "device", namespace = "http://www.rs.tu-darmstadt.de/ns/spartanmc/devices")
public class DeviceDescription

{ @XmlElementWrapper(name = "drives") @XmlElement(name = "drive") private List<String> drives; }

The List can be marshalled correctly. But unmarshalling always ends up with an empty List.

Xml:
<device xmlns=""http://www.rs.tu-darmstadt.de/ns/spartanmc/devices">
<drives>
<drive>1</drive>
<drive>2</drive>
</drives>
</device>

If the namespace is explicitly added to the XmlElement annotation unmarshalling works.
Using @XmlAnyElement inside the wrapper list all contents and confirms that the child elements do infact belong to the "...devices" namespace.






[JAXB-1086] Performance improvement in com.sun.xml.bind.v2.runtime.Coordinator Created: 15/Dec/15  Updated: 15/Dec/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: asoldano Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It's possible to reduce memory allocation in Coordinator by setting its thread-local member to null instead of removing it. See the patch below:

diff --git a/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/runtime/Coordinator.java b/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/runtime/Coordinator.java
index 4695d4e..c97a8f8 100644
--- a/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/runtime/Coordinator.java
+++ b/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/runtime/Coordinator.java
@@ -129,10 +129,7 @@ protected final void pushCoordinator() {
      * Called whenever an execution flow exits the realm of this {@link Coordinator}.
      */
     protected final void popCoordinator() {
-        if (old != null)
-            activeTable.set(old);
-        else
-            activeTable.remove();
+        activeTable.set(old);
         old = null; // avoid memory leak
     }





[JAXB-1085] @XmlTransient should be allowed on any transient field Created: 09/Nov/15  Updated: 09/Nov/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: jinahya Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)


Tags: transient

 Description   

With following code,
```
@XmlTransient
private transient Some some;
```
JAXB complains
```
Transient field "some" cannot have any JAXB annotations.
```
`@XmlTransient` should be excluded from this rule.






[JAXB-1084] Java Object Model is not populated for empty elements with a fixed value Created: 29/Sep/15  Updated: 29/Sep/15

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdx Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 8 update 20, Eclipse 4.4.1, Ant 1.9.4, Weblogic 12.1.3



 Description   

When an element in an XML document has a fixed value, the document is valid when the element is empty or the elements value equals the fixed value defined in the schema.

However, when populating the Java Object Model based upon the XML document, the output is not deterministic. If the element has a value, then the value is populated. However, if the element is empty then the Java Object Model's value is null. This seems to contradict the XML spec since the Java Object Model should be populated with the fixed value defined in the XSD just like it is when a default value is used.






[JAXB-1083] Wrong schema generated: Not a valid XSD when @XmlType(propOrder = {}) used with List Created: 16/Sep/15  Updated: 16/Sep/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: juherr Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(propOrder = {})
public class Root {
	
    @XmlElement
    private List<String> elements = new ArrayList<>();

    @XmlElement
    private String string;
}

will generate the following XSD:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="root" type="root"/>

  <xs:complexType name="root">
    <xs:all>
      <xs:element name="elements" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="string" type="xs:string" minOccurs="0"/>
    </xs:all>
  </xs:complexType>
</xs:schema>

But maxOccurs="unbounded" is not legal for <xs:all>.

The bad part is that jaxb is not able the parse the file it has itself generated.

(I target "runtime" component because I am using JAXBContext#generateSchema method)



 Comments   
Comment by laune [ 16/Sep/15 ]

Could you please add the XML Schema snippet you expect to be generated for your Java class?

Comment by juherr [ 16/Sep/15 ]

I have no idea about what the XSD should be.
I'm not an XML/XSD expert but I think it's not possible to modelize what I want (some single elements + a list, without order) with XSD.

Maybe the generation should fail when it try to set maxOccurs="unbounded" into a <xs:all>.

In fact, it shouldn't be possible to generate bad XSD and I don't care how users/I will be warn.

EDIT: It tried with MOXy too and it has the same problem. Maybe you should provide the same fix?

Comment by laune [ 16/Sep/15 ]

I do not agree with "The bad part is that jaxb is not able the parse the file it has itself generated." In fact, this is fine, since any good XML Schema parser is the ultimate arbiter for whatever a schema generator issues. And one will have to rely on that to ensure that the generated XML Schema is OK. And that's why I don't agree with "priority major".

I agree: the XML you have been trying to describe can't be defined using XML Schema. The closest you can get is some strict order (<string> before or after).

XML Schema wasn't defined to comply with every designer's whim - some thought was given to make parsing and handling of XML efficient and not overly complex.

Comment by juherr [ 16/Sep/15 ]

I took the default priority value. Feel free to change it (I don't find the edit button).





[JAXB-1082] XJC: Generate methods in class ObjectFactory with modifier static Created: 12/Sep/15  Updated: 12/Sep/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: hartmannt Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, xjc generates methods in class ObjectFactory like

public Foo createFoo() {
  return new Foo();
}

However, this leads to the following warning in Eclipse:

The method createFoo() from the type ObjectFactory can potentially be declared as static

Thus, it would be better to generate the methods with modifier static:

public static Foo createFoo() {
  return new Foo();
}





[JAXB-1081] roperties don't get serialized when different XmlAccessorTypes are used Created: 27/Aug/15  Updated: 27/Aug/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: flo.javajira Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Overview:
AbstractClass has the property "myId" and forces its implementation in Classes that extend it.
FieldAccessingClass and PropertyAccessingClass extend the AbstractClass and are Serializable (@XmlRootElement),
FieldAccessingClass has @XmlAccessorType(XmlAccessType.FIELD) set, while PropertyAccessingClass has
@XmlAccessorType(XmlAccessType.PROPERTY).

Analysis:
When the class PropertyAccessingClass gets serialized, the property "myId" won't get serialized.

As fas as I understand jaxb and was able to analyze it, there are two reasons for this:
1. In com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl#checkOverrideProperties, the property "myId" gets detected as a "hiddenByOverride"-Field (this only happens because of the XmlAccessorType-mixing)
2. In com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl#serializeBody the line
Utils.REFLECTION_NAVIGATOR.getDeclaredField(beanClass, p.getFieldName()) == null only leads to non-existing fields being serialized.

I'm not sure whether this is expected behaviour, or if it is a bug. To me, leaving out properties of a class (PropertyAccessingClass) because some other class extends it (FieldAccessingClass) with a different XmlAccessorType seems like a bug.

Unfortunately, I can't say if the checkOverrideProperties shouldn't detect the property as hiddenByOverride or if serializeBody should do a != null check.

In JAXB-Versions before https://java.net/projects/jaxb/lists/commits/archive/2012-05/message/66 this commit (i.e. before 2.2.6) both Classes would've been serialized completly though.

A simple example is available here:
https://debugco.de/flo/jaxb_serialization_problem.zip
You obviously need to add the current jaxb-ri to your classpath.






[JAXB-1080] Binder.getJAXBNode() returns wrong JAXB object Created: 13/Aug/15  Updated: 13/Aug/15

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.8 (JDK 8), 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregory.lardiere Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the following test case which reproduces the bug : https://www.dropbox.com/s/o6alr2y8c2cowy5/jaxb-ri-bug2.zip?dl=0

The classes in package test.jaxb are generated from the included XSD with xjc.

For the last <complex/> node from the XML document, Binder.getJAXBNode() returns the wrong JAXB object. The object returned is a test.jaxb.Root instance instead of a test.jaxb.Complex instance.

The bug is reproducible on jdk1.8.0_51 (with embedded jaxb-ri), and also with JAXB-RI 2.2.11 (endorsed dirs mechanism). The output of class test.Test is :

<complex/> : test.jaxb.Complex@6d03e736
<complex/> : test.jaxb.Complex@5fd0d5ae
<complex/> : test.jaxb.Root@58372a00

The bug does NOT happen with EclipseLink's MOXy :

<complex/> : test.jaxb.Complex@4232c52b
<complex/> : test.jaxb.Complex@305fd85d
<complex/> : test.jaxb.Complex@11438d26





[JAXB-1079] Binder getXMLNode/getJAXBNode returns null for "simpleContent" objects Created: 13/Aug/15  Updated: 13/Aug/15

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.8 (JDK 8), 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregory.lardiere Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the attached test case which reproduces the bug.

The classes in package test.jaxb are generated from the included XSD with xjc. The class test.jaxb.Simple is generated from a complexType which contains only a simpleContent.

The Binder can't manage the class test.jaxb.Simple : the methods getXMLNode() and getJAXBNode() return null.

The bug is reproducible on jdk1.8.0_51 (with embedded jaxb-ri), and also with JAXB-RI 2.2.11 (endorsed dirs mechanism). The output of class test.Test is :

<simple>x</simple> XmlNode : null
<simple>y</simple> XmlNode : null
<simple>z</simple> XmlNode : null
<simple>x</simple> JAXBNode : null
<simple>y</simple> JAXBNode : null
<simple>z</simple> JAXBNode : javax.xml.bind.JAXBElement@52cc8049

The bug does NOT happen with EclipseLink's MOXy :

<simple>x</simple> XmlNode : [simple: null]
<simple>y</simple> XmlNode : [simple: null]
<simple>z</simple> XmlNode : [simple: null]
<simple>x</simple> JAXBNode : test.jaxb.Simple@e874448
<simple>y</simple> JAXBNode : test.jaxb.Simple@60285225
<simple>z</simple> JAXBNode : test.jaxb.Simple@45820e51


 Comments   
Comment by gregory.lardiere [ 13/Aug/15 ]

(didn't find how to attach a file)
Here is the test case : https://www.dropbox.com/s/l1hxyi0maa6tkqz/jaxb-ri-bug.zip?dl=0





[JAXB-1078] cvc-complex-type.3.2.2: Attribute 'bindingStyle' is not allowed to appear in element 'jxb:globalBindings' Created: 01/Jul/15  Updated: 14/Dec/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jeetendra Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Windows , Linux


Tags: bindingStyle

 Description   

I did switched my application from jdk 1.6 to jdk 1.8 and tested. found this error

[ERROR] cvc-complex-type.3.2.2: Attribute 'bindingStyle' is not allowed to appear in element 'jxb:globalBindings'

This seems due to Jaxb 2.0 (which is included for Java 1.8) is having issue. Could you guys help if there is any substitute for 'bindingStyle' in jaxb 2.0 .

If i switch to Jaxb 2.0 standard , my jaxb generated code does not have few classes , which makes it error prone for execution.
Would appreciate for any kind of suggestion/help.



 Comments   
Comment by puce [ 14/Dec/15 ]

According to http://docs.oracle.com/cd/E17802_01/webservices/webservices/docs/2.0/tutorial/doc/JAXBUsing4.html#wp149475 the following should work, but it results in the mentioned error:

<jxb:globalBindings bindingStyle="modelGroupBinding"/>

Where can I find the according XSD?
The link at http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/jaxb/index.html is broken.





[JAXB-1077] <xs:attribute name="myAttr" type="NMTOKENS"> mapped to @XmlSchemaType("NMTOKENS") List<String> Created: 29/Jun/15  Updated: 29/Jun/15

Status: Open
Project: jaxb
Component/s: spec, xjc
Affects Version/s: 2.0.3, 2.1.14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: thomasernest Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While generating Java from XSD, I get the following error case:

<xs:attribute name="myAttr" type="NMTOKENS" />

is mapped to

@XmlSchemaType("NMTOKENS")
List<String>

The problem is that @XmlSchemaType is applied to the list item, not the list itself. As a result it is mapped to

<xs:attribute name="myAttr">
  <xs:simpleType>
    <xs:list itemType="xs:NMTOKENS"/>
  </xs:simpleType>
</xs:attribute>

The expected behavior could be :

  1. Map to Java
    @XmlSchemaType("NMTOKEN")
    List<String>
    
  2. Map to Java
    @XmlSchemaType("NMTOKENS")
    String
    
  3. Provide an option to apply @XmlSchemaType on the list itself instead of list items.

I don't know if it is a detail missing in specification or an error in xjc.
This bug may happen with IDREFS too. It seems linked to JAXB-357.






[JAXB-1076] ClassLoader Leak Created: 27/Jun/15  Updated: 22/Jan/17

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chengas123 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: memory-leak
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javax.xml.bind.DatatypeConverterImpl in the JAXB Reference Implementation shipped with JDK 1.6+ will keep a static reference (datatypeFactory) to a concrete subclass of javax.xml.datatype.DatatypeFactory, that is resolved when the class is loaded (which I believe happens if you have custom bindings that reference the static methods in javax.xml.bind.DatatypeConverter). It seems that if for example you have a version of Xerces inside your application, the factory method may resolve org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl as the implementation to use (rather than com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl shipped with the JDK), which means there will a reference from javax.xml.bind.DatatypeConverterImpl to your classloader.



 Comments   
Comment by chengas123 [ 22/Jan/17 ]

Any chance this issue could be looked at?





[JAXB-1075] Add flag to allow missed CPluginCustomization.markAcknowledged() to emit warnings instead of failing the execution. Created: 23/May/15  Updated: 09/Jun/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: jahutton Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As far as I can tell there is no reason (and no requirement in the spec) to error if the CPluginCustomization.markAcknowledged() of a plugin is not invoked. If the goal is to notify the user so that they can evaluate any missed customizations, then it should be emitted as a warning/info. Otherwise what this leads to are a bunch of custom jaxb plugins that just mark everything as acknowledged. Having this as an option would allow users who feel it necessary to error out to keep this behavior.



 Comments   
Comment by jahutton [ 09/Jun/15 ]

Maybe a solution to this would allow an option to disable the reference implementation requirement to have all plugins acknowledged. This would preserve existing behavior in case someone has a system where they want to require this.





[JAXB-1074] Jaxb generated corrupted XML(Intermittent) file during marshalling eventhough validated against XSD, but rerunning the job suceeded Created: 09/May/15  Updated: 21/May/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mayuran19 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Solaris 10, JDK 1.7,NFS file system



 Description   

We are having some issue with XML file generation using JAXB. Even though the marshalling is successfully completed the generated XML file is corrupted sometimes(Everyday we generate around 200 xml files each is 150MB in size, so far only 2 files are corrupted in two months).

There were no errors reported in the log file(catalina.out) even though we log each exceptions.

But when we rerun the job, the files are generated successfully.

The marshaller is used by multiple threads at the same time, we have already checked the spring code that for every call of marshall, spring create new marshaller object. So we ruled out the concurrency issue.

private void write(Object obj, XmlOutput out, Runnable postInitAction) throws JAXBException {
try {
if( obj == null )
throw new IllegalArgumentException(Messages.NOT_MARSHALLABLE.format());

if( schema!=null ) {
// send the output to the validator as well
ValidatorHandler validator = schema.newValidatorHandler();
validator.setErrorHandler(new FatalAdapter(serializer));
// work around a bug in JAXP validator in Tiger
XMLFilterImpl f = new XMLFilterImpl() {
@Override
public void startPrefixMapping(String prefix, String uri) throws SAXException

{ super.startPrefixMapping(prefix.intern(), uri.intern()); }

};
f.setContentHandler(validator);
out = new ForkXmlOutput( new SAXOutput(f) {
@Override
public void startDocument(XMLSerializer serializer, boolean fragment, int[] nsUriIndex2prefixIndex, NamespaceContextImpl nsContext) throws SAXException, IOException, XMLStreamException

{ super.startDocument(serializer, false, nsUriIndex2prefixIndex, nsContext); }

@Override
public void endDocument(boolean fragment) throws SAXException, IOException, XMLStreamException

{ super.endDocument(false); }

}, out );
}

try

{ prewrite(out,isFragment(),postInitAction); serializer.childAsRoot(obj); postwrite(); }

catch( SAXException e )

{ throw new MarshalException(e); } catch (IOException e) { throw new MarshalException(e); }

catch (XMLStreamException e)

{ throw new MarshalException(e); }

finally

{ serializer.close(); }

} finally

{ cleanUp(); }

}

private void cleanUp() {
if(toBeFlushed!=null)
try

{ toBeFlushed.flush(); }

catch (IOException e)

{ // ignore }
if(toBeClosed!=null)
try { toBeClosed.close(); } catch (IOException e) { // ignore }

toBeFlushed = null;
toBeClosed = null;
}

I don't understand why the ioexception is being ignored in the cleanup method.



 Comments   
Comment by Iaroslav Savytskyi [ 11/May/15 ]

Thanks for reporting.
I'll add logging there.

Comment by mayuran19 [ 11/May/15 ]

Hi laroslav savytskyi,
Thanks for your reply.

Is it possible to confirm that the said issue have real impact if NFS file system is not stable?
So that I can concentrate on work around for the issue.
Otherwise I need to continue the investigation in other areas such as concurrency.

Thanks,
Mayuran

Comment by Iaroslav Savytskyi [ 21/May/15 ]

Hi,

As you've said every marshaller is used by one thread. So it couldn't be concurrency issue.

My proposition is to patch given code with some logging and test it. To do this you will need to checkout standalone JAXB, patch, build and use.

GIT: git://java.net/jaxb~v2
Build: mvn clean install

Don't forget to put jaxb-api.jar to endorsed folder.

Comment by mayuran19 [ 21/May/15 ]

Hi,

Thanks for the update.
I will checkout and build.

Regards,
Mayuran





[JAXB-1073] jaxb:globalBindings optionalProperty="primitive" causes NullPointer in xjc Created: 08/May/15  Updated: 11/May/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vace117 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Apache Ant(TM) version 1.8.2 compiled on December 3 2011



 Description   
bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" version="2.1">

    <jaxb:globalBindings optionalProperty="primitive" />
</jaxb:bindings>
APPTransactionData.xsd
<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema	targetNamespace="http://www.agr.gc.ca/APP"
			xmlns:app="http://www.agr.gc.ca/APP"
			xmlns:xs="http://www.w3.org/2001/XMLSchema">

    
	<xs:complexType name="Shareholder_Type">
		<xs:sequence>
			<xs:element name="Controlling_Member" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
			<xs:element name="Producer_Reference_Id" type="app:Producer_Reference_Id_Type"/>
		</xs:sequence>	
	</xs:complexType>

	<xs:simpleType name="Producer_Reference_Id_Type">
		<xs:restriction base="xs:string" />
	</xs:simpleType>
	

</xs:schema>
build.xml
	<xjc 	destdir="${schema.source.dir}"
			schema="APPTransactionData.xsd"
			binding="bindings.xml"
			package="${schema.generated.package}">

My intent here is to force isControllingMember() method have a primitive boolean return type, as opposed to Boolean.

Running my Ant task causes this exception:

java.lang.NullPointerException
        at com.sun.codemodel.JVar.annotate(JVar.java:188)
        at com.sun.codemodel.TypedAnnotationWriter.create(TypedAnnotationWriter.java:247)
        at com.sun.codemodel.JVar.annotate2(JVar.java:192)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.getXew(AbstractField.java:354)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.writeXmlElementAnnotation(AbstractField.java:286)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.annotateElement(AbstractField.java:242)
        at com.sun.tools.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:157)
        at com.sun.tools.xjc.generator.bean.field.AbstractFieldWithVar.createField(AbstractFieldWithVar.java:79)
        at com.sun.tools.xjc.generator.bean.field.UnboxedField.<init>(UnboxedField.java:79)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at com.sun.tools.xjc.generator.bean.field.GenericFieldRenderer.generate(GenericFieldRenderer.java:69)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:777)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:558)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:261)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:169)
        at com.sun.tools.xjc.model.Model.generateCode(Model.java:288)
        at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:524)
        at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
        at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
        at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.Main.runBuild(Main.java:809)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

If I modify bindings.xml like this:

bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" version="2.1">
    
    <jaxb:globalBindings optionalProperty="primitive" generateIsSetMethod="false" />
</jaxb:bindings>

then my ShareholderType class gets successfully generated. Unfortunately, adding generateIsSetMethod attribute causes optionalProperty="primitive" not to work anymore for the boolean field (now the return type on isControllingMember() is Boolean), so this is not a workaround.



 Comments   
Comment by Iaroslav Savytskyi [ 11/May/15 ]

Thank you for reporting.
I've successfully reproduced the problem.





[JAXB-1072] Package level annotations don't work for inner classes Created: 20/Mar/15  Updated: 20/Mar/15

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tuomas_kiviaho Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

com.sun.tools.internal.jxc.ap.InlineAnnotationReaderImpl#getPackageAnnotation assumes that TypeElement#getEnclosingElement() returns always PackageElement but with inner classes the eclosing element will be a TypeElement.

As a fix I propose that Element#getKind() is inquired instead for ElementKind.CLASS|INTERFACE(|ENUM?) and TypeElement#getEnclosingElement() is repeated until ElementKind.PACKAGE is reached.

@Override
public <A extends Annotation> A getPackageAnnotation(Class<A> a, TypeElement clazz, Locatable srcPos) {
    Element enclosingElement = clazz;
    do {
        enclosingElement = enclosingElement.getEnclosingElement();
    } while (enclosingElement instanceof TypeElement);
    return LocatableAnnotation.create(enclosingElement.getAnnotation(a), srcPos);
}





[JAXB-1071] Support Plugin Customizations on All Schema Components Created: 11/Mar/15  Updated: 11/Mar/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: flutter Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JavaSE 1.7


Tags: customizations, plugin, xjc

 Description   

Currently, Plugin Customizations applied to a schema component that doesn't support a vendor Customization (like e.g. modelGroupDecl or attGroupDecl) will lead to an error message in XJC, since there is no way for the plugin to "markAsAcknowledged()" the plugin customization instance before it is consumed by the BGMBuilder's UnusedCustomizationChecker.
In the case of "group" or "attributeGroup" an additional complication is that these declarations are only processed in the context of the complexType that uses them rather than individually.

Improvement suggestion:

  • Handle "group" and "attributeGroup" declarations as first-class model elements instead of only through their usage.
  • Make all model elements based on schema components that support the "xs:annotation" element implement "Customizable", and hand any customization found down to the plugins for acknowledgement.





[JAXB-1070] Bad pom dependencies lead to java.lang.NoClassDefFoundError: com/sun/xml/bind/api/ErrorListener Created: 09/Mar/15  Updated: 13/Mar/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chengas123 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Running jaxb-xjc bombs out because there's no dependency declared on jaxb-core

More info here:
https://github.com/jacobono/gradle-jaxb-plugin/issues/15



 Comments   
Comment by Iaroslav Savytskyi [ 10/Mar/15 ]

It's not clear where is the problem.

From poms I see that:
org.glassfish.jaxb:jaxb-xjc has dependency on org.glassfish.jaxb:jaxb-core
com.sun.xml.bind:jaxb-xjc depends on org.glassfish.jaxb:jaxb-xjc

Comment by chengas123 [ 10/Mar/15 ]

Iaroslav, there's no dependency on com.sun.xml.bind:jaxb-core though.

Also, com.sun.xml.bind:jaxb-xjc only optionally depends on org.glassfish.jaxb:jaxb-xjc, so it's not going to pull it in. I don't think it should even have an optional dependency though. An optional dependency is typically used if com.sun.xml.bind:jaxb-xjc had code referencing classes from org.glassfish.jaxb:jaxb-xjc because you wanted to provide some extra features for it or something, but didn't want to force everyone to pull that jar into their project since only some people would use it. However, in this case, there seems to be no reference at all to any classes in that jar even for optional functionality, so it'd be better to just remove that dependency entirely.

Most build systems can show the dependency graph. E.g. if you use gradle you can run "gradle dependencies"

Here's the dependency graph with 2.2.7:

runtime - Runtime classpath for source set 'main'.
--- com.sun.xml.bind:jaxb-xjc:2.2.7
--- com.sun.xml.bind:jaxb-core:2.2.7
+--- javax.xml.bind:jaxb-api:2.2.7
--- com.sun.istack:istack-commons-runtime:2.16

Here's the dependency graph with 2.2.11:

runtime - Runtime classpath for source set 'main'.
--- com.sun.xml.bind:jaxb-xjc:2.2.11

Comment by Iaroslav Savytskyi [ 13/Mar/15 ]

In the version 2.2.8 we fixed JAXB maven project. Because of this new groupId: org.glassfish.jaxb was introduced.
https://jaxb.java.net/nonav/2.2.11/docs/ch02.html#a-2-2-8

The old one 'com.sun.xml.bind' shouldn't be used. It exists only for building legacy jaxb-ri.zip bundle.

Here is current dependency tree for JAXB runtime:

[INFO] — maven-dependency-plugin:2.8:tree (default-cli) @ jaxb-runtime —
[INFO] org.glassfish.jaxb:jaxb-runtime:jar:2.2.12-SNAPSHOT
[INFO] +- org.glassfish.jaxb:jaxb-core:jar:2.2.12-SNAPSHOT:compile
[INFO] | +- javax.xml.bind:jaxb-api:jar:2.2.13-b150205.1422:compile
[INFO] | +- org.glassfish.jaxb:txw2:jar:2.2.12-SNAPSHOT:compile
[INFO] | - com.sun.istack:istack-commons-runtime:jar:2.21:compile
[INFO] +- org.jvnet.staxex:stax-ex:jar:1.7.7:compile
[INFO] +- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.13:compile
[INFO] - junit:junit:jar:4.11:test
[INFO] - org.hamcrest:hamcrest-core:jar:1.3:test





[JAXB-1069] prefix-mapping is not predictable Created: 06/Mar/15  Updated: 10/Mar/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mihxil Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you generate XML which includes other XML's, you might have a different default namespace in two different javax.xml.bind.annotation.XmlNs in package-info.

In the current implementation of com.sun.xml.bind.v2.runtime.JAXBContextImpl it is not predictable which of the two will win. Actually in java 7 I get other ones that in java 8.

I propose to change

                        xmlNsSet = new HashSet<XmlNs>();

in

                        xmlNsSet = new LinkedHashSet<XmlNs>();

(at line 327)

I think this will fix it. The set will be at insertion order, and we will not end up with 'ns3' for our current default namespace...



 Comments   
Comment by Iaroslav Savytskyi [ 10/Mar/15 ]

Can you please provide simple testcase to cover this issue?
Thanks.





[JAXB-1068] Remove mentions of RELAXNG from the documentation and the CLI help until it somehow works Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The xjc /? output prints the following out:

  -relaxng           :  treat input as RELAX NG (experimental,unsupported)
  -relaxng-compact   :  treat input as RELAX NG compact syntax (experimental,unsupported)

This is formulated similar to:

  -dtd               :  treat input as XML DTD (experimental,unsupported)
  -wsdl              :  treat input as WSDL and compile schemas inside it (experimental,unsupported)

As DTD and WSDL compilation do (more or less) work, I assumed, RELAXNG can be also works somehow.

This assumption costed be today 0.5 PT. I have tried to compile a minimal RELAXNG_COMPACT example and consequently encountered JAXB-1065, JAXB-1066 (which I worked around), and, finally JAXB-1067.

With these issue I can with confidence say that RELAXNG_COMPACT compilation simply does not work. This is different from just "unsupported" (which I would interpret as "we don't officially support this") or "experimental" (which I would interpret as "we haven't thoroughly tested it yet"). It just does not work, completely and probably for a long time already.

Therefore I would consider these command line options and the documentation to be misleading:

  -relaxng           :  treat input as RELAX NG (experimental,unsupported)
  -relaxng-compact   :  treat input as RELAX NG compact syntax (experimental,unsupported)

It costed me today a few hundred euros worth of time invested.

Please remove the command line options and correct the documentation in order not to mislead further users.

Thank you.






[JAXB-1067] XJC with RELAXNG_COMPACT generates classes without properties Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File georss.rnc    

 Description   

After workarounds for [jaxb-1065] and [jaxb-1066] I have managed to generated the classes. To my surprize, classes are empty:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "")
@XmlRootElement(name = "featureName")
public class FeatureName {


}





[JAXB-1066] XJC fails on RELAXNG_COMPACT with NPE Created: 26/Feb/15  Updated: 01/Feb/17

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

NPE:

java.lang.NullPointerException
	at com.sun.tools.xjc.reader.Ring.get(Ring.java:97)
	at com.sun.tools.xjc.model.CPropertyInfo.<init>(CPropertyInfo.java:124)
	at com.sun.tools.xjc.model.CElementPropertyInfo.<init>(CElementPropertyInfo.java:103)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onRepeated(ContentModelBinder.java:114)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onZeroOrMore(ContentModelBinder.java:103)
	at com.sun.tools.xjc.reader.relaxng.ContentModelBinder.onZeroOrMore(ContentModelBinder.java:70)
	at org.kohsuke.rngom.digested.DZeroOrMorePattern.accept(DZeroOrMorePattern.java:32)
	at org.kohsuke.rngom.digested.DPatternWalker.onContainer(DPatternWalker.java:42)
	at org.kohsuke.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:63)
	at org.kohsuke.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:27)
	at org.kohsuke.rngom.digested.DGroupPattern.accept(DGroupPattern.java:35)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.bindContentModel(RELAXNGCompiler.java:165)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.compile(RELAXNGCompiler.java:158)
	at com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.build(RELAXNGCompiler.java:123)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:607)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNGCompact(ModelLoader.java:595)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:166)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:50)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:40)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:1)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:488)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:311)
	at org.jvnet.jaxb2.maven2.test.RunXJC2Mojo.testExecute(RunXJC2Mojo.java:30)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

This is due to the Ring not being initialized correctly.

The com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler.build(DPattern, JCodeModel, Options) method should begin a ring and add model to it:


public static Model build(DPattern grammar, JCodeModel codeModel, Options opts )

{ RELAXNGCompiler compiler = new RELAXNGCompiler(grammar, codeModel, opts); // ... Ring.begin(); Ring.add(compiler.model); // ... compiler.compile(); // ... Ring.end(); // ... return compiler.model; }

 Comments   
Comment by choboticus [ 08/Feb/16 ]

Similar stack trace from the standalone xjc 2.2.8-b130911.1802:

$ xjc -cp jaxb-extra-osgi-2.2.7.jar -relaxng-compact registry.rnc 
parsing a schema...
Exception in thread "main" java.lang.NullPointerException
    at com.sun.tools.internal.xjc.reader.Ring.get(Ring.java:82)
    at com.sun.tools.internal.xjc.model.CPropertyInfo.<init>(CPropertyInfo.java:110)
    at com.sun.tools.internal.xjc.model.CSingleTypePropertyInfo.<init>(CSingleTypePropertyInfo.java:57)
    at com.sun.tools.internal.xjc.model.CAttributePropertyInfo.<init>(CAttributePropertyInfo.java:58)
    at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onAttribute(ContentModelBinder.java:119)
    at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onAttribute(ContentModelBinder.java:55)
    at com.sun.xml.internal.rngom.digested.DAttributePattern.accept(DAttributePattern.java:58)
    at com.sun.xml.internal.rngom.digested.DPatternWalker.onContainer(DPatternWalker.java:66)
    at com.sun.xml.internal.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:87)
    at com.sun.xml.internal.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:51)
    at com.sun.xml.internal.rngom.digested.DGroupPattern.accept(DGroupPattern.java:59)
    at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.bindContentModel(RELAXNGCompiler.java:150)
    at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.compile(RELAXNGCompiler.java:143)
    at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.build(RELAXNGCompiler.java:108)
    at com.sun.tools.internal.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:592)
    at com.sun.tools.internal.xjc.ModelLoader.loadRELAXNGCompact(ModelLoader.java:580)
    at com.sun.tools.internal.xjc.ModelLoader.load(ModelLoader.java:151)
    at com.sun.tools.internal.xjc.ModelLoader.load(ModelLoader.java:104)
    at com.sun.tools.internal.xjc.Driver.run(Driver.java:318)
    at com.sun.tools.internal.xjc.Driver.run(Driver.java:185)
    at com.sun.tools.internal.xjc.Driver._main(Driver.java:108)
    at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:65)
    at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:88)
Comment by 5im0n [ 09/Feb/16 ]

The solution described above is not complete. For me this worked (com.sun.tools.xjc.reader.relaxng.RELAXNGCompiler):

public static Model build(DPattern grammar, JCodeModel codeModel, Options opts ) {
    RELAXNGCompiler compiler = new RELAXNGCompiler(grammar, codeModel, opts);
    Ring ring = Ring.begin();
    Ring.add(compiler.model);
    compiler.compile();
    Ring.end(ring);
    return compiler.model;
}
Comment by nicolas_rouquette [ 01/Feb/17 ]

The solution above involves accessing a private member; that's not directly usable by end-user code unless we use reflection.

Is there an end-user utility that could work properly?

I'd like to suggest a test case for OASIS' DocBook 5.x, which is a rewrite of the older DocBook schemas in RelaxNG: http://docbook.org/schemas/5x.html

http://docbook.org/schemas/5x.html

I tried it but it crashes on this issue:

xjc -version -classpath activation-1.1.1.jar:jaxb-extra-osgi-2.2.11.jar -d ../docbook.api/ -verbose -relaxng docbook.rng
xjc 2.2.8-b130911.1802

xjc -classpath activation-1.1.1.jar:jaxb-extra-osgi-2.2.11.jar -d ../docbook.api/ -verbose -relaxng docbook.rng
parsing a schema...
Exception in thread "main" java.lang.NullPointerException
	at com.sun.tools.internal.xjc.reader.Ring.get(Ring.java:82)
	at com.sun.tools.internal.xjc.model.CPropertyInfo.<init>(CPropertyInfo.java:110)
	at com.sun.tools.internal.xjc.model.CSingleTypePropertyInfo.<init>(CSingleTypePropertyInfo.java:57)
	at com.sun.tools.internal.xjc.model.CAttributePropertyInfo.<init>(CAttributePropertyInfo.java:58)
	at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onAttribute(ContentModelBinder.java:119)
	at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onAttribute(ContentModelBinder.java:55)
	at com.sun.xml.internal.rngom.digested.DAttributePattern.accept(DAttributePattern.java:58)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onRef(DPatternWalker.java:115)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onRef(DPatternWalker.java:51)
	at com.sun.xml.internal.rngom.digested.DRefPattern.accept(DRefPattern.java:77)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onUnary(DPatternWalker.java:131)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onOptional(DPatternWalker.java:111)
	at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onOptional(ContentModelBinder.java:82)
	at com.sun.tools.internal.xjc.reader.relaxng.ContentModelBinder.onOptional(ContentModelBinder.java:55)
	at com.sun.xml.internal.rngom.digested.DOptionalPattern.accept(DOptionalPattern.java:56)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onContainer(DPatternWalker.java:66)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onInterleave(DPatternWalker.java:91)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onInterleave(DPatternWalker.java:51)
	at com.sun.xml.internal.rngom.digested.DInterleavePattern.accept(DInterleavePattern.java:59)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onRef(DPatternWalker.java:115)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onRef(DPatternWalker.java:51)
	at com.sun.xml.internal.rngom.digested.DRefPattern.accept(DRefPattern.java:77)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onContainer(DPatternWalker.java:66)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:87)
	at com.sun.xml.internal.rngom.digested.DPatternWalker.onGroup(DPatternWalker.java:51)
	at com.sun.xml.internal.rngom.digested.DGroupPattern.accept(DGroupPattern.java:59)
	at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.bindContentModel(RELAXNGCompiler.java:150)
	at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.compile(RELAXNGCompiler.java:143)
	at com.sun.tools.internal.xjc.reader.relaxng.RELAXNGCompiler.build(RELAXNGCompiler.java:108)
	at com.sun.tools.internal.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:592)
	at com.sun.tools.internal.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:565)
	at com.sun.tools.internal.xjc.ModelLoader.load(ModelLoader.java:146)
	at com.sun.tools.internal.xjc.ModelLoader.load(ModelLoader.java:104)
	at com.sun.tools.internal.xjc.Driver.run(Driver.java:318)
	at com.sun.tools.internal.xjc.Driver.run(Driver.java:185)
	at com.sun.tools.internal.xjc.Driver._main(Driver.java:108)
	at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:65)
	at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:88)




[JAXB-1065] XJC fails on RELAXNG_COMPACT compilation with datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized Created: 26/Feb/15  Updated: 02/Jun/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File georss.rnc    

 Description   

When trying to compile the attached (or any) RNC file I get:

datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized

Possibly related to JAXB-128 and JAXB-465.

I believe a link to the datatype library is somehow broken.



 Comments   
Comment by lexi [ 26/Feb/15 ]

Java 1.5 workaround is obviously not an option.

Comment by lexi [ 26/Feb/15 ]

Tested with 2.2.11 via maven-jaxb2-plugin and 2.2.4-2 via command-line.

Comment by lexi [ 26/Feb/15 ]

Stack trace (unfortunately not too enlightning):

org.xml.sax.SAXParseException; systemId: file:/C:/Projects/workspaces/mj2p/maven-jaxb2-plugin-project/tests/rnc/src/main/resources/georss.rnc; lineNumber: 25; columnNumber: 45; datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized
	at org.kohsuke.rngom.binary.SchemaBuilderImpl.error(SchemaBuilderImpl.java:751)
	at org.kohsuke.rngom.binary.SchemaBuilderImpl.makeDataPatternBuilder(SchemaBuilderImpl.java:379)
	at org.kohsuke.rngom.parse.host.SchemaBuilderHost.makeDataPatternBuilder(SchemaBuilderHost.java:150)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.DataExpr(CompactSyntax.java:1856)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:947)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.ListExpr(CompactSyntax.java:1475)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:929)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.ElementExpr(CompactSyntax.java:1137)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.PrimaryExpr(CompactSyntax.java:917)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.AnnotatedPrimaryExpr(CompactSyntax.java:891)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.UnaryExpr(CompactSyntax.java:1079)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Expr(CompactSyntax.java:996)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Define(CompactSyntax.java:1618)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Definition(CompactSyntax.java:1590)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.GrammarComponent(CompactSyntax.java:1561)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.GrammarBody(CompactSyntax.java:1547)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.TopLevelGrammar(CompactSyntax.java:747)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.Input(CompactSyntax.java:442)
	at org.kohsuke.rngom.parse.compact.CompactSyntax.parse(CompactSyntax.java:135)
	at org.kohsuke.rngom.parse.compact.CompactParseable.parse(CompactParseable.java:55)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNG(ModelLoader.java:606)
	at com.sun.tools.xjc.ModelLoader.loadRELAXNGCompact(ModelLoader.java:595)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:166)
	at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:50)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:40)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:28)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:488)
	at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:311)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Comment by lexi [ 26/Feb/15 ]

This is most probably due to com.sun.msv.datatype.xsd.ngimpl.DataTypeLibraryImpl missing from the classpath.

Comment by lexi [ 26/Feb/15 ]

Ok, so how it seems, for RelaxNG to work on these schemas, it needs a datatype library for XML Schema.
This was a part of xsdlib or msv in the past and in modern days could only be found in com.sun.xml.bind:jaxb-extra-osgi.
Which exists in 2.2.11 version. But is somehow labelled for OSGi and is not under the new groupId.

Adding com.sun.xml.bind:jaxb-extra-osgi to the classpath solves this particular problem. The compilation still fails but for other reasons.

What is not clear to me is what is happening here. Why does RelaxNG Datatype library only appear in jaxb-extra-osgi? What does it have to do with OSGI at all? Why isn't it in the new group id? what are the plans here? I have a not so good feeling about this.

Comment by becke.ch [ 02/Jun/15 ]

I've the same issue:
OS:
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty

JDK: jdk-8u45-linux-x64.tar.gz

Running: /jdk1.8.0_45/bin/xjc -relaxng-compact datatypes.rnc
...
parsing a schema...
[ERROR] datatype library "http://www.w3.org/2001/XMLSchema-datatypes" not recognized
line 9 of file:/ws/app/becke-ch--edoc--s0-v1/eclipse/becke-ch--epub--s0-0-v1--core/src/main/resources/ch/becke/epub__s0_0_v1/core/structure/metainf/mod/datatypes.rnc
... etc.

And the rnc file can be found here: http://www.idpf.org/epub/301/schema/mod/datatypes.rnc





[JAXB-1064] The setters generated for the array fields cause NPE if the passed in array was null Created: 16/Jan/15  Updated: 13/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mystarrocks Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: xjc
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: jaxb, jaxb-xjc, xjc

 Description   
    public void setNames(String[] values) {
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }

Here's how XJC generates a setter if a collectionType of indexed was specified in the JAXB binding file. This throws an NPE if the values attribute was null. Especially for non-mandatory elements, this can very easily cause an NPE.

What's the reason for doing so? Does the JAXB spec require it this way? If not, perhaps changing the way the method is generated to include an appropriate null check can help avoid this? Maybe if it the passed in parameter was null, an empty array can be assigned to the field in question?

I looked at the JAXB spec and there is a mention for indexed fields that the argument should be discarded if it was null:

Page 58 of JAXB 2.2 spec

• setId(Type [])
The array setter method defines the property’s set value. If the
argument itself is null then the property’s set value, if any, is discarded.
If the argument is not null and....

I think this behavior can be observed in all the versions of jaxb-xjc, but the one my CXF client uses is 2.2.10 the CXF codegen plugin version being 3.0.2.

I'm OK with creating a pull request to get this fixed, if that's fine.



 Comments   
Comment by mystarrocks [ 01/Feb/15 ]

Any updates on this one? As it stands, the collectionType="indexed" is simply unusable.

Comment by Iaroslav Savytskyi [ 02/Feb/15 ]

I have to check. Now it looks like we are violating 2 rulers: getter returns empty array for null value and setter doesn't accept null argument. So array value couldn't be reset.

Even more. What we have to return in case if value is null and we are asked about it's length???

Comment by mystarrocks [ 03/Feb/15 ]

I don't think there's a need to change the getters or the length operations in any way. The getters should return the value as is, i.e null if null or the array if it was set previously using the setter; while the length should either return the length of the array or throw an NPE depending on if it was set previously or not.

The only requirement here is to comply with the spec for the setters for array fields by not setting explicitly if a null was passed as an argument.

Like:

    public void setNames(String[] values) {
      if (values == null) return; // simply ignore a null argument
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }
Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

I've reread specification more carefully (JAXB 2.2, section 5.5.2.1):

For getter: null should be returned instead of empty array in case if value wasn't set. Now user has no chance to determine if array was set without editing source class generated by XJC.

For setter: "If the argument itself is null then the property’s set value, if any, is discarded." -> previous value set to null.

Comment by mystarrocks [ 03/Feb/15 ]

I'm not quite sure about this statement:

Now user has no chance to determine if array was set without editing source class generated by XJC.

What's the rationale here? Why would the user want to know if the property was set or not? The user would merely call the getter to access the field whose value should be returned as:

  • null if it was not set previously or
  • the array if it was set previously.

Besides, the field will be null if it wasn't set anyway - b/c we don't initialize it with an array be default, do we?

Sorry if I'm missing something obvious, but I'm not understanding why this change to the setter will affect anything to the other invariants on the field. Can you please elaborate?

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

In my opinion, your proposition

if (values == null) return; // simply ignore a null argument

for setter, is against the specification. It's explicitly written that null argument for setter should reset already set value. So couldn't be ignored.

Comment by mystarrocks [ 03/Feb/15 ]

You're right,

if (values == null) return; // simply ignore a null argument

deviates from the spec. How about:

    public void setNames(String[] values) {
      if (values == null) {
          this.names = null; // discard the previously set value on the field per spec by setting the field to be null
          return;
      }
      int len = values.length;
      this.names = ((String[]) new String[len] );
      for (int i = 0; (i<len); i ++) {
          this.names[i] = values[i];
      }
    }

This complies with the spec by discarding the previously set value if the argument was null and do the usual thing otherwise. What the clients really expect here is null safety, so whatever variant of the above code that can offer that should be good.

Comment by Iaroslav Savytskyi [ 05/Feb/15 ]

Thanks for reporting. Will be fixed.





[JAXB-1063] Add option to SchemaGen not to dump intermediary bytecode in output directory Created: 15/Jan/15  Updated: 15/Jan/15

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lennartj Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Abstract

The SchemaGenerator generates bytecode from which it creates XSDs. However, it also has the option to generate XSDs from annotated Java source code. We need a nifty option to place these (intermediary, generated) bytecode files in another directory than the generated XSDs. I would suggest

-bytecodeDirectory path or perhaps -bd path analogous to the current -d path for where generated XSDs are located. If the -bytecodeDirectory path option is not given, the intermediary bytecode files should be generated in the same locations as it is today.

Example

A short example might illustrate the reason here.

  1. Given a Maven project with an annotated Java class - say src/main/java/some/package/Foo.java - we want to use schemagen to generate an XSD.
  2. Both the compiled bytecode of the class above, and the generated XSD should go into the resulting JAR.
  3. Using some plugin, we instruct schemagen to generate the XSD from the annotated Java source file. The resulting command is something like {{schemagen -d target/generated-resources -episode target/generated-resources/META-INF/sun-jaxb.episode src/main/java/some/package/Foo.java }}

The effect of the schemagen operation above is that the scema1.xsd and the META-INF/sun-jaxb.episode files are added to the Maven build as resources - and therefore correctly copied into the resulting JAR.

However ... in the same directory resides a schemagen-compiled intermediary bytecode file some/package/Foo.class. This file should not be copied into the resulting JAR. In fact, it might be a problem that it even exists, since the actual compilation step by the maven-compiler-plugin or plain javac compiler may have a different suite of arguments than schemagen.

Consequence: required, complex cleanup operation

I now have to perform a complex and unnecessary cleanup, which I would like not to have do to:

  1. Figure out which files below the target/generated-resources/ directory are actually bytecode which originated from the schemagen compilation
  2. Remove only those bytecode files from the target/generated-resources/ directory but preserve the generated XSDs and episode files.

A better solution

The complex cleanup operation need not be done at all if schemagen could be fired with something like

schemagen -d target/generated-resources -episode target/generated-resources/META-INF/sun-jaxb.episode -bytecodeDirectory target/schemagen_work src/main/java/some/package/Foo.java

This would imply that I would stash the generated intermediary bytecode files in another directory than the target/generated-resources ... and hence no cleanup operation would be required.






[JAXB-1062] Behavior changed while setting collection property Created: 08/Jan/15  Updated: 08/Jan/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: roekoe Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When updating from 2.2.5 to 2.2.7 we noticed a small change in how collections (at least lists in our case) get initialized. Previously the setter received a fully initialized list. As of 2.2.7 the setter receives a semi initialized , which receives some or all (timing?) of its content after the property gets called.

I'll attach an simple code example when upgrading the pom jaxb-impl version from 2.2.6 to 2.2.7 the testcase fails.



 Comments   
Comment by roekoe [ 08/Jan/15 ]
import java.io.StringReader;
import java.io.StringWriter;
import java.io.Writer;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.xml.bind.JAXB;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;

import org.junit.Test;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.core.IsCollectionContaining.hasItems;
import static org.hamcrest.core.StringContains.containsString;


public class ClassWithCollectionPropertyTest {

    @Test
    public void testToXml() throws Exception {
        Root root = new Root();
        root.setList(Arrays.asList("hello", "world"));
        Writer writer = new StringWriter();
        JAXB.marshal(root, writer);

        assertThat(writer.toString(), containsString("<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n" +
            "<root>\n" +
            "    <list>hello</list>\n" +
            "    <list>world</list>\n" +
            "</root>"));
    }

    @Test
    public void testFromXml() throws Exception {
        String input = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n" +
            "<root>\n" +
            "    <list>hello</list>\n" +
            "    <list>world</list>\n" +
            "</root>";

        Root result = JAXB.unmarshal(new StringReader(input), Root.class);
        assertThat(result.getList(), hasItems("hello", "world"));
    }

    @XmlAccessorType(XmlAccessType.PROPERTY)
    public static class Root {

        private List<String> internal = new ArrayList<String>();

        public List<String> getList() {
            ArrayList<String> answer = new ArrayList<String>();
            answer.addAll(internal);
            return answer;
        }

        public void setList(List<String> list) {
            this.internal.addAll(list);
        }
    }
}
Comment by roekoe [ 08/Jan/15 ]
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>boeskol</groupId>
  <artifactId>jaxb</artifactId>
  <version>1.0-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>com.sun.xml.bind</groupId>
      <artifactId>jaxb-impl</artifactId>
      <!--<version>2.2.6</version>-->
      <version>2.2.7</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>




[JAXB-1061] The primitive char type is not correctly handled in the isSet method Created: 19/Dec/14  Updated: 19/Dec/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File schema.xsd    

 Description   

When generating code for the following char property, XJC generates incorrect isSetChar method. Schema fragment:

	<xs:complexType name="complexTypeWithChar">
		<xs:sequence>
			<xs:element name="char">
				<xs:annotation>
					<xs:appinfo>
						<jaxb:property>
							<jaxb:baseType name="char" />
						</jaxb:property>
					</xs:appinfo>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:minLength value="1"/>
						<xs:maxLength value="1"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>

Generates:

    @XmlElement(name = "char", type = String.class)
    protected char _char;

    public boolean isSetChar() {
        return (this._char!= null);
    }

Which does not compile.

Apparently, char is somehow not considered to be primitive.

I have attached a sample schema to reproduce this.



 Comments   
Comment by lexi [ 19/Dec/14 ]

I think the problem is here:

https://github.com/gf-metro/jaxb/blob/dae7d777e6d65728a08f840cc1aef4454f4f542f/jaxb-ri/xjc/src/main/java/com/sun/tools/xjc/model/CBuiltinLeafInfo.java#L310-L347

No builtin type for `char`. Mapped as `unsignedShort` here:

https://github.com/gf-metro/jaxb/blob/3461152ffe39baf32b8550d47d18d58cdbc139c5/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java#L266-L275





[JAXB-1060] Please release org.jvnet.staxex:stax-ex:1.7.7 to the central Maven repo Created: 16/Dec/14  Updated: 17/Dec/14  Resolved: 16/Dec/14

Status: Resolved
Project: jaxb
Component/s: None
Affects Version/s: 2.2.11
Fix Version/s: 2.1.11

Type: Bug Priority: Blocker
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

a user of the maven-jaxb2 plugin has reported the following issue:

https://github.com/highsource/maven-jaxb2-plugin/issues/28

In short, org.glassfish.jaxb:jaxb-runtime:2.2.11 depends on org.jvnet.staxex:stax-ex:1.7.7 which is not present in the central Maven repo (yet).

See:

http://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime/2.2.11

Shows stax-ex 1.7.7 as dependency. The latest is 1.7.6:

http://central.maven.org/maven2/org/jvnet/staxex/stax-ex/

Would you please deploy as soon as possible, this is a blocker.

Best wishes,
Alexey



 Comments   
Comment by Martin Grebac [ 16/Dec/14 ]

Should be resolved now.

Comment by lexi [ 17/Dec/14 ]

Now it's good:

http://central.maven.org/maven2/org/jvnet/staxex/stax-ex/1.7.7/

Thank you very much for the fast reaction.





[JAXB-1059] MixedExtendedComplexTypeBuilder should creates a property with a lowercase name Created: 14/Dec/14  Updated: 14/Dec/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The {{}} creates the dummy property as follows:

p = prop.createDummyExtendedMixedReferenceProperty("contentOverrideFor" + ct.getName(), ct, ts);

(Around line 99.)

This makes both "private" as well as "public" property names lowercase and results in getter names like:

public List<Object> getcontentOverrideForGenericMetaDataType() { ... }

Which is not correct.

Please correct it to:

p = prop.createDummyExtendedMixedReferenceProperty("ContentOverrideFor" + ct.getName(), ct, ts);





[JAXB-1058] NPE because of the DummyListField.$get Created: 13/Dec/14  Updated: 15/Dec/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Today I've spent a few hours hunting an NPE bug.

I was trying to add the generateMixedExtensions="true" feature to a working project and started getting an NPE:

Caused by: java.lang.NullPointerException
	at com.sun.codemodel.JInvocation.generate(JInvocation.java:176)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:363)
	at com.sun.codemodel.JInvocation.generate(JInvocation.java:185)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JAssignment.generate(JAssignment.java:65)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JAssignment.state(JAssignment.java:69)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JBlock.generateBody(JBlock.java:448)
	at com.sun.codemodel.JBlock.generate(JBlock.java:436)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JBlock.state(JBlock.java:464)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JBlock.generateBody(JBlock.java:448)
	at com.sun.codemodel.JBlock.generate(JBlock.java:436)
	at com.sun.codemodel.JFormatter.g(JFormatter.java:350)
	at com.sun.codemodel.JBlock.state(JBlock.java:464)
	at com.sun.codemodel.JFormatter.s(JFormatter.java:386)
	at com.sun.codemodel.JMethod.declare(JMethod.java:464)
	at com.sun.codemodel.JFormatter.d(JFormatter.java:376)
	at com.sun.codemodel.JDefinedClass.declareBody(JDefinedClass.java:832)
	at com.sun.codemodel.JDefinedClass.declare(JDefinedClass.java:803)
	at com.sun.codemodel.JFormatter.d(JFormatter.java:376)
	at com.sun.codemodel.JFormatter.write(JFormatter.java:406)
	at com.sun.codemodel.JPackage.build(JPackage.java:442)
	at com.sun.codemodel.JCodeModel.build(JCodeModel.java:311)
	at com.sun.codemodel.JCodeModel.build(JCodeModel.java:301)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.writeCode(XJC22Mojo.java:98)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:42)
	at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:28)

After some debugging I've found out that the NPE was thrown because the passed JMethod was null.

And that was because of the DummyListField.$get - a getter for the dummy list field. $get is a private field which is never initialized in the code, but used in the field accessor, for instance:

        public void toRawValue(JBlock block, JVar $var) {
            // [RESULT]
            // $<var>.addAll(bean.getLIST());
            // list.toArray( array );
            block.assign($var,JExpr._new(codeModel.ref(ArrayList.class).narrow(exposedType.boxify())).arg(
                $target.invoke($get)
            ));
        }

This leads to $target.invoke(...) with null and consequently to the NPE during code generation.

I think it was forgotten to initialize the $get field. Other list fields have something like:

        $get = writer.declareMethod(listT,"get"+prop.getName(true));
        writer.javadoc().append(prop.javadoc);
        JBlock block = $get.body();
        fixNullRef(block);  // avoid using an internal getter
        block._return(acc.ref(true));

I think this appeared here because the generateMixedExtensions="true" feature probably creates a dummy field. Should it be dummy, actually? Anyway, somehow with that feature a DummyListField is created and it has a bug.



 Comments   
Comment by lexi [ 15/Dec/14 ]

I've made a temporal fix in form of a plugin:

https://github.com/highsource/jaxb2-basics/blob/master/basic/src/main/java/org/jvnet/jaxb2_commons/plugin/fixjaxb1058/FixJAXB1058Plugin.java





[JAXB-1057] Maven BOM includes dependency missing in central Created: 20/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

Status: Resolved
Project: jaxb
Component/s: None
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anders Hammar Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

n/a



 Description   

The Maven BOM for 2.2.11 (https://repo1.maven.org/maven2/org/glassfish/jaxb/jaxb-bom/2.2.11/jaxb-bom-2.2.11.pom) specifies the jaxb-api dependency as version 2.2.12-b140109.1041. This artifact does not exist in central which causes problems to people using the BOM as intended.

As releases in central can't be changed this cannot be fixed other than a new (patch) version of the BOM is released.
But also, you should implement necessary steps to ensure this does not happen again. I would guess your current release process has access to other repositories than central (where this artifact did access), which is not good.



 Comments   
Comment by lennartj [ 20/Nov/14 ]

As a developer of the Codehaus JAXB plugin, I would be grateful for a stable BOM to imply complete dependencies.
In the meantime ... am I correct in assuming that the 2.2.11 API (and the 1.7.6 stax-ex) can be used with the rest of the 2.2.11 release of the artifacts?

Comment by Iaroslav Savytskyi [ 21/Nov/14 ]

Thanks for reporting.
Artifact was promoted. Not released. Now it's released.





[JAXB-1056] Generation of JAXBElement for Nillable and minOccurs="0" within XMLEmentRef Created: 17/Oct/14  Updated: 17/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lynchie Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the schema

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://xml.jaxb.test/test"
targetNamespace="http://xml.jaxb.test/test"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

<xsd:element name="Parent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NillOne" type="xsd:int" minOccurs="0" nillable="true"/>
<xsd:element ref="NillTwo" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="NillTwo" type="xsd:int" nillable="true"/>
</xsd:schema>

Running this xsd through xjc in 2.2.7 still generates XmlElement Refs with both nillable="true" and minOccurs="0" as a plain Integer and not a JAXBElement<Integer>

//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.7 
// See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
// Any modifications to this file will be lost upon recompilation of the source schema. 
// Generated on: 2014.09.10 at 12:30:20 PM BST 
//


package test.jaxb.xml.test;

import javax.xml.bind.JAXBElement;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlElementRef;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for anonymous complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * &lt;complexType>
 *   &lt;complexContent>
 *     &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       &lt;sequence>
 *         &lt;element name="NillOne" type="{http://www.w3.org/2001/XMLSchema}int" minOccurs="0"/>
 *         &lt;element ref="{http://xml.jaxb.test/test}NillTwo" minOccurs="0"/>
 *       &lt;/sequence>
 *     &lt;/restriction>
 *   &lt;/complexContent>
 * &lt;/complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nillOne",
    "nillTwo"
})
@XmlRootElement(name = "Parent")
public class Parent {

    @XmlElementRef(name = "NillOne", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillOne;
    @XmlElement(name = "NillTwo", nillable = true)
    protected Integer nillTwo;

    /**
     * Gets the value of the nillOne property.
     * 
     * @return
     *     possible object is
     *     {@link JAXBElement }{@code <}{@link Integer }{@code >}
     *     
     */
    public JAXBElement<Integer> getNillOne() {
        return nillOne;
    }

    /**
     * Sets the value of the nillOne property.
     * 
     * @param value
     *     allowed object is
     *     {@link JAXBElement }{@code <}{@link Integer }{@code >}
     *     
     */
    public void setNillOne(JAXBElement<Integer> value) {
        this.nillOne = value;
    }

    /**
     * Gets the value of the nillTwo property.
     * 
     * @return
     *     possible object is
     *     {@link Integer }
     *     
     */
    public Integer getNillTwo() {
        return nillTwo;
    }

    /**
     * Sets the value of the nillTwo property.
     * 
     * @param value
     *     allowed object is
     *     {@link Integer }
     *     
     */
    public void setNillTwo(Integer value) {
        this.nillTwo = value;
    }

}

This was related to JAXB-840 but it was supposed to be fixed but It appears to still occur

From looking at the code, there is a check in RawTypeSetBuilder$XmlTypeRef.canBeType() that does the following:

            // nillable and optional at the same time. needs an element wrapper to distinguish those
            // two states. But this is not a hard requirement.
            if(decl.isNillable() && parent.mul.isOptional())
                return RawTypeSet.Mode.CAN_BE_TYPEREF;

However, as the NillTwo is a ref inside the xsd, it is parsed using RawTypeSetBuilder$CElementInfoRef.canBeType() which doesn't have a similar check. If I add the code snippet above before the if(target.hasClass()) call it generates the correct java like below:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "nillOne",
    "nillTwo"
})
@XmlRootElement(name = "Parent")
public class Parent {

    @XmlElementRef(name = "NillOne", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillOne;
    @XmlElementRef(name = "NillTwo", namespace = "http://xml.jaxb.test/test", type = JAXBElement.class, required = false)
    protected JAXBElement<Integer> nillTwo;






[JAXB-1055] Code creating ClassLoader for ant tasks not working properly Created: 15/Oct/14  Updated: 16/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: miroslav.kos Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The implementation in com.sun.tools.xjc.ClassLoaderBuilder#createProtectiveClassLoader#createProtectiveClassLoader() seems not to work properly. It should load always the latest API version (without need to use endorsed mechanism), but it probably worked well only for jdk6.

            // what does this really find for jdk >= jdk7 ?
            URL apiUrl = cl.getResource("javax/xml/bind/JAXBPermission.class"); 
            if(apiUrl==null)
                throw new ClassNotFoundException("There's no JAXB 2.2 API in the classpath");

            cl = new URLClassLoader(new URL[]{ParallelWorldClassLoader.toJarUrl(apiUrl)},cl);

It has to be verified that it adds jaxb-api.jar, not rt.jar for jdk7+.



 Comments   
Comment by Iaroslav Savytskyi [ 15/Oct/14 ]

Hi Miran,

Do you have jaxb-api.jar within endorsed folder? I think it should be there.

Comment by miroslav.kos [ 16/Oct/14 ]

Well, my understanding is that this code is trying to load proper API version without using endorsed mechanism. If you use endorsed, you don't need this classloaders magic stuff.





[JAXB-1054] jaxb-impl and jaxb-xjc POMs are invalid Created: 14/Oct/14  Updated: 13/Dec/14  Resolved: 15/Oct/14

Status: Closed
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File console.log     Text File eclipse.log    

 Description   

I am getting the following warning:

10/14/14, 8:48:54 PM GMT+2: [WARN] The POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.xml.bind:jaxb-impl:2.2.11
[ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ 

10/14/14, 8:48:54 PM GMT+2: [WARN] The POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.xml.bind:jaxb-xjc:2.2.11
[ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ 

This is minor, not blocking anything.



 Comments   
Comment by Iaroslav Savytskyi [ 15/Oct/14 ]

Hi Lexi,

What I have to do to get this errors?

I've just tried to build the project with Maven 3... And I don't see those warnings.

Paths to tools.jar are specified within jaxb-parent pom:

        <profile>
            <id>default-tools.jar</id>
            <activation>
                <file>
                    <exists>${java.home}/../lib/tools.jar</exists>
                </file>
            </activation>
            <properties>
                <tools.jar>${java.home}/../lib/tools.jar</tools.jar>
            </properties>
        </profile>
        <profile>
            <id>default-tools.jar-mac</id>
            <activation>
                <file>
                    <exists>${java.home}/../Classes/classes.jar</exists>
                </file>
            </activation>
            <properties>
                <tools.jar>${java.home}/../Classes/classes.jar</tools.jar>
            </properties>
        </profile>
Comment by lexi [ 15/Oct/14 ]

Hm, this is weird.

When I run clean compilation of one of my projects in Eclipse, I get the following:

10/15/14, 11:42:46 PM GMT+2: [INFO] Creating new launch configuration
10/15/14, 11:42:58 PM GMT+2: [INFO] C:\Projects\workspaces\mj2p\maven-jaxb2-plugin-project\tests\JAXB-1044
10/15/14, 11:42:58 PM GMT+2: [INFO]  mvn  -B -X -e clean install
10/16/14, 12:09:07 AM GMT+2: [WARN] The POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.xml.bind:jaxb-impl:2.2.11
[ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ 

10/16/14, 12:09:07 AM GMT+2: [WARN] The POM for com.sun.xml.bind:jaxb-xjc:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.xml.bind:jaxb-xjc:2.2.11
[ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ 

10/16/14, 12:09:07 AM GMT+2: [WARN] The POM for com.sun.xml.bind:jaxb-core:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for com.sun.xml.bind:jaxb-core:2.2.11
[ERROR] 'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} @ 

See the eclipse.log.

I don't see these messages in the console (see the console.log).

This must be somehow related to Eclipse. Your `pom.xml`s look fine.

I'll close it as not reproducible. I am sorry to have disturbed you for no reason.

Comment by lexi [ 15/Oct/14 ]

Asked on SO:

http://stackoverflow.com/questions/26393332/getting-the-pom-for-name-is-invalid-transitive-dependencies-if-any-will-no

Comment by Lukas Jungmann [ 20/Oct/14 ]

one thing I've noticed is that both profiles are defined as 'file exists', it would be perhaps better to have them defined in a way where exactly one of those profiles gets applied - ie one rule 'exists', the other 'not exists'

Comment by lexi [ 13/Dec/14 ]

After further investigation I've found out that I was running into this issue:

http://stackoverflow.com/questions/13288735/maven-not-picking-java-home-correctly

And this Eclipse bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=432992





[JAXB-1053] Use Java 7 diamond operator Created: 04/Oct/14  Updated: 15/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: donvip Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK7u67



 Description   

Using xjc bundled in latest JDK7 (7u67 right now), the generated code does not use Java 7 diamond operator.
This results in many warnings in Eclipse, see for example these discussions on StackOverflow:
http://stackoverflow.com/q/22314669/2257172
http://stackoverflow.com/q/19917257/2257172

We should be able to generate code that uses diamond operator, even by default or with a new command line option.



 Comments   
Comment by Iaroslav Savytskyi [ 09/Oct/14 ]

I agree.. This could be nice enhancement. But it have to be postponed until we have to support JDK6.





[JAXB-1052] Marshaller.marshall throws NPE if an adapter adapts a non-null bound type to null value of another type with single xmlValue annotation Created: 01/Oct/14  Updated: 01/Oct/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: coconnor Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is basically a very narrow corner-case of JAXB-415, but I thought it might be better to track it as a new bug. I actually discovered it in Scala, but was able to reproduce it with the following Java (which, I tested worked in MOXy - heresy I know).

Also, It doesn't occur if,
1) you add an attribute to Bar
2) you change the single xmlValue to be an xmlElement

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Foo {

@XmlElement
@XmlJavaTypeAdapter(TestAdapter.class)
private Optional<Bar> v;
public Foo()
{
}
public Foo(Optional<Bar> v)

{ this.v = v; }

public static void main(String[] args) throws Exception

{ Marshaller m = JAXBContext.newInstance(Bar.class, Foo.class).createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); m.marshal(new Foo(Optional.of(new Bar("foo"))), System.out); }

}

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Bar {
@XmlValue
private String v;

public Bar() {
}

public Bar(String v)

{ this.v = v; }

}

public class TestAdapter extends XmlAdapter<Bar,Optional<Bar>>
{
public Optional<Bar> unmarshal(Bar v) throws Exception

{ return null; }

public Bar marshal(Optional<Bar> v) throws Exception

{ return null; }

}



 Comments   
Comment by coconnor [ 01/Oct/14 ]

I used,
guava = "com.google.guava" % "guava" % "18.0"

It might also work if you adapt from completely separate type, but it seemed appropriate to demonstrate the utility I am deriving from this use-case.

Comment by coconnor [ 01/Oct/14 ]

And this is the stacktrace:

Exception in thread "main" java.lang.NullPointerException
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:54)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:379)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.get(Accessor.java:266)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.getUnadapted(Accessor.java:143)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.hasValue(TransducedAccessor.java:251)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl$TransducerImpl.writeLeafElement(RuntimeClassInfoImpl.java:409)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:256)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:130)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:361)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:342)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
at org.caoilte.atomizer.model.Foo.main(Foo.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)





[JAXB-1051] JAXB RI does not implement §5.5.4 of JAXB 2.2 specification Created: 30/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

Status: Closed
Project: jaxb
Component/s: runtime, spec
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Florian Schoppmann Assignee: Iaroslav Savytskyi
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

§5.5.4 ("isSet Property Modifier") of the JAXB 2.2 specification is not implemented in the JAXB reference implementation. (It is also not implemented in EclipseLink MOXy, though MOXy has an XmlIsSetNullPolicy annotation).

Example:

public class XMLTest {
    @XmlRootElement
    public static final class Foo {
        private final ArrayList<Bar> bars = new ArrayList<>();

        @XmlElementWrapper(name = "bars")
        @XmlElement(name = "bar")
        public List<Bar> getBars() {
            return bars;
        }

        public boolean isSetBars() {
            System.out.println("isSetBars() called!");
            return !bars.isEmpty();
        }

        public void unsetBars() {
            System.out.println("unsetBars() called!");
            bars.clear();
        }
    }

    public static class Bar {
        @XmlElement
        private String name;
    }

    @Test
    public void jaxbTest() throws Exception {
        JAXBContext jaxbContext = JAXBContext.newInstance(Foo.class);
        Marshaller marshaller = jaxbContext.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.marshal(new Foo(), System.out);
    }
}

The above code outputs

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<foo>
    <bars/>
</foo>

but something of the following form would be expected according the the spec:

isSetBars() called!
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<foo/>

Without §5.5.4 it is impossible to distinguish between set and unset list properties in a portable way.



 Comments   
Comment by Florian Schoppmann [ 30/Sep/14 ]

This issue is also related to JAXB-948.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

There is no need for JAXB to call "isSet" method. We have empty list. So we are marshalling it as <bars/>
So if you don't want to see it in the output - set bars to null.

Comment by Florian Schoppmann [ 30/Sep/14 ]

I don't follow that argument for several reasons:

  1. Settings bars to null is not a portable option. For "list properties", the JAXB specification only expects a getter, no setter. Hence, there is no standard way to set a list to null.
  2. There is nothing in §5.5.4 that makes calling isSet property modifiers optional (assuming the modifier exists).
  3. As JAXB-948 demonstrates, disobeying the specs has caused incompatibilities. Why should ignoring the specs be "works as designed"?
Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

1) good catch But specification doesn't forbid you to add setter for the list.
2) If you are going XJC way and you want to work with nulls -> use generateIsSetMethod or optionalProperty
In this case for:

<element name="bars" type="string" maxOccurs="unbounded"/>

XJC will generate for you something like:

Foo.java
   @XmlElement(required = true)
   protected List<String> bars;

   public List<String> getBars() {
        if (bars == null) {
            bars = new ArrayList<String>();
        }
        return this.bars;
    }

    public boolean isSetBars() {
        return ((this.bars!= null)&&(!this.bars.isEmpty()));
    }

    public void unsetBars() {
        this.bars = null;
    }

3) the main idea behind "isSet" methods is to allow user after UNMARSHALLING to know if xml HAS that value or not. (By the way, user has to call "isSet" before trying to get data from the collection.)

That's why there is no need for JAXB runtime to check that values during MARSHALLING. It's on the user to set something there or not.

4) JAXB-948 was fixed. There is no incompatibilities any more. If users specifies setter for the collection and add there additional logic. It's up to him. And JAXB "works as designed" in this case.

The only thing we can improve here is to try to call collection's setter AFTER the it's filled with values. But sure such way has it's disadvantages.

Comment by Florian Schoppmann [ 30/Sep/14 ]

I see. Chapter 5 of the specification is basically only concerned with the direction XML Schema -> Java, and the output of XJC is not normative. That indeed answers 1) - 3). Thanks!

Regarding 4), however, I am still wondering whether the current implementation legitimately breaks the code in my comment to INCK-948 (that code worked fine with JDK 7, and it also works fine with EclipseLink MOXy). Unless that code is in violation of the specs (which I currently fail to see), I think JAXB-948 was not really fixed and should be reopened.





[JAXB-1050] Wrong package test.t1 in txw2 Created: 28/Sep/14  Updated: 28/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Java files in txw2/src/test/java say they're in test.t1 whereas they are in t1.



 Comments   
Comment by lexi [ 28/Sep/14 ]

PR: https://github.com/gf-metro/jaxb/pull/5





[JAXB-1049] com.sun.tools.xjc.model.Aspect is missing in XJC Created: 28/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

Status: Closed
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mvn.log    

 Description   

com.sun.tools.xjc.model.Aspect is probably missing in XJC. Please see the compilation log.



 Comments   
Comment by lexi [ 28/Sep/14 ]

Please see the PR:
https://github.com/gf-metro/jaxb/pull/4

OCA is signed:

http://www.oracle.com/technetwork/community/oca-486395.html#v (Aleksei Valikov)

Comment by Iaroslav Savytskyi [ 29/Sep/14 ]

I know .. It was bad merging Instead of move it just delete and recreated file.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

Fixed within 2.2.11-b140930





[JAXB-1048] com.sun.xsom:xsom:jar:20140513 is missing Created: 28/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

Status: Closed
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mvn.log    

 Description   

I'm trying to build the jaxb-ri forked in GitHub.

This is what I get for txwc2:

[ERROR] Failed to execute goal on project txwc2: Could not resolve dependencies
for project org.glassfish.jaxb:txwc2:jar:2.2.11-SNAPSHOT: Failure to find com.sun.xsom:xsom:jar:20140513 in https://maven.java.net/content/repositories/releases/ was cached in the local repository, resolution will not be reattempted until the update interval of releases.java.net has elapsed or updates are forced -> [Help 1]

I don't see this JAR in https://maven.java.net/content/repositories/releases/.

Maven log is attached.



 Comments   
Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

New xsom version 20140925 is released yesterday.





[JAXB-1047] SCD bindings do not support custom/vendor customization elements Created: 28/Sep/14  Updated: 28/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I wrote a number of XJC plugins, some of these plugins can be customized via binding files.

For instance, I can do the following:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings schemaLocation="w3c/1999/xlink.xsd" node="/xs:schema">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

If my Jsonix plugin is activated, XJC will know that jsonix:packageMapping is a customization element for Jsonix (plugin API allows saying what your customization namespace URI is and which local names you expect).

SCD seems to be a more advanced way to address schema elements. I.e.

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink" ... />

addresses the XLink schema logically via namespace URI. Forget the files, this is perfect. Much more versatile than schemaLocation and node. I guess episodes would not work without SCD in first place. For my scenarios it would for instance help with JAXB-1047.

My problem is that SCD does not allow custom elements. So this:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

I get the following error:

[ERROR] Error while parsing schema(s).Location [ file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb{8,89}].
org.xml.sax.SAXParseException; systemId: file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb; lineNumber: 8; columnNumber: 89; cvc-elt.1: Cannot find the declaration of element 'jsonix:packageMapping'.

Clearly, SCD does not process custom configuration elements whereas schemaLocation plus node do process.






[JAXB-1046] Catalog-resolved schema is not considered to be a part of compilation Created: 28/Sep/14  Updated: 02/Oct/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive cd.zip    

 Description   

Please see the cd.zip.

Assume http://www.ab.org/d.xsd is rewritten to ab/d.xsd via catalog:

REWRITE_SYSTEM "http://www.ab.org" "ab"

I want to customize the d.xsd so I do the following in the binding file:

	<jaxb:bindings schemaLocation="ab/d.xsd" 
		node="/xs:schema">
		<jaxb:schemaBindings>
			<jaxb:package name="org.ab.d"/>
		</jaxb:schemaBindings>
	</jaxb:bindings>

I get the following error message:

[ERROR] "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/d.xsd" is not a part of this compilation. Is this a mistake for "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/c.xsd"?
  line 13 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/cd.xjb

I would argue that ab/c.xsd is definitely a part of the compilation - even if resolved via catalog. Otherwise I'm forced to write the absolute URL in the binding's schemaLocation which is ugly.

This is also important because this issue prohibits reusage of binding files. Please let me explain.

Assume we habe two schemas a.xsd and b.xsd, b.xsd imports a.xsd via absolute URL http://www.ab.org/a.xsd.

We want to compile a.xsd in one compilation and b.xsd plus b.xsd in another.

Due to JAXB-1044 we can't compile http://www.ab.org/a.xsd directly (i.e. xjc http://www.ab.org/a.xsd -catalog a.cat).
Even when using a catalog, XJC still tries to download the file. So we have to compile the local copy xjc a.xsd. If we want to use a binding file to customize compilation, we have to write schemaLocation="a.xsd" in the binding file. Ok, all of this is more or less fine.

Now we want to compile b.xsd which imports http://www.ab.org/a.xsd. Now, it would be cool to reuse the binding file from the first compilation. But that binding file says schemaLocation="a.xsd" bit our second compilation needs schemaLocation="http://www.ab.org/a.xsd". Dead end. We have to write another a.xjb with the only difference being relative vs. absolute URL.

One solution would have been to compile http://www.ab.org/a.xsd instead of a.xsd in the first compilation. But as I pointed, this does not work due to JAXB-1044.

FYI I am perfectly aware of features like SCD and episodes. However there are scenarios, where SCD and episodes are not suitable or don't work as desired. For instance, SCD/episodes do not handle vendor customization elements at the moment.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in https://github.com/gf-metro/jaxb/pull/7 (see the DOMForest).

When resolving URIs, add BOTH the original URI as well as the resolved URI to the id/documents map - with the same document, of course.





[JAXB-1045] "Item" is already defined error with catalogs, bindings and mixed absolute and relative URLs Created: 28/Sep/14  Updated: 02/Oct/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive cd.zip     Zip Archive gml-v_3_1_1.zip    

 Description   

This is somewhat complex setup, please take a look at the prepared example (attached) first.

I am trying to do a clean compilation of the GML 3.1.1 schema using catalogs and binding files.

I've created local copies of files in the w3c and ogc folders and rewrite URLs using the following catalog file:

REWRITE_SYSTEM "http://www.w3.org" "w3c"
REWRITE_SYSTEM "http://schemas.opengis.net" "ogc"

In the GML schema there is one schema which imports SMIL via the absolute URL:

defaultStyle.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd"/>

My understanding is that http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd will be resolved to ogc/gml/3.1.1/smil/smil20.xsd via catalog.

The smil20.xsd imports smil20-language.xsd via relative URL:

smil20.xsd
<import namespace="http://www.w3.org/2001/SMIL20/Language" schemaLocation="smil20-language.xsd"/>

The smil20-language.xsd imports the smil20.xsd also via relative URL:

smil20-language.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="smil20.xsd"/>

When I try to compile this I get the following stream of errors:

[ERROR] 'structureModuleAttrs' is already defined
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 37 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'skipContentAttrs' is already defined
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'alternateContentAttrs' is already defined
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'nonNegativeDecimalType' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animate' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animatePrototype' is already defined
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 67 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animNamedTargetAttrs' is already defined
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animAddAccumAttrs' is already defined
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animValuesAttrs' is already defined
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animSetValuesAttrs' is already defined
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animTargetAttrs' is already defined
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animModeAttrs' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotion' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotionPrototype' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 126 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColor' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColorPrototype' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 132 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'set' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'setPrototype' is already defined
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 138 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorAttrs' is already defined
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorType' is already defined
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultAttrs' is already defined
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultType' is already defined
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingAttrs' is already defined
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingType' is already defined
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultAttrs' is already defined
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultType' is already defined
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrs' is already defined
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrsType' is already defined
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultAttrs' is already defined
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultType' is already defined
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'beginEndTimingAttrs' is already defined
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'durTimingAttrs' is already defined
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'repeatTimingAttrs' is already defined
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'deprecatedRepeatTiming' is already defined
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'minMaxTimingAttrs' is already defined
  line 235 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

Failed to parse a schema.

Note that XJC complains about the identical URLs, also references the same lines (however in a wrong order which is a bit weird).

If I change both of the relative URLs in the SMIL schemas to absolute URLs, it does work. Of course, I don't want this workaround as I don't want to patch external schemas.

I've also reproduced it on a "reduced" test case with simple schemas (see the cd.zip attachment).

The problem arises only if bindings files are used. When compiling without bindings, it works (see success.bat and failure.bat in cd.zip). failure.bat gives the following error trace:

[ERROR] 'd' is already defined
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] 'DType' is already defined
  line 16 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 10 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

Failed to parse a schema.

Lines are quite interesting. The element 'd' is reported two times on the same line. The type 'DType' is reported two times - one on the opening <complexType ...> tag of the type and once on the closing </schema> tag:

01<?xml version="1.0" encoding="UTF-8"?>
02<schema 
03	xmlns="http://www.w3.org/2001/XMLSchema"
04	targetNamespace="urn:d" elementFormDefault="qualified"
05	xmlns:d="urn:d"
06	xmlns:e="urn:e">
07
08	<import namespace="urn:e" schemaLocation="e.xsd"/>
09	<element name="d" type="d:DType"/>
10	<complexType name="DType">
11		<sequence>
12			<element name="s" type="string"/>
13			<element name="e" type="e:EType"/>
14		</sequence>
15	</complexType>
16</schema>

My guess is that the graph:

  • schema 1 -(absolute URL)-> schema 2
  • schema 2 -(relative URL)-> schema 3
  • schema 3 -(relative URL)-> schema 2

somehow causes problems with schema 2. I think the problem might be different paths to schema 2. The URLs are finally rewritten via catalog to the same URL but the same document gets parsed two times.

This is quite a showstopper for me at the moment. I am forced to patch schemas on a very big scale, which is extremely ugly.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in the https://github.com/gf-metro/jaxb/pull/7

The problem here is that when the entity resolver resolves some systemId, you get an input source with the stream AND a resolved systemId. Subsequent resolutions (when you for instance have an import or an include) will use this resolved system id. This may result in some schemas addressed by an unresolved and by a resolved system id - despite being placed in the same local source.

The fix is simple: when resolving, only provide the stream and don't change the system id (or public id) of the input source. This still works well - parsers take XML from the stream. And this corrects the problem since system id does not change.


I understand that we're talking customer-facing interface here so you probably have to carefully consider if you apply the fixes or not. I am persuaded that what I propose is the correct behaviour, so I will want to fix it anyway (in maven-jaxb2-plugin, at least). I think I can make workarounds via the entity resolver for JAXB-1044 and JAXB-1045 as it is basically the entity resolver logic which is changed here.
What I can't do is JAXB-1046 since it addresses the interna of the DOMForest which is not accessible. But I think this fix is not dangerous at all.

Please let me know what you think of the fixes and if we can work them into the XJC release.





[JAXB-1044] Catalog is not used to resolve the schema URL provided as an argument to XJC Created: 28/Sep/14  Updated: 07/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive a.zip    

 Description   

I am compiling schemas from public schema repositories, available online.

However, I don't want builds to download these schemas in first place, instead I want them to work with local copies, "redirected" by catalogs.

I have found out that catalogs seem to be not applied to the URL arguments directly passed to XJC.

Please see the attached test case:

xjc a.xsd

works of course.

However assume I want to compile http://www.ab.org/a.xsd directly. This is a legal use case.
But I don't want a.xsd to be downloaded from http://www.ab.org. So I provide a catalog:

REWRITE_SYSTEM "http://www.ab.org" "."

But this catalog does not seem to be applied to the URL I provide as a command-line argument. This fails:

xjc http://www.ab.org/a.xsd -catalog catalog.cat

Fails is a sense that XJC still tries to download a.xsd from http://www.ab.org.

At the same time, if http://www.ab.org/a.xsd would have been included in another schema, this would have worked.



 Comments   
Comment by Iaroslav Savytskyi [ 07/Oct/14 ]

Hi Aleksei,

To be honest, it's clear what are you trying to do, but does it makes sense?

Why will somebody call xjc with

xjc http://www.ab.org/a.xsd -catalog catalog.cat

if he already has a.xsd on his local?

Comment by lexi [ 07/Oct/14 ]

It does make sense. Please also see JAXB-1046, it explains the issue in detail.

Assume we have http://www.ab.org/a.xsd which imports b.xsd relatively. And b.xsd imports a.xsd via an absolute URL: http://www.ab.org/a.xsd.

Which schemas will be compiled if we just compile the local copy of a.xsd? The answer is:

So this is one of the reasons people get "MyType is already defined" (see JAXB-1045). You basically get the same schema (i.e. the same local copy) included via two different systemIds. An that's the problem.

This is not just theory. I work with W3C, OGC, and OASIS schemas and they do this all the time. Some schemas import other schemas relatively, some via absolute URLs. An I have spent days trying to compile these schemas, fighting "MyType is already defined" and "my.xsd is not part of this compilation" errors all the way.

Finally I came to the conclusion that I should not mix compiling local copies and absolute URLs with catalogs. I should compile EVERYTHING uniformely. And since absolute URLs are in play, this should be absolute URLs with catalogs.

I have actually already implemented the workaround for JAXB-1044 in the maven-jaxb2-plugin. It now resolves URLs before passing to XJC. Any you know what? It works just splendid. Take a look at this project:

https://github.com/highsource/w3c-schemas

This works way better than anything I've managed to get working in the past. Actually, the combination of JAXB-1044, JAXB-1045 and JAXB-1046 actually forced me to patch local copies of schemas so that they always use relative URLs. It just did not work the other way round.

If you're still in doubt if this makes sense, try to compile this schema from local copies without patching it:

http://schemas.opengis.net/gml/3.1.1/base/gmlBase.xsd

You will run exactly in the problem I describe above. GML uses SMIL schemas, importing them via absolute URLs. SMIL Schemas, however, import each other via relative URLs. Kaboom.

As I said, I've implemented a workaround in the maven-jaxb2-plugin, but I still would like to get it fixed in the core XJC because I have a few projects which use the command-line XJC and I really won't like to start dancing aroud command-line tools as well.





[JAXB-1043] Content of collection properties lost during Unmarshalling Created: 26/Sep/14  Updated: 30/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: killerchamb Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Bug occurs on version 2.2.10-b140310.1920



 Description   

Recent versions of JAXB handle collection properties differently than before. An empty collection is created at the beginning, and set into the target bean, and then elements are added to the collection, without any interaction with the bean.

So if the bean for instance makes a private copy of the collection when the setter is called, the content of the collection is lost. See the unit test below.

Issue occurs with version 2.2.10-b140310.1920


package test.serialization.jaxb;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;

import java.io.StringReader;
import java.io.StringWriter;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.annotation.XmlRootElement;

import org.junit.Test;

@XmlRootElement
public class A {

	protected List<String> list;

	public List<String> getList() {
		return list;
	}

	public void setList(List<String> list) {
		// Store the list content in a private copy
		this.list = new ArrayList<>(list);
	}

	@Test
	public void test() throws Exception {
		A a = new A();
		a.setList(Arrays.asList("something"));
		
		JAXBContext ctx = JAXBContext.newInstance(A.class);

		StringWriter writer = new StringWriter();
		
		ctx.createMarshaller().marshal(a, writer);
		
		String text = writer.toString();
		System.out.println(text);
		
		A a2 = (A) ctx.createUnmarshaller().unmarshal(new StringReader(text));
		assertNotNull(a2.getList());
		assertEquals(1, a2.getList().size());
		assertEquals("something", a2.getList().get(0));
	}
	
}



 Comments   
Comment by laune [ 26/Sep/14 ]

Consider;
class A1

{ protected List<String> list = new ArrayList<>(); //... }

works, as does
class A2 {
//...
public void setList(List<String> list)

{ this.list = list; }

//...
}
With class A as shown, the client must provide the implementation for List<String>, apparently leaving it up to him whether it's going to be a LinkedList, an ArrayList or whaterver. But that object isn't returned!

Which, after all, would make a client write code like
a.setList( new ArrayList<String>() );
for(String s: ..)

{ ;a.setList( a.getList().add() ); }

because it isn't guaranteed that what you set is what you get; resulting in a markedly inefficient code.

It may be regrettable that JAXB'S behaviour has changed, but I wouldn't expect it to work with a class according to the pattern of class A.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

Hi @killerchamb,

Why do you think this is a bug?

In any case you can clone the collection after unmarshalling, right?

I'm going to close this as 'Not a bug'

Comment by killerchamb [ 30/Sep/14 ]

Hi, and thank you for looking at this.

I agree that the new behaviour is not a bug, not more than the previous behaviour at least. It's just that it does not work in a few more cases than before, when the getter/setter methods of a class modify the data. When you can alter the source code of the serialized classes it is very easy to fix, when you cannot it blocks you.

I let you close the ticket, at least there will be a trace of the discussion.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

The only thing I can imagine is, that we can set already populated collection.
I'll give a try.

Thanks for reporting.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

@me -> https://java.net/jira/browse/JAXB-948





[JAXB-1042] Javadoc compilation errors with JDK8 Created: 22/Sep/14  Updated: 26/Sep/14  Resolved: 26/Sep/14

Status: Resolved
Project: jaxb
Component/s: docs
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: petros.splinakis Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Javadoc compilation fails with errors when ran using JDK8.



 Comments   
Comment by Lukas Jungmann [ 26/Sep/14 ]

should be already fixed in current master





[JAXB-1041] inheritence & XmlRootElement Created: 19/Sep/14  Updated: 20/Sep/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: diorcety Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If B class extends the class A, both annotate with XmlType, and C class annotate with XmlType & XmlRootElement, C contains a field of type A.

The Xml can looks like that
<C>
<A xsi:type="B"/>
</C>
.
Now if A is a XmlRootElement the Xml could looks like that
<A xsi:type="B"/>

Currently, jaxb is not able to marshall that (B class doesn't have XmlRootElement annotation),
but is able to unmarshall that.



 Comments   
Comment by laune [ 20/Sep/14 ]

This works according to the specification.

It isn't possible to marshal an element that isn't annotated with XmlRootElement, which is the way the marshaller learns about the local name and the namespace of the root element.

It would be possible to create a JAXBElement and marshal this - see the JAvadoc.

This issue should be closed.

Comment by diorcety [ 20/Sep/14 ]

Ok i didn't know that was a specification restriction. This mean that jaxb can unmarshall that without any trick, but can't marshall without using JAXBElement.

Comment by laune [ 20/Sep/14 ]

It's more a consequence of: "If there is no information about an XML element's name and namespace: how can you create (i.e. marshal) it`?" It's a gap that can't be filled even if the spec's authors would have wanted to.

Comment by diorcety [ 20/Sep/14 ]

According to this post http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-xsitype.html?showComment=1354657419516#c7344877388280882872, this is the behaviour of Moxy





[JAXB-1040] JAnnotationUse causes NPE in getAnnotationMembers() Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If memberValues field is never added a parameter, then calling JAnnotationUse#getAnnotationMembers() causes NullPointerException. This is actual for annotations like `@XmlMixed`, which by definition don't have params.






[JAXB-1039] Call to JPackage.annotations() causes empty package-info.java to be generated Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Dmitry Katsubo Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently getter JPackage.annotations() is called, private field annotations is set to not-null value, causing empty {{package-info.java} to be generated.

The line JPackage.java:443

if(annotations!=null || jdoc!=null)

should be changed to:

if((annotations!=null && !annotations.isEmpty) || jdoc!=null)





[JAXB-1038] Allow the inject-code plugin to inject code into enums Created: 10/Sep/14  Updated: 03/Feb/15  Resolved: 03/Feb/15

Status: Resolved
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: 2.2.12

Type: Improvement Priority: Major
Reporter: kengelke Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
for (EnumOutline eo : model.getEnums()) {
            CPluginCustomization c =
eo.target.getCustomizations().find(Const.NS, "code");
            if (c == null) {
                continue;   // no customization --- nothing to inject
here
            }

            c.markAsAcknowledged();
            // TODO: ideally you should validate this DOM element to
make sure
            // that there's no typo/etc. JAXP 1.3 can do this very
easily.
            String codeFragment = DOMUtils.getElementText(c.element);

            // inject the specified code fragment into the
implementation class.
            eo.clazz.direct(codeFragment);
}


 Comments   
Comment by kengelke [ 05/Nov/14 ]

Any news on this issue? I was a bit sad to see it wasn't included in 2.2.11. It's such a small change. I have submitted the Contributor Agreement on September 10th. If there is anything that prevents this change from being merged please let me know.

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

Implemented in JAXB 2.2.12-SNAPSHOT





[JAXB-1037] Duplicate (after name mapping) field name causes IllegalArgumentException Created: 06/Sep/14  Updated: 08/Sep/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.8 (JDK 8)
Fix Version/s: None

Type: Bug Priority: Major
Reporter: laune Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux ubuntu 14.04, jdk1.8.0_20



 Description   

Actually, the xjc version identifies itself as
$ xjc -version
xjc 2.2.8-b130911.1802
But this funny bug tracker tells me that this version 2.2.8 doesn't exist! So how come it is delivered together with the official Java JDK 1.8.0_20???

Compile the XML Schema file below to see the error. Note that "xx" and "XX" cause the crash, whereas "xx" and "Xx" produce an error message (as would be expected in the other case as well).

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="what:ever"
elementFormDefault="qualified">

<xs:complexType name="Media">
<xs:sequence>
<xs:element name="id" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID"/>
</xs:complexType>

</xs:schema>



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

It's was my fault with versions. It's OK now. And I've updated the bug affected version.

Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

I think the bug is that we throw error in this case. ID and id generates different names for getters/setters. So there shouldn't be a problem. I'm going to refactor XJC code to use java.beans.Introspector.





[JAXB-1036] Jaxb cannot unmarshal files containing hash (#) in name. Created: 24/Aug/14  Updated: 08/Sep/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: michalborek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Jaxb Unmarshaller has unmarshal(File) method.

When passing a file that contains # in name (e.g. some#name.xml), the part of name after the hash is treated as URL anchor and is not recognized properly.

The problem is caused by improper implementation of this method, which internally uses unmarshal(URL) method invocation.



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

Confirming the bug.
Thanks for reporting.





[JAXB-1035] Locator is not set for elements without attributes Created: 19/Aug/14  Updated: 19/Aug/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: michalborek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A locator field, defined as follows:
@XmlType(name = "selector")
public class Selector

{ @XmlLocation @XmlTransient public Locator locator; @XmlValue public String value; }

is ignored in classes, that are treated as leaves (in XML).

In effect, having node <selector>text</selector> we are unable to get line of <selector> xml node (locator is null).

When we add some dummy attribute to that class, locator is being set.

I've checked the source code and the problem is with the fact that when arbitrary node contains only text content, it is treated as Leaf, and there is no consideration whether there is Locator attribute defined or not.






[JAXB-1034] Add/respect non-proxy hosts settings Created: 29/Jul/14  Updated: 29/Jul/14

Status: Open
Project: jaxb
Component/s: maven-plugin
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Michael Osipov Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One can pass a HTTP proxy but not non-proxy hosts. If HTTP is retrieved from settings.xml, sub element nonProxyHosts is ignored but must be respected.

A patch can be provided.

This relates to JAX_WS-1154.



 Comments   
Comment by Michael Osipov [ 29/Jul/14 ]

This is actually crucial in a corporate environment.

Comment by Michael Osipov [ 29/Jul/14 ]

Please close, wrong project.





[JAXB-1033] disableXmlSecurity doesn't work properly Created: 17/Jul/14  Updated: 17/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: miroslav.kos Assignee: miroslav.kos
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

disableXmlSecurity doesn't work properly when Security Manager enabled:

javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING:
Cannot set the feature to false when security manager is present.
at com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:122)
at com.sun.xml.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:128)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:154)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)






[JAXB-1032] "Unique Particle Attribution" exception when choice is A,B or A+B Created: 03/Jul/14  Updated: 29/Dec/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tiou2 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I currently have a choice of either having 'field1' OR 'field2'. I need to make additionally possible having both 'field1' AND 'field2' as well. So the choice is to have either field1, field2 or both field1 and field2.

I have the following structure in an XSD:

<xsd:choice>
	<xsd:element name="field1" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:int"/>
		</xsd:simpleType>
	</xsd:element>
	<xsd:element name="field2" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string">
				<xsd:minLength value="1"/>
			</xsd:restriction>
		</xsd:simpleType>
	</xsd:element>
</xsd:choice>

Adding a sequence with both field1 and field2 causes the exception:

	(....)
		</xsd:element>
		<xsd:sequence>
			<xsd:element name="field1" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:int"/>
				</xsd:simpleType>
			</xsd:element>
			<xsd:element name="field2" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:string">
					<xsd:minLength value="1"/>
				</xsd:restriction>
			</xsd:simpleType>
		</xsd:element>
	</xsd:sequence>
</xsd:choice>

The exception I'm getting is:

[ERROR] Error while parsing schema(s).Location [ file:...removed...].
org.xml.sax.SAXParseException; systemId: ...removed...; lineNumber: X; columnNumber: Y; cos-nonambig: "ns1":field1 and "ns1":field1 (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)


 Comments   
Comment by Tiou2 [ 03/Jul/14 ]

A workaround is to add another field within the sequence, unfortunately it cannot be made optional:

	<xsd:choice>
		<xsd:element name="oid" type="xsd:int" nillable="false"/>
		<xsd:element name="klantnummer" type="xsd:string" nillable="false"/>
	</xsd:choice>
	<xsd:choice>
		<xsd:element name="field1" type="xsd:int" nillable="false"/>
		<xsd:element name="field2" type="xsd:string" nillable="false"/>
		<xsd:sequence>
			<xsd:element name="dont_use"/>
			<xsd:element name="field1" type="xsd:int" nillable="false"/>
			<xsd:element name="field2" type="xsd:string" nillable="false"/>
		</xsd:sequence>
	</xsd:choice>
Comment by lexi [ 15/Jul/14 ]

Moved to JAXB sind this is not a Maven plugin issue.





[JAXB-1031] JAXB 2.1.x generates errorneous episode File Created: 15/Jul/14  Updated: 03/Oct/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.14, 2.1.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lexi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File sun-jaxb.episode    

 Description   

A user has reported that JAXB-XJC version 2.1.14 generates a bad episode file due to the - string contained in the internal version (v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240-SNAPSHOT). When this version is printed out in the comment, this makes XML invalid.

This also makes JAXB-984 or JAXB-1003 blockers since 2.1.14 is not usable and 2.1.15 and above have invalid POMs.



 Comments   
Comment by lexi [ 15/Jul/14 ]

Attached a sample file.

Note the comment:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:36:41 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

Same problem with 2.1.16:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.16-hudson-jaxb-ri-2.1-pushtomaven-250--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:44:54 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

2.1.13 is not affected.

Comment by lexi [ 03/Oct/14 ]

This issue still persists in 2.1.17.





[JAXB-1030] Marshal/Unmarshal not symmetric for Strings with newline characters CR LF Created: 10/Jul/14  Updated: 06/Dec/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: barney2k7 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jaxb 2.2.4-2 in Oracle jdk 7u60



 Description   

We've recently discovered an issue with marshal/unmarshal operations not being symmetric for strings containing newline characters (CR, LF or CRLF) (i.e. the resulting string after a marshal/unmarshal cycle isn't what the original string was).
Since XML parsers must normalize attribute values by replacing newline characters with spaces (reference: http://www.w3.org/TR/REC-xml/#AVNormalize), newline characters need to be escaped properly, but there doesn't seem to be a 'standard' way to tell a Marshaller to do this. Interestingly, this is only an issue if a StreamResult is used. If a DOMResult plus a Transformer is used, newline characters are actually escaped properly.
I'll attach a test case, which shows both ways to do this, with only 'testDomAndTransform' working properly so far.

Note that a very similar issue (JAXB-449) has been filed in the past and is marked as fixed. This doesn't actually seem to be the case, as the test case attached to that issue is still failing.



 Comments   
Comment by barney2k7 [ 10/Jul/14 ]

Here's the test case:

CrLfMarshalUnmarshalTest.java
import java.io.StringReader;
import java.io.StringWriter;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMResult;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import junit.framework.TestCase;

import org.w3c.dom.Document;

public class CrLfMarshalUnmarshalTest extends TestCase {
  private static final String VALUE = "abc\r\nd\re\nf";
  private Bean fElem;
  private Marshaller fMarshaller;
  private Unmarshaller fUnmarshaller;
  
  @Override
  protected void setUp() throws Exception {
    super.setUp();
    JAXBContext ctx = JAXBContext.newInstance(Bean.class);
    fMarshaller = ctx.createMarshaller();
    fUnmarshaller = ctx.createUnmarshaller();
    
    fElem = new Bean();
    fElem.setAttributeString(VALUE);
    fElem.setElementString(VALUE);
  }
  
  public void testWriter() throws Exception {
    StringWriter sw = new StringWriter();
    fMarshaller.marshal(fElem, sw);
    String resultXml = sw.toString();
    System.out.println(resultXml);
    Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml));
    assertEquals(VALUE, resultElem.getAttributeString());
    assertEquals(VALUE, resultElem.getElementString());
  }

  public void testDomAndTransform() throws Exception {
    StringWriter sw = new StringWriter();
    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    dbf.setNamespaceAware(true);
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document d = db.newDocument();
    DOMResult result = new DOMResult(d);
    fMarshaller.marshal(fElem, result);
    Transformer tf = TransformerFactory.newInstance().newTransformer();
    tf.transform(new DOMSource(d), new StreamResult(sw));
    String resultXml = sw.toString();
    System.out.println(resultXml);
    Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml));
    assertEquals(VALUE, resultElem.getAttributeString());
    assertEquals(VALUE, resultElem.getElementString());
  }
  
  @XmlAccessorType(XmlAccessType.FIELD)
  @XmlType(name = "", propOrder = {"fElementString", "fAttributeString"})
  @XmlRootElement(name = "Bean")
  public static class Bean {

    @XmlElement(name = "ElementString")
    protected String fElementString;

    @XmlAttribute(name = "AttributeString")
    protected String fAttributeString;
    
    public String getElementString() {
      return fElementString;
    }
    
    public void setElementString(String elementString) {
      fElementString = elementString;
    }
    
    public String getAttributeString() {
      return fAttributeString;
    }
    
    public void setAttributeString(String attributeString) {
      fAttributeString = attributeString;
    }

  }
}
Comment by barney2k7 [ 06/Dec/16 ]

Created a pull request: https://github.com/gf-metro/jaxb/pull/32





[JAXB-1029] Incorrect marshalling of object with overridden properties Created: 08/Jul/14  Updated: 09/Jul/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vtkhir Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_03"
jaxb 2.2.7



 Description   
Parent.java
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Parent {
    private String field;

    @XmlElement(name = "field")
    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }
}
Child.java
@XmlRootElement(name = "Node")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Child extends Parent {
    @Override
    @XmlElement(name = "overridedField")
    public String getField() {
        return super.getField();
    }

    public void setField(String field) {
        super.setField(field);
    }
}

Marshalling using jaxb 2.2.7:

<Node><field>test</field><overridedField>test</overridedField></Node>

jaxb 2.1.13:

<Node><overridedField>test</overridedField></Node>

Property overriding was fixed in JAXB-804 but issue remained in case when child class doesn't contains the field. The only option to get round with property access type is to add field in the Child class



 Comments   
Comment by Iaroslav Savytskyi [ 09/Jul/14 ]

Hi vtkhir,

Thank you for reporting. This looks like a bug. I'll take a look asap I'll be able to.


Best regards.
Iaroslav





[JAXB-1028] Unmarshaller sets the incorrect element as nil Created: 03/Jul/14  Updated: 02/Feb/15  Resolved: 02/Feb/15

Status: Closed
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.6
Fix Version/s: 2.2.11

Type: Bug Priority: Major
Reporter: scottetech Assignee: Iaroslav Savytskyi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have generated classes for the xml schema below using xjc. I have noticed that when unmarshalling an xml message like the one below where the UserReference element is nil the ResourceSpecification is marked a nil according to the object, even so the object is not null. If I then marshal the object into XML the ResourceSpecification is marked as nil and if I unmarshal it again back into an Object the ResourceSpecification is null.

XSD

<xs:schema elementFormDefault="qualified"
targetNamespace="http://mycompany.com/CoreServices/Entities" xmlns:ser="http://schemas.microsoft.com/2003/10/Serialization/"
xmlns:tns="http://mycompany.com/CoreServices/Entities" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
<xs:complexType name="JobType">
<xs:sequence>
<xs:element name="JobReference" nillable="true" type="xs:string" />
<xs:element name="CurrentResources" nillable="true"
type="tns:ActualResourceAllocations" />
</xs:sequence>
</xs:complexType>
<xs:element name="Job" nillable="true" type="tns:JobType" />
<xs:complexType name="ActualResourceAllocations">
<xs:sequence>
<xs:element name="AllocatedResources" nillable="true"
type="tns:ArrayOfResource" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfResource">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Resource"
nillable="true" type="tns:Resource" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="Resource">
<xs:sequence>
<xs:element name="UserReference" nillable="true" type="xs:string" />
<xs:element minOccurs="0" name="ResourceSpecificationB"
nillable="true" type="tns:ResourceSpecification" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResourceSpecification">
<xs:sequence>
<xs:element name="ResourceSpecificationId" type="xs:int" />
<xs:element name="SpecUserReference" nillable="true" type="xs:string" />
<xs:element name="Description" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>

Example XML

<a:Job xmlns="http://mycompany.com/CoreServices" xmlns:a="http://mycompany.com/CoreServices/Entities"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:JobReference>ESB234-TC015_LG</a:JobReference>
<a:CurrentResources>
<a:AllocatedResources>
<a:Resource>
<a:UserReference i:nil="true" />
<a:ResourceSpecificationB>
<a:ResourceSpecificationId>1</a:ResourceSpecificationId>
<a:SpecUserReference>as</a:SpecUserReference>
<a:Description>Default</a:Description>
</a:ResourceSpecificationB>
</a:Resource>
</a:AllocatedResources>
</a:CurrentResources>
</a:Job>

Example unit test
package com.mycompany.xml;

import java.io.File;
import java.io.StringReader;
import java.io.StringWriter;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;

import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.mycompany.ws.mywebservice.JobType;
import com.mycompany.ws.mywebservice.Resource;

/**

  • This is a test
    *
    */
    public class NilTest {

private static final Logger LOG = LoggerFactory.getLogger(NilTest.class);

@Test
public void testNil() throws Exception {
JAXBContext context = JAXBContext.newInstance(JobType.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
Object a = unmarshaller.unmarshal(new File("src/test/resources/failingmessage.xml"));

JAXBElement<JobType> jobTypeElement = (JAXBElement<JobType>) a;
JobType jobType = jobTypeElement.getValue();
for (Resource r : jobType.getCurrentResources().getAllocatedResources().getResource())

{ LOG.info("resource specification " + r.getResourceSpecificationB()); LOG.info("resource specification is nil " + r.getResourceSpecificationB().isNil()); LOG.info("Descriptor " + r.getResourceSpecificationB().getValue().getDescription()); }

Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
StringWriter sw = new StringWriter();
marshaller.marshal(a, sw);
System.out.print(sw.toString());

StringReader sr = new StringReader(sw.toString());
a = unmarshaller.unmarshal(sr);

jobTypeElement = (JAXBElement<JobType>) a;
jobType = jobTypeElement.getValue();
for (Resource r : jobType.getCurrentResources().getAllocatedResources().getResource())

{ LOG.info("resource specification " + r.getResourceSpecificationB()); LOG.info("resource specification is nil " + r.getResourceSpecificationB().isNil()); LOG.info("Descriptor " + r.getResourceSpecificationB().getValue().getDescription()); }

}

}



 Comments   
Comment by kylape [ 05/Aug/14 ]

I tested the reproducer posted, and it seems to work as reported.

I created a (hopefully) simpler reproducer:

<xs:schema xmlns:tns="http://jaxb.gss.redhat.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0" targetNamespace="http://jaxb.gss.redhat.com/">
  <xs:element name="team" type="tns:team"/>
  <xs:complexType name="team">
    <xs:sequence>
      <xs:element ref="tns:abstractName"/>
      <xs:element ref="tns:member"/>
    </xs:sequence>
  </xs:complexType>
  <xs:element abstract="true"  name="abstractName" nillable="false"/>
  <xs:element abstract="false" name="name"         nillable="true" substitutionGroup="tns:abstractName" type="xs:string"/>
  <xs:element abstract="true"  name="member"       nillable="false"/>
  <xs:element abstract="false" name="programmer"   nillable="true" substitutionGroup="tns:member" type="xs:string"/>
</xs:schema>

Code to test:

package com.redhat.gss.jaxb;

import java.net.URL;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;

public class Test {
  private static JAXBContext ctx = null;

  public static void main(String[] args) throws Exception {
    ctx = JAXBContext.newInstance(ObjectFactory.class, Team.class, String.class);
    URL inputUrl = Test.class.getResource("/no-nil.xml");
    System.out.println("Non-nil test.");
    doTest(inputUrl);
    System.out.println("\nNil test.  Member should NOT be nil");
    inputUrl = Test.class.getResource("/nil.xml");
    doTest(inputUrl);
  }

  public static void doTest(URL inputUrl) throws Exception {
    Unmarshaller unm = ctx.createUnmarshaller();
    Object o = unm.unmarshal(inputUrl);
    Team team = ((JAXBElement<Team>)o).getValue();
    System.out.println("Name: " + team.getAbstractName().getValue());
    System.out.println("Name nil? " + (team.getAbstractName().isNil() ? "YES" : "NO"));
    System.out.println("Member: " + team.getMember().getValue());
    System.out.println("Member nil? " + (team.getMember().isNil() ? "YES" : "NO"));
  }
}

nil.xml:

<team xmlns="http://jaxb.gss.redhat.com/">
  <name xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
  <programmer>Kyle</programmer>
</team>

no-nil.xml:

<team xmlns="http://jaxb.gss.redhat.com/">
  <name>SEG</name>
  <programmer>Kyle</programmer>
</team>
Comment by kylape [ 05/Aug/14 ]

Pull request: https://github.com/gf-metro/jaxb/pull/3

Comment by Iaroslav Savytskyi [ 02/Feb/15 ]

Already fixed in 2.2.11





[JAXB-1027] NullPointerException with @XmlRootElement and @XmlValue Created: 22/Jun/14  Updated: 22/May/15

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tmjee1 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This happens with the jaxb version that comes bundled with jdk8

@XmlRootElement("obj1")
public class Object1

{ @XmlElementRef public Object2 object2 }

@XmlRootElement("obj2")
public class Object2

{ @XmlValue public String val; }

the above would trigger
Exception in thread "main" java.lang.NullPointerException
at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:488)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:305)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)



 Comments   
Comment by rpmcfong [ 13/May/15 ]

I encountered this issue today on Java 1.8.0_40 and took a look through the source code for 2.2.11. It looks like it would work if we didn't consider it a leaf node.

One fix would require com.sun.xml.bind.v2.runtime.property.PropertyFactory.create line 124 to return false. This would allow line 126 to find propImpls[7] which is SingleReferenceNodeProperty.class. Alternatively, we could add SingleReferenceNodeProperty​ to propImpls[1].

Are there side effects to this suggestion?

Comment by Iaroslav Savytskyi [ 22/May/15 ]

I've spent some time trying to understand why it's working like this.
The problem is in @XmlElementRef -> @XmlValue combination. It seems to be valid combination even if XJC is not generating such case in this way.

Comment by Iaroslav Savytskyi [ 22/May/15 ]

@rpmcfong: the side effect is that generated XML is not correct





[JAXB-1026] Running XJC with BOTH a binding file and a catalog that re-writes system ID's can lead to multiple type declaration errors Created: 19/Jun/14  Updated: 19/Jun/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dkulp Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When calling XJC with using a catalog that does a re-write of the SystemID:

REWRITE_SYSTEM "http://foo.blah.com/MySchema.xsd" "MyNewLocation.xsd"

AND there is a binding file added (it can be an empty binding file or a binding file with a globalBinding), and the schema ends up in a circular import loop, it can result in "already defined" errors.

The root cause is on line 296 of DOMForest (xjc version 2.2.11). The InputSource returned from:

 if( entityResolver!=null )
            is = entityResolver.resolveEntity(null,systemId);

could have a new systemId. However, when it calls the parse on line 301, it passes the old system id. That is then used as the key for the call to "core.add" (line 383).

Note: if you DON'T us a binding file, this is not a problem as the optimized code path for that does not suffer from this issue. In that case, line 342 of NGCCRuntimeEx properly calls the source.getSystemId() to get the system ID that it then uses.



 Comments   
Comment by dkulp [ 19/Jun/14 ]

I cannot find an option to attach a file to this issue that includes a test case.

A test case that demonstrates the problem can be found at:

http://dankulp.com/JAXB-1026.tar.gz





[JAXB-1025] Single schema works but not multiple schema Created: 07/Jun/14  Updated: 09/Sep/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lulseged Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 8.1 Enterprise



 Description   

Validation works with single schema but does not work with multiple schema. Java objects created by xjc are same. My tests works when it is a single schema but gives validation error when I use multiple schema, cvc-elt.1: Cannot find the declaration of element 'itinerary'.

There is no single difference between single and multiple schema except it is divided in number of schemas.

Why is validation failing?

I have used 2.2.7 and 2.2.11-SNAPSHOT. Gives the same error.

I can provide a maven project that can demonstrate this case.

I will appreciate any help.

BR
Lulseged

For single:

Source source = new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd");

For multiple:
Source[] source = new StreamSource[]
{
new StreamSource(getClass().getResourceAsStream("/xsd/travel.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/plane.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd"))
};

Schema schema = schemaFactory.newSchema(source);

When using

Single schema:
itinerary.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xsd:element name="travel" type="e:travel-type" />

<xsd:complexType name="travel-type" abstract="true">
<xsd:sequence>
<xsd:element name="origin" type="xsd:string" />
<xsd:element name="destination" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>

<!-- plane -->
<xsd:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xsd:complexType name="plane-type">
<xsd:complexContent>
<xsd:extension base="e:travel-type">
<xsd:sequence>
<xsd:element name="flightNumber" type="xsd:int" />
<xsd:element name="meal" type="xsd:string" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!-- itinerary -->
<xsd:element name="itinerary" type="e:itinerary-type" />

<xsd:complexType name="itinerary-type">
<xsd:sequence>
<xsd:element ref="e:travel" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>

</xsd:schema>

Multiple schema:
travel.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:element name="travel" type="e:travel-type" />

<xs:complexType name="travel-type" abstract="true">
<xs:sequence>
<xs:element name="origin" type="xs:string" />
<xs:element name="destination" type="xs:string" />
</xs:sequence>
</xs:complexType>

</xs:schema>

itinerary.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" xmlns="http://example.org/"
targetNamespace="http://example.org/" elementFormDefault="qualified">

<xs:include schemaLocation="travel.xsd" />

<xs:include schemaLocation="plane.xsd" />

<xs:element name="itinerary" type="e:itinerary-type" />

<xs:complexType name="itinerary-type">
<xs:sequence>
<xs:element ref="e:travel" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:schema>

plane.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:include schemaLocation="travel.xsd" />

<xs:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xs:complexType name="plane-type">
<xs:complexContent>
<xs:extension base="e:travel-type">
<xs:sequence>
<xs:element name="flightNumber" type="xs:int" />
<xs:element name="meal" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>



 Comments   
Comment by Newtopian [ 09/Sep/16 ]

I would suspect the order in which you pass the XSD to XJC matters. make sure the dependencies appear first in the list and see if that fixes your issue.

I would suspect all xjc uses the same sub-system to load the XSD and build the namespaces

https://java.net/jira/browse/JAXB-906





[JAXB-1024] we are having multiple schema which is having same element name and same namespace Created: 03/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Closed
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.5
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: androidgalaxyman Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 , jboss EAP 6.1 Final , jdk java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)


Tags: jax-ws, jaxb, jaxb-xjc, jboss, metro

 Description   

our application generates the web service classes using JAXB / XJC compiler. we are giving multiple schema as the input to get the java classes for web services . The schema files will be compiled each one and put into the separate packages. assume we are having X and Y schema , just like below mentioned schema. Each schema having same element name , but having the type of complexType .but different complex type. When compilation it will generate the multiple ObjectFactory. This web service , we are trying to deploy in jboss EAP 6.1 ,results the problem of illegalAnnotationException. Can you please anyone advise?

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
The element name {}row has more than one mapping.
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XType.ObjectFactory.createRow(com.xxx.tws.pojo.XType.XType)
at com.xxx.tws.pojo.XType.ObjectFactory
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XTESTType.ObjectFactory.createRow(com.xxx.tws.pojo.XTESTType.XTESTType)
at com.xxx.tws.pojo.XTESTType.ObjectFactory

X:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XType"></xsd:element>
<xsd:complexType name="XType">
</xsd:complexType
</xsd:schema

Y:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XTESTType"></xsd:element>
<xsd:complexType name="XTESTType">
</xsd:complexType
</xsd:schema



 Comments   
Comment by androidgalaxyman [ 26/Jun/14 ]

Please close this issue. we have resolved by giving name space for each schema. Thanks

Comment by Martin Grebac [ 26/Jun/14 ]

Thanks.





[JAXB-1023] Java SE 8: generated Javadoc comments: error: bad use of '>' Created: 17/May/14  Updated: 17/May/14  Resolved: 17/May/14

Status: Resolved
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: puce Assignee: Iaroslav Savytskyi
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java: 1.8.0_05; Java HotSpot(TM) 64-Bit Server VM 25.5-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_05-b13
System: Linux version 3.11.0-19-generic running on amd64; UTF-8; de_CH (nb)


Issue Links:
Duplicate
duplicates JAXB-973 generated code should be compilable w... Resolved
Tags: java8, javadoc, xjc

 Description   

The Javadoc comments generated by XJC contains '>' instead of '>'.

This results in

error: bad use of '>'

with the default configuration of Javadoc of Java SE 8.

Tested with locale: de_CH

Here is a sample output from the Drombler ACP project:

/**

  • <p>Java-Klasse für application element declaration.
  • <p>Das folgende Schemafragment gibt den erwarteten Content an, der in dieser Klasse enthalten ist.
  • <pre>
  • <element name="application">
  • <complexType>
  • <complexContent>
  • <restriction base=" {http://www.w3.org/2001/XMLSchema}

    anyType">

  • <sequence>
  • <element name="extensions" type=" {http://www.drombler.org/schema/acp/application}

    ExtensionsType" minOccurs="0"/>

  • </sequence>
  • </restriction>
  • </complexContent>
  • </complexType>
  • </element>
  • </pre>
  • */



 Comments   
Comment by puce [ 17/May/14 ]

JIRA reformated some of the texts and I can't edit it. The correct output would be '&gt;'

Comment by puce [ 17/May/14 ]

Here the sample output again:

/**
 * <p>Java-Klasse für application element declaration.
 * 
 * <p>Das folgende Schemafragment gibt den erwarteten Content an, der in dieser Klasse enthalten ist.
 * 
 * <pre>
 * &lt;element name="application">
 *   &lt;complexType>
 *     &lt;complexContent>
 *       &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *         &lt;sequence>
 *           &lt;element name="extensions" type="{http://www.drombler.org/schema/acp/application}ExtensionsType" minOccurs="0"/>
 *         &lt;/sequence>
 *       &lt;/restriction>
 *     &lt;/complexContent>
 *   &lt;/complexType>
 * &lt;/element>
 * </pre>
 * 
 * 
 */
Comment by Lukas Jungmann [ 17/May/14 ]

duplicate of JAXB-973 and JAXB-1022





[JAXB-1022] '>' not escaped in doclet comments Created: 14/May/14  Updated: 18/Feb/15

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: schrepfler Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, xjc

 Description   

When generating the JAXB classes using XJC, the javadoc example xml instance has the '<' properly encoded while the closing '>' is not.
The result is that if one is making a maven release which triggers the javadoc compilation the errors will break that step thus the whole release.
This was observed on MacOSX and JDK8.



 Comments   
Comment by Lukas Jungmann [ 14/May/14 ]

I'd say this is jdk8 related, duplicate of https://java.net/jira/browse/JAXB-973 and not a blocker, since workaround is to pass -Xdoclint:none to javadoc executable as is documented ie here: http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html

Comment by p.gillissen [ 18/Feb/15 ]

hi schrepfler
I had the same issue (with Java 7) and solved it by updating the Maven JAXB plugin (org.jvnet.jaxb2.maven2:maven-jaxb2-plugin) to version 0.12.3. Now all my > are correctly escaped.





[JAXB-1021] When an element have same name that his element ancestor, jvc generate bad java classes, with a parent and a son with the same name. Created: 13/May/14  Updated: 13/May/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jpsanchez Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64,


Tags: element, name, same

 Description   

If you have en element with the same name that his parent, jvc run without problems but generate bad java classes.
If you tray to binding the name, then jvc generate a run time error like:

D:\PCBCK\Java\jaxb\jaxb-ri-2.2.7\samples\aod>xjc -nv -verbose messages.xsd -b bindingset.xml
Exception in thread "main" java.lang.IllegalArgumentException: Illegal class inheritance loop.
Outer class TargetSpeedElement may not subclass from inner class:
<<classnale>>
at com.sun.codemodel.internal.JDefinedClass._extends(JDefinedClass.java:257)
at com.sun.tools.internal.xjc.generator.bean.ImplStructureStrategy$1._extends(ImplStructureStrategy.java:104)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:197)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)






[JAXB-1020] XmlIDREF is ignored in subclass, causing 'A cycle is detected in the object graph. This will cause infinitely deep XML:' Created: 13/May/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Closed
Project: jaxb
Component/s: runtime
Affects Version/s: None
Fix Version/s: 2.2.11

Type: Bug Priority: Blocker
Reporter: JFK9 Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

running under Windows 7 64bit



 Description   

The version of JAXB is whatever was included in the JDK.

A Container type class includes a child type class;

public class Container {

@XmlID
public String id = "Container-" + UUID.randomUUID().toString();

public Set<Contained> children = new HashSet<Contained>();
}

The child has a reference to its container via an @XmlIDREF, which means the child will NOT include the container's XML.

public class Contained {

//Because container is a reference only it should not cause 'infinitely deep XML'
@XmlIDREF
public Container container;
}

If I create an object tree and marshall it, this works fine.
HOWEVER if I create a Subclass of Container:

public class ContainerSub extends Container {
}

it DOES NOT.

This is potentially related to https://java.net/jira/browse/JAXB-870

Test case:

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Root {

public Container container;
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

import java.util.HashSet;
import java.util.Set;
import java.util.UUID;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlID;

@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)
public class Container {

@XmlID
public String id = "Container-" + UUID.randomUUID().toString();

public Set<Contained> children = new HashSet<Contained>();
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

public class ContainerSub extends Container {
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlIDREF;

@XmlAccessorType( XmlAccessType.PUBLIC_MEMBER )
public class Contained {

//Because container is a reference only it should not cause 'infinitely deep XML'
@XmlIDREF
public Container container;
}

--------------------------------------------------------------

package uk.co.his.play;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;

import org.junit.Test;

import uk.co.his.test.jaxb.metrobug.Contained;
import uk.co.his.test.jaxb.metrobug.Container;
import uk.co.his.test.jaxb.metrobug.ContainerSub;
import uk.co.his.test.jaxb.metrobug.Root;

public class JAXBbugs {

@Test
public void idRefsDoBreakCyclesInJdkJAXBinSuperClass() throws JAXBException

{ Root root = new Root(); root.container = new Container(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); JAXBContext context = createJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

@Test
public void idRefsShouldBreakCyclesInJdkJAXBinSubclass() throws JAXBException

{ Root root = new Root(); root.container = new ContainerSub(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); JAXBContext context = createJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

@Test
public void idRefsDoBreakCyclesInMoxy() throws JAXBException

{ Root root = new Root(); root.container = new ContainerSub(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); org.eclipse.persistence.jaxb.JAXBContext context = createMoxyJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

private static JAXBContext createJAXBContext(Class<?> clazz) throws JAXBException

{ return JAXBContext.newInstance(clazz); }

private static org.eclipse.persistence.jaxb.JAXBContext createMoxyJAXBContext(Class<?> clazz) throws JAXBException {
Class<?> clazzs[] =

{ clazz }

;
return (org.eclipse.persistence.jaxb.JAXBContext) org.eclipse.persistence.jaxb.JAXBContextFactory.createContext(clazzs, null);
}
}



 Comments   
Comment by iain.wilson [ 14/Oct/14 ]

Just to confirm that I have witnessed the same issue with Version 7 Update 67 and would agree with the status of the Jira.

Some comment on here from the devs would be appreciated so there is some visibility of when or if this issue is likely to be fixed.

Comment by Iaroslav Savytskyi [ 14/Oct/14 ]

Hi Iain,

Thanks for reporting. I can confirm that within JDK7 there is a bug with inherited cycle dependencies.

But it's already fixed in latest JAXB 2.2.11.

Comment by Iaroslav Savytskyi [ 14/Oct/14 ]

Already fixed.





[JAXB-1019] Invalid boolean values added to lists as 'false' (part 2) Created: 12/May/14  Updated: 12/May/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.4
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: kylape Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by kylape [ 12/May/14 ]

This is a continuation of JAXB-849. While that jira fixed some cases of illegal xs:boolean values, there are still others that return false when they should return null, namely values that start with t and f. It looks like changing these two lines to return null would do the trick:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L270
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L285

In addition, if the string literals "t" and "f" are passed in, this will cause an unmarshalling error:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:203) [rt.jar:1.7.0_55]
        at java.lang.StringBuilder.charAt(StringBuilder.java:72) [rt.jar:1.7.0_55]
        at com.sun.xml.bind.DatatypeConverterImpl._parseBoolean(DatatypeConverterImpl.java:260)

This would map to either of these two lines on master:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L264
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L278

Comment by kylape [ 12/May/14 ]

Pull request for this issue (with added test case): https://github.com/gf-metro/jaxb/pull/2





[JAXB-1018] NPE when using mixed element and episode Created: 10/May/14  Updated: 10/May/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.4u2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: MichelHartmann Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm trying to compile two XSD files using an episode file:

The first one:
xjc -d out -episode schema_1.episode schema_1.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://example.com/schema_1"
	   xmlns:ns1="http://example.com/schema_1"
	   xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:element name="Element">
		<xs:complexType>
			<xs:simpleContent>
				<xs:extension base="xs:string">
					<xs:attribute name="Attribute" type="xs:string" use="optional" />
				</xs:extension>
			</xs:simpleContent>
		</xs:complexType>
	</xs:element>

</xs:schema>

Then I try to compile the second file:
xjc -verbose -d out schema_2.xsd -extension -b schema_1.episode

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
	targetNamespace="http://example.com/schema_2"
	xmlns:ns1="http://example.com/schema_1"
	xmlns:ns2="http://example.com/schema_2"
	xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:import namespace="http://example.com/schema_1" schemaLocation="schema_1.xsd" />

	<xs:complexType name="Abstract" abstract="true" mixed="true">
		<xs:sequence>
			<xs:element ref="ns1:Element" minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>

</xs:schema>

This will result in.

Exception in thread "main" java.lang.NullPointerException
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:173)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:146)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:114)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:97)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:62)
        at com.sun.tools.internal.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:67)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:759)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:540)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:243)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
        at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
        at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
        at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
        at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)

If I drop the mixed="true" or if I place both elements in one XSD the compilation will succeed.






[JAXB-1017] Messages.properties: Incorrect value for CONFLICTING_XML_ELEMENT_MAPPING Created: 07/May/14  Updated: 27/Oct/16

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.5, 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: soilworker Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When JAXB wants to read the string for following error:

CONFLICTING_XML_ELEMENT_MAPPING = \
    The element name '{'{0}'}'{1} has more than one mapping.

the original error will be lost because the formatting of the string fails and a new exception will be thrown:

java.lang.IllegalArgumentException: can't parse argument number ''{0}''
	at java.text.MessageFormat.makeFormat(MessageFormat.java:1339)[:1.6.0_25]
	at java.text.MessageFormat.applyPattern(MessageFormat.java:458)[:1.6.0_25]
	at java.text.MessageFormat.<init>(MessageFormat.java:350)[:1.6.0_25]
	at java.text.MessageFormat.format(MessageFormat.java:811)[:1.6.0_25]
	at com.sun.xml.bind.v2.model.impl.Messages.format(Messages.java:133)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.TypeInfoSetImpl.add(TypeInfoSetImpl.java:306)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.RegistryInfoImpl.<init>(RegistryInfoImpl.java:121)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.addRegistry(ModelBuilder.java:362)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:332)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:460)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:298)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:141)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1163)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_25]
	at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)[:1.6.0_25]
	at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:267)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at java.security.AccessController.doPrivileged(Native Method)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:172)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:464)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:330)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:478)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:690)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:540)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:252)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:205)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:90)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:156)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:156)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]

I used the version 2.2.5 but I've been taking a look to the newest version(2.2.7 and 2.2.7-b63) and there the message string is still the same. So I think this issue is still present



 Comments   
Comment by soilworker [ 07/May/14 ]

I see now that it only appears with the german language(Messages_de.properties).

Comment by afavieres [ 27/Oct/16 ]

I have this bug with english language.





[JAXB-1016] Importing elements from schema with no namespace into schema with a namespace fails Created: 30/Apr/14  Updated: 30/Apr/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markjenner Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 or Linux, Java 6u18



 Description   

I have a complex schema most of which uses the empty namespace, except for one file, CDQobjects.xsd. The elements in there need to rely on some elements from the empty namespace and imports the appropriate file CreditCurves.xsd. However when I run xjc on the schema it fails with error:

parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'RelativeCreditSpreadCurve' to a(n) 'element declaration' component.
line 13 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

[ERROR] src-resolve: Cannot resolve the name 'CreditSpreadCurve' to a(n) 'element declaration' component.
line 14 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

However, if I remove all of the other schema files and leave just the one with the error and the one it relies on, without editing them:

  • CDQobjects.xsd
  • CreditCurves.xsd

Then xjc creates the java classes correctly.

I tried to whittle down the test case to a simpler schema to make it easier for you to reproduce the problem but I ran into some strange and seemingly improbable dependencies:

  • I got the test set down to just 3 files, and the addition the 3rd (unreferenced) xsd file would cause the error to appear. However, when I moved this schema to a different dir to package them up, I noticed that the error did not occur on the copy!
  • In a different test, I changed the name of CreditCurves.xsd to BeforeCDQobjectsCreditCurves.xsd and the error went away when I used xjc on Windows 7, but still occurred on our build server on Linux.

The error seems to consistently occur on Windows with the package of Schema files that I have attached. I hope you can reproduce it locally and then just delete bits until you get to a simple case that reliably fails and helps you uncover the problem.

Ah. I just started looking for the attach button to include the schema and there doesn't seem to be one! How should I send you the test case?






[JAXB-1015] Quote character is not replaced by U+0022 during marshalling Created: 29/Apr/14  Updated: 07/May/14

Status: Open
Project: jaxb
Component/s: None
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: j.malek Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java1.8u05 + Maven3



 Description   

There is a problem when marshalling object that contains XML string with quote character.
Character " is not replaced by '"'.
Here is JUnit test that fails:

public class WrappedXMLMarshallingTest {

    @Test
    public void shouldMarshallWrappedXML() throws JAXBException {
        // given
        Message message = new Message("<frame type=\"1.0\">test</frame>");
        Marshaller marshaller = createMessageMarshaller();
        ByteArrayOutputStream result = new ByteArrayOutputStream();

        // when
        marshaller.marshal(message, result);

        // then
        String expectedResult =
                "<message><content>&lt;frame type=&quot;1.0&quot;&gt;test&lt;/frame&gt;</content></message>";
        assertEquals(expectedResult, result.toString());
    }

    private Marshaller createMessageMarshaller() throws JAXBException {
        JAXBContext context = JAXBContext.newInstance(Message.class);
        Marshaller marshaller = context.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");
        marshaller.setProperty(Marshaller.JAXB_FRAGMENT, true);
        return marshaller;
    }

    @XmlAccessorType(XmlAccessType.FIELD)
    @XmlType(name = "", propOrder = {
            "content"
    })
    @XmlRootElement(name = "message")
    static class Message {
        private String content;

        private Message() {
        }

        private Message(String content) {
            this.content = content;
        }

        String content() {
            return content;
        }
    }
}


 Comments   
Comment by j.malek [ 07/May/14 ]

It looks like I made a mistake, """ is used to allow attribute values to contains double quotes, in this scenario quote is used in xml element so marshalling works fine.





[JAXB-1014] eclipse Luna reports an error in classes generated by JAXB Created: 22/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

Status: Closed
Project: jaxb
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: andreaMz Assignee: Iaroslav Savytskyi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1 x64, eclipse Luna M6, JRE 7u55



 Description   

When generating Java classes for a simple xsd file, one of the generated Java classes shows the error
The expected XML type associated with 'int' is not valid for XML element 'ARQPriority'
but the xsd file seems correct, and the generated Java code also seems correct.
Since I don't see a way to attach a file to the report, here is the sample xsd file, the error is in the Java class generated for ARQParameterSetType. If desired, I can provide the whole eclipse Luna project.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="xs3p.xsl"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns="http://test" 
            xmlns:mdl="http://test" 
            targetNamespace="http://test" 
            elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xsd:element name="MDLRoot" type="MDLRootType"/>
  <xsd:complexType name="MDLRootType">
    <xsd:sequence>
      <xsd:element name="RadioLink" type="RadioLinkType" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="RadioLinkType">
    <xsd:sequence>
      <xsd:element name="ARQParameterSet" type="ARQParameterSetType" minOccurs="0" maxOccurs="8"/>
    </xsd:sequence>
    <xsd:attribute name="ID" type="xsd:ID" use="required"/>
  </xsd:complexType>
  <xsd:complexType name="ARQParameterSetType">
    <xsd:sequence>
      <xsd:element name="ARQPriority" type="ARQPriorityType"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:simpleType name="ARQPriorityType">
    <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="0"/>
      <xsd:maxInclusive value="7"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>


 Comments   
Comment by Pavel Bucek [ 22/Apr/14 ]

just a side-question: why are you filing this bug against JAXB when you state that the problem is most likely on Eclipse Luna side?

Comment by andreaMz [ 22/Apr/14 ]

It is my understanding that Eclipse simply reports an error that is generated by JAXB, since in the Problems view the Type is listed as "JAXB Problem". Besides, the problem is reported the same way in Eclipse Juno.

Comment by Pavel Bucek [ 22/Apr/14 ]

Ok, sounds more valid now.

Next time, you can include that info as well (generally, you want to add as much relevant info as possible...). It could be useful to know which component reports these issues to confirm that the info Juno is displaying is from JAXB; have you tried to marshal/unmarshal with registered ValidationEventHandler? Did that produced anything?

And please add a link to the issue reported agains Eclipse Juno, it might be useful (especially if that contains more informations).

Thanks!

Comment by andreaMz [ 22/Apr/14 ]

As you can imagine, the sample xsd file I included in my report is a subset of a much larger and complex third party xsd file. I was able to unmarshal and marshal xml files corresponding to the original xsd without any validation issue reported. The only "problem" are these errors showing up in many of the classes generated from the original xsd file.
If that would help reproduce the problem, I could upload a zip of the eclipse project that produces it, but I need to know how (where) to upload it. Also, since not many people use Eclipse Luna yet, should I upload a project for Eclipse Juno? would that be simpler to use?

Comment by Pavel Bucek [ 22/Apr/14 ]

The best would be if you could find minimal XML schema which will reproduce the issue, without any other complex external schemas and then "upload" your project somewhere (preferably github). I guess you don't really need to upload project files for "all" other versions, just state that this issue is reproducible on older (Juno, ..) eclipse versions, so it is not a regression.

// the link to issue agains Eclipse Luna is still missing

Comment by andreaMz [