[JAXB-1104] Generate goal fails with JDK 1.8.0 - again Created: 19/Aug/16  Updated: 19/Aug/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






[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-850] NullPointerException - com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get with @XmlValue and generics Created: 04/Aug/11  Updated: 16/Aug/16

Status: In Progress
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.4u1
Fix Version/s: None

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

Windows XP


Tags: metro2_2-waived

 Description   

I've a class with generics like this :

@XmLRootElement
public class NillableValue<E> {
    private boolean _nillable = false;
    private E _value = null;
    
    @XmlAttribute(name="null")
    public boolean isNillable() {
	return _nillable;
    }

    @XmlValue	
    public E getValue() {
 	return _value;
    }

    // Setter here
}

And another like this :

@XmLRootElement
public class NillableStringValue extends NillableValue<E> {}

When i try to marshall NillableStringValue, got :

java.lang.NullPointerException
	at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:169)

This works if i replace @XmlValue by @XmlElement and when I don't use generics



 Comments   
Comment by Herr-Herner [ 16/Aug/16 ]

I am confronted with the same issue. The built-in JAXB implementation seems to have a problem when it should marshal objects of type Object in combination with @XmlValue. It's time to get rid of this bug.





[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-986] Using marshaller on xjc generated classes causes Exception. Works in jdk7, not in jdk 8. Created: 24/Oct/13  Updated: 09/Aug/16

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

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

Windows 7
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b109)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b51, mixed mode)


Tags: jaxb-xjc

 Description   

Using marshaller on xjc generated classes causes java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

Works in jdk7, not in jdk 8.

Java file generated by xjc in jdk8 is different than what is produced
by xjc in jdk7.

Schema:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="intlist">
<xs:list itemType="xs:int"/>
</xs:simpleType>
<xs:complexType name="Person">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="scores" type="intlist"/>
</xs:sequence>
</xs:complexType>
<xs:element name="person" type="Person"/>
</xs:schema>

Difference in Person.java
in jdk8:
@XmlList
@XmlElement(type = Integer.class)
@XmlSchemaType(name = "anySimpleType")
protected List<Integer> scores;

in jdk 7:
@XmlList
@XmlElement(type = Integer.class)
protected List<Integer> scores;

REGRESSION : Additional Information
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b109)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b51, mixed mode)

xjc 2.2.8-b20130806.1801

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile xsd to Java files:
$ xjc.exe -p jaxb -d src test.xsd

Compile test program and run.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected an XML file to be created with Person object.
ACTUAL -
Exception

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.String

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package jaxb;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import java.io.File;
import java.io.FileOutputStream;
import java.util.List;

public class App {

public static void main( String[] args ) throws Exception {

File file = new File( "test-out.xml");
FileOutputStream fis = new FileOutputStream( file );
ObjectFactory of = new ObjectFactory();

Person person = of.createPerson();
person.setName( "Bob" );
List<Integer> values = person.getScores();
values.add( 1 );
values.add( 2 );

JAXBElement jaxbElement = of.createPerson( person );

JAXBContext ctx = JAXBContext.newInstance( "jaxb" );
try

{ Marshaller marshaller = ctx.createMarshaller(); // Dies here with: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String marshaller.marshal( jaxbElement, fis ); fis.close(); }

catch( JAXBException e )

{ throw new RuntimeException( e ); }

}
}



 Comments   
Comment by dkulp [ 12/Sep/14 ]

This should be raised from Minor to Critical.

This bug also exists in "JAXB RI v2.2.10-b140310.1920".

This is preventing the WS-Discovery service in CXF from working properly as the WS-Discovery API's have a XmlList of QNames and trying to marshal the Discovery messages is causing ClassCast exceptions from QName to String.

Comment by jotel71 [ 09/Jan/15 ]

It's obvious regression and priority should be much higher then minor!

The problem is when some of the elements references an extended simple type by name. The XJC adds @XmlSchemaType annotation to the generated classes which won't match actual type used. And having such classes is not possible to properly marshal it to the XML stream without class cast exception!

Bug still exists in version 2.2.11

Comment by jotel71 [ 09/Jan/15 ]

As a workaround (not nice but working) you can use annotate plugin and override wrongly produced annotation. Just add a similar constriction to your bindings:

 <jaxb:bindings node="//xs:element[@type='YourSimpleType']">
        <annox:annotate target="field">@javax.xml.bind.annotation.XmlSchemaType(name="YourSimpleType")</annox:annotate>
</jaxb:bindings>
Comment by dkulp [ 09/Jan/15 ]

As another workaround, the CXF team created an xjc plugin that tried to detect this problem and removes the XmlSchemaType annotation:

http://repo1.maven.org/maven2/org/apache/cxf/xjcplugins/cxf-xjc-bug986/3.0.3/

I still cannot believe a bug this critical and has a reproducible test case has been open for more than a year.

Comment by bo2x [ 26/Nov/15 ]

Still not working in jdk1.8.0_60 two years after...

Comment by selimok [ 09/Aug/16 ]

Same problem here.

I found some workaround for this problem, but all based on XSD manipulation (like this: http://stackoverflow.com/questions/33346803/how-to-tell-jaxb-not-to-generate-xmlschematype-annotation)

But in our case, we get the WSDL and XSD from a 3rd party source and manipulation of these is not an option.

I think the bug should be reprioritised.

Thanks.





[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-906] XJC Dependent on Order of XSDs Listed on Command Line Created: 25/Jun/12  Updated: 05/Aug/16

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

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

Attachments: Zip Archive jaxb.zip    
Tags: metro2_2-waived, xjc

 Description   

I have created a simplified example that shows that XJC is dependent on the order of the XSDs specified on the command line. In my example (attached), I have 3 XSDs in 2 namespaces:

  • A2.xsd imports B.xsd
  • B.xsd includes A.xsd
  • A2.xsd is in a distinct namespace from A.xsd and B.xsd (sharing the same namespace)

The command below fails:

>java -jar ../../lib/jaxb-ri-20120516/lib/jaxb-xjc.jar -verbose com/example/ns/A.xsd com/example/ns/B.xsd com/example/ns2/A2.xsd

parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'ns:bType' to a(n) 'type definition' component.
  line 10 of file:/in-work/lobo/mmaxey/logs/jaxb/com/example/ns2/A2.xsd

If I switch the order of A.xsd and B.xsd on the command line (making B.xsd first), it works:

>java -jar ../../lib/jaxb-ri-20120516/lib/jaxb-xjc.jar -verbose com/example/ns/B.xsd com/example/ns/A.xsd com/example/ns2/A2.xsd
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location

com/example/ns/AType.java
com/example/ns/BType.java
com/example/ns/ObjectFactory.java
com/example/ns/package-info.java
com/example/ns2/AType.java
com/example/ns2/ObjectFactory.java
com/example/ns2/package-info.java

Is this the expected behavior?



 Comments   
Comment by Iaroslav Savytskyi [ 02/Jul/12 ]

I wasn't able to find something about xsd order in the spec.
We can plan an implementation of such improvement which will allow to put schemas in default order for the future releases.

Comment by mmaxey [ 02/Jul/12 ]

I understand you have many issues to work and may want to think of this as an enhancement request. Let me make an argument for why this bug is very important to me.

I work with 300-400 XSDs where the build of these has been automated. This automation relies on being able to specify the list of XSDs by the directory name and/or in any order. Because of this bug, I must now insert some hacks into the automation that accounts for ordering. These hacks are going to be numerous because many our XSDs follow the pattern of the attached examples due to their high degree of interdependency.

Thank you for your assistance and thank you for considering my impact when assigning a priority to resolving this issue.

Comment by Newtopian [ 05/Aug/16 ]

I have a very similar issue here where I’m using the maven-jaxb2-plugin to generate code from xsd files.

I was able to track down the problem to namespace resolution. Basically the files have to be presented in such way that the order of the files represents the order of dependencies. I would expect the namespace resolver to be able to use the files in parameter as it would a catalog and to iterate the whole collection before failing to resolve a namespace.

As it stands we could summarize the situation as such:
"In order to get XJC to parse and resolve namespaces in the xsd files I must first parse and resolve the xsd files to determine namespace dependencies. Then build the file list accordingly before passing over to xjc"

When viewed like this, I would more consider this a bug than enhancement. This being said, getting this fixed is to me far more important than the categorization semantics.

The maven-jaxb2-plugin seems to use the lexicographical order of files as the order provided to xjc. More details on the issue I raised over there https://github.com/highsource/maven-jaxb2-plugin/issues/98

Should you need more info, details or repro-steps for this issue please let me know.

Thanks.

Comment by Newtopian [ 05/Aug/16 ]

Possibly related issues :





[JAXB-832] Classes created using XJC with generateMixedExtensions cannot regenerate a schema Created: 04/May/11  Updated: 02/Aug/16

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

Type: Bug Priority: Minor
Reporter: dkulp Assignee: Martin Grebac
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is taken from trying to diagnose a bug logged with CXF:

https://issues.apache.org/jira/browse/CXF-3450

If I use the testcase attached there to generate the java classes, then write a quick main method to do:

JAXBContext ctx = JAXBContext.newInstance("ping.types"); 
      SchemaOutputResolver resolver = new SchemaOutputResolver() { 
        public Result createOutput(String namespaceUri, 
                  String suggestedFileName) throws IOException { 
            StreamResult r = new StreamResult(new ByteArrayOutputStream()); 
            r.setSystemId(suggestedFileName); 
            return r; 
        }; 
      
      }; 
     ctx.generateSchema(resolver); 

it fails with the stack trace there.



 Comments   
Comment by Martin Grebac [ 09/May/11 ]

generatemixedextensions is an experimental proprietary switch, so adjusting priority accordingly

Comment by hhueter [ 21/Nov/11 ]

Is there a known workaround for this problem? I need to support a given wsdl which does use mixed contents. This bug prevents the wsdl generation and thus i cant properly deploy my JAX-WS webservice. My runtime environment is a current glassfish installation.

Comment by 0x0000.ru [ 02/Aug/16 ]

@javax.xml.bind.annotation.XmlMixed is also an experimental feature? Using this produces the same error.





[JAXB-942] Catalog with PUBLIC definition fails when using an episode Created: 21/Jan/13  Updated: 17/Jul/16

Status: In Progress
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.6
Fix Version/s: None

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


 Description   

This issue is a result of analysis for MAVEN_JAXB2_PLUGIN-53.

The problem is that using a catalog with PUBLIC definition fails when episode is used as well.

I have a schema b.xsd which imports a schema a.xsd:

<xsd:import namespace="http://maven-jaxb2-plugin/samples/episode/a" schemaLocation="a.xsd"/>

The schema a.xsd is, however placed in a/a.xsd. This can be handled with the following catalog entry:

PUBLIC "http://maven-jaxb2-plugin/samples/episode/a" "a/a.xsd"

This works fine:

xjc -catalog catalog.cat b.xsd

Now assume we also have an episode JAR:

a.jar!/META-INF/sun-jaxb.episode
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
  <bindings scd="x-schema::tns" xmlns:tns="http://maven-jaxb2-plugin/samples/episode/a">
    <schemaBindings map="false">
      <package name="maven_jaxb2_plugin.samples.episode.a"/>
    </schemaBindings>
    <bindings scd="~tns:AType">
      <class ref="maven_jaxb2_plugin.samples.episode.a.AType"/>
    </bindings>
    <bindings scd="~tns:A1Type">
      <class ref="maven_jaxb2_plugin.samples.episode.a.A1Type"/>
    </bindings>
    <bindings scd="~tns:A2EnumType">
      <typesafeEnumClass ref="maven_jaxb2_plugin.samples.episode.a.A2EnumType"/>
    </bindings>
  </bindings>
</bindings>

Now this fails:

xjc -extension -catalog catalog.cat b.xsd a.jar

The catalog does not work:

xjc -extension -catalog catalog.cat b.xsd a.jar
parsing a schema...
[ERROR] ...\test\a.xsd (Das System kann die angegebene Datei nicht finden) (eng. Could not find the file)
unknown location

Failed to parse a schema.

I can provide a minimal test project which reproduces this. Attachments do not work. Via mail? (Please ping me: valikov at gmx.net)



 Comments   
Comment by lexi [ 21/Jan/13 ]

I did some debugging and found out that in case no binding files are used, model loading opts to "speculative mode"

I traced it down to the DOMForest which calls the entity resolver with null publicId (whereas it is not null - the namespace is provided):

DOMForest.java
public Document parse( String systemId, boolean root ) throws SAXException, IOException {

        systemId = Options.normalizeSystemId(systemId);

        if( core.containsKey(systemId) )
            // this document has already been parsed. Just ignore.
            return core.get(systemId);
        
        InputSource is=null;
        
        // allow entity resolver to find the actual byte stream.
        if( entityResolver!=null )

// HERE:
            is = entityResolver.resolveEntity(null,systemId);
        if( is==null )
            is = new InputSource(systemId);
        
        // but we still use the original system Id as the key.
        return parse( systemId, is, root );
    }

If no episodes are provided, then no binding files are defined and ModelLoader opts to the "speculative" mode:

ModelLoader.java
public XSSchemaSet loadXMLSchema() throws SAXException {

        if( opt.strictCheck && !SchemaConstraintChecker.check(opt.getGrammars(),errorReceiver,opt.entityResolver, opt.disableXmlSecurity)) {
            // schema error. error should have been reported
            return null;
        }

        if(opt.getBindFiles().length==0) {
            // no external binding. try the speculative no DOMForest execution,
            // which is faster if the speculation succeeds.
            try {
                return createXSOMSpeculative();
            } catch( SpeculationFailure _ ) {
                // failed. go the slow way
            }
        }

        // the default slower way is to parse everything into DOM first.
        // so that we can take external annotations into account.
        DOMForest forest = buildDOMForest( new XMLSchemaInternalizationLogic() );
        return createXSOM(forest, scdBasedBindingSet);
    }

It seems to be something wrong with the DOMForest. It should not ignore the publicId.

Comment by phax [ 19/Jun/13 ]

I'm having the same problem in 2.2.7.
I was tracing it down to AbstractReferenceFinderImpl.startElement

The call to abstract method "findExternalResource" only returns the specified XSD path but totally ignores the publicID of the item (if present). The implementation to this method is in com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder

And afterwards it seems to me, that the resolution of the artifact does not consider a catalog!
-> In my case this leads to the problem that the catalog file must contain an absolute path instead of a relative path!

Comment by lexi [ 06/Oct/14 ]

Here's a pull request which fixed it:

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

Comment by phax [ 13/Jul/16 ]

Any progress? The pull request is there forever? I don't even get a response on my OCA request....

Comment by maiden168 [ 17/Jul/16 ]

Thanks for reminder. I'll ask someone to take a look on it next week, but no hard promises.
There are always priorities and problems with resources.





[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-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-971] Regression: annotation @XmlJavaTypeAdapters on package is ignored since JAXB v2.2.4-1 Created: 26/Jul/13  Updated: 13/Jun/16

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

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

Windows 7 x64; JDK 1.6 and JDK 1.7



 Description   

JAXB v2.2.4-1 was the last version that takes into account @XmlJavaTypeAdapters annotation (applied on package). All later JAXB versions ignore this annotation - supplied XmlAdapters are not being used.

Attached is an Ant project, adapted from JAXB sample "j2s-xmlAdapter".
Original sample code (working OK in all JAXB versions) had:

@XmlRootElement
@XmlType(name="KitchenWorldBasketType")
public class KitchenWorldBasket {
    @XmlJavaTypeAdapter(AdapterPurchaseListToHashMap.class)
    HashMap basket = new HashMap();
    ...

and

public class Main {
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(KitchenWorldBasket.class);
        ...

The attached project has these modifications:

@XmlRootElement
@XmlType(name="KitchenWorldBasketType")
public class KitchenWorldBasket {
    //@XmlJavaTypeAdapter(AdapterPurchaseListToHashMap.class)
    @XmlElement(type = PurchaseList.class)
    public LinkedHashMap basket = new LinkedHashMap();
    ...

and

@XmlJavaTypeAdapters({
        @XmlJavaTypeAdapter(value = AdapterPurchaseListToHashMap.class, type = LinkedHashMap.class)
})
package shoppingCart;

import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapters;
import java.util.LinkedHashMap;

and

public class Main {
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(KitchenWorldBasket.class.getPackage().getName());
        ...

Running the attached project with JAXB v2.2.4-1 gives:

run:
     [echo] Running the sample application...
     [java] KitchenWorldBasket:
     [java] key: 9027   value: glasstop stove in black
     [java] key: 10424  value: backsplash kit in black
     [java] key: 288    value: wooden spoon
     [java] key: 289    value: salt and pepper shakers in yellow
     [java]
     [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
     [java] <kitchenWorldBasket>
     [java]     <basket>
     [java]         <item key="9027">glasstop stove in black</item>
     [java]         <item key="10424">backsplash kit in black</item>
     [java]         <item key="288">wooden spoon</item>
     [java]         <item key="289">salt and pepper shakers in yellow</item>
     [java]     </basket>
     [java] </kitchenWorldBasket>

BUILD SUCCESSFUL

Running with JAXB v2.2.5, v2.2.6 and v2.2.7:

run:
     [echo] Running the sample application...
     [java] KitchenWorldBasket:
     [java]
     [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
     [java] <kitchenWorldBasket>
     [java]     <basket/>
     [java] </kitchenWorldBasket>

BUILD SUCCESSFUL

There is no difference, whether namespaces are being used or not. I stumbled on this bug working with WebServices and JAX-WS/JAXB bindings (where namespaces are being used).

Additionally, annotation @XmlJavaTypeAdapter is being ignored on classes too (though I do not have a sample test case).

It seems, that @XmlJavaTypeAdapter is being taken into account only when it is applied on class fields.



 Comments   
Comment by donatasc [ 26/Jul/13 ]

Sample project can be downloaded from:
http://www.mif.vu.lt/~donatas/private/j2s-xmlAdapter-onPackage.zip

Comment by Iaroslav Savytskyi [ 29/Jul/13 ]

Hi,

Thanks a lot for reporting.

May be this problem occurred because of APT rewrite in 2.2.5. I have to check.

Comment by matejsp [ 13/Jun/16 ]

I have the same problem. Any chance of this bug being actually fixed?
Only working solution is to put annotation on a field.
This is not possible without external annox plugin (when using XSD + binding file).

Alternative would be to set package-info or set annotation on type class (in this case LinkedHashMap).
This would be of course only possible when using custom class instead of buildin.





[JAXB-484] JAXB sometimes can't apply a customisation in multiple compilation scenario. Created: 15/Feb/08  Updated: 09/Jun/16

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.6
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: nzlemming Assignee: jaxb-issues
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Attachments: File testcase.tgz    
Issuezilla Id: 484

 Description   

We have a large project where the data layer is almost totally based on JAXB. We
have multiple levels of schemas, and use xs:import and extensions heavily.
Occasionally we have a problem where JAXB will refuse to run, saying that it
cannot honour a customisation, usually from a base schema when compiling a
sub-schema.

I finally managed to isolate a test case, see the files in the attached tar. The
problem is the javaType customisation on core:ID (in core.xsd).

To reproduce:

xjc.sh core.xsd -d output -p generated.core.com.mycorp.model.common.datatypes

This compiles just the base schema, and works correctly.

xjc.sh core.xsd card.xsd -extension -b core.episode -d output -p
generated.card.com.mycorp.model.common.datatypes

This demonstrates the base file being imported with the corresponding episode.
This also works.

xjc.sh core.xsd iso8583.xsd testcase.xsd -extension -b core.episode -b
iso8583.episode -d output -p generated.testcase.com.mycorp.model.common.datatypes

This case should be identical to the above, but breaks with the error below:

[ERROR] compiler was unable to honor this javaType customization. It is attached
to a wrong place, or its inconsistent with other bindings.
line 66 of file:/Users/colin/dev/platform/common/testcase/core.xsd

[ERROR] (the above customization is attached to the following location in the
schema)
line 61 of file:/Users/colin/dev/platform/common/testcase/core.xsd

This is a very urgent issue for us, any workaround until a fix is available
would be greatly appreciated.



 Comments   
Comment by nzlemming [ 15/Feb/08 ]

Created an attachment (id=243)
Test case files.

Comment by pbober [ 06/Oct/12 ]

I've run across this issue in 2.2.6 and 2.2.7-b41. It's four years old so I am surprised there is nobody else reporting it. Are there plans to fix it?

Comment by aledibe [ 04/Jul/13 ]

I'm having the same problem with the latest 2.2.7 version. Dis anybody found a fix/workaround?

Comment by Iaroslav Savytskyi [ 04/Jul/13 ]

Hi,

The issue is really old. And because nobody else reporting it I assumed that it's fixed.
I'll take a look at it.


Iaroslav

Comment by flutter [ 09/Jun/16 ]

As far as I can tell, it is NOT fixed in 2.2.11.

The expected behavior when using the episode mechanism would be that customizations are either ignored by the xjc run importing the episode, or that an XJC plugin gets the chance to process the customization found in the XSD imported via the episode. Both doesn't seem to work.





[JAXB-932] Some UnmarshalExceptions result in memory leaks - reference to object never released by com.sun.xml.bind.v2.runtime.unmarshaller.Scope Created: 12/Dec/12  Updated: 24/May/16

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

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

Attachments: Java Source File JaxbLeakTest.java    
Tags: memoryleak

 Description   

I have found that certain UnmarshalExceptions result in memory leaks. A reference to the unmarshalled object is held by com.sun.xml.bind.v2.runtime.unmarshaller.Scope and is never released for the lifetime of the application, which eventually results in an OutOfMemoryError if a sufficient number of UnmarshalExceptions occur.

Stacktrace of such an exception that results in a leak:

javax.xml.bind.UnmarshalException
 - with linked exception:
[org.xml.sax.SAXParseException: XML document structures must start and end within the same entity.]
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:315)
        at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:527)
        at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:224)
        at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:137)
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:194)
        at JaxbLeakTest.main(JaxbLeakTest.java:21)

Reduced test case:

import java.io.StringReader;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

public class JaxbLeakTest {
	public static void main(String args[]) throws Exception {
		JAXBContext context = JAXBContext.newInstance(JaxbLeakTest.Foo.class);
		Unmarshaller unmarshaller = context.createUnmarshaller();
		for (int i = 0; i < 1000; i++) {
			if (i % 100 == 0) {
				Runtime.getRuntime().gc();
				System.out.println("Foo.getInstanceCount()=" + Foo.getInstanceCount());
			}
			try {
				unmarshaller.unmarshal(new StringReader("<foo><bar/>"));
			} catch (Exception e) {
			}
		}
	}

	@XmlAccessorType(XmlAccessType.FIELD)
	@XmlRootElement(name = "foo")
	public static class Foo {
		private List<String> bar;

		private static AtomicInteger instanceCount = new AtomicInteger();

		public Foo() {
			instanceCount.incrementAndGet();
		}

		protected void finalize() {
			instanceCount.decrementAndGet();
		}

		public static int getInstanceCount() {
			return instanceCount.get();
		}
	}
}

The output of the above test case, using JAXB RI 2.2.6:

Foo.getInstanceCount()=0
Foo.getInstanceCount()=100
Foo.getInstanceCount()=200
Foo.getInstanceCount()=300
Foo.getInstanceCount()=400
Foo.getInstanceCount()=500
Foo.getInstanceCount()=600
Foo.getInstanceCount()=700
Foo.getInstanceCount()=800
Foo.getInstanceCount()=900

In the process of creating the above test case, I found that the type of the variable "bar" has an effect on whether the leak occurs. The leak only seems to occur when bar is a List.

Reference chain from Eclipse:

[1] JaxbLeakTest$Foo  (id=26)
  '[1]' referenced from:
    [0] Scope<BeanT,PropT,ItemT,PackT>  (id=158)
      '[0]' referenced from:
        [0] Scope<BeanT,PropT,ItemT,PackT>[128]  (id=137)
          '[0]' referenced from:
            [1] UnmarshallingContext  (id=133)


 Comments   
Comment by peddapola [ 24/May/16 ]

instead caching Unmarshaller, just cache JAXBContext

below code should work fine, without much performance impact:

import java.io.StringReader;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;

public class JaxbLeakTest {
public static void main(String args[]) throws Exception {
JAXBContext context = JAXBContext.newInstance(JaxbLeakTest.Foo.class);
for (int i = 0; i < 1000; i++) {
Unmarshaller unmarshaller = context.createUnmarshaller();

if (i % 100 == 0)

{ Runtime.getRuntime().gc(); System.out.println("Foo.getInstanceCount()=" + Foo.getInstanceCount()); }

try

{ unmarshaller.unmarshal(new StringReader("<foo><bar/>")); }

catch (Exception e) {
}
}
}

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "foo")
public static class Foo {
private List<String> bar;

private static AtomicInteger instanceCount = new AtomicInteger();

public Foo()

{ instanceCount.incrementAndGet(); }

protected void finalize()

{ instanceCount.decrementAndGet(); }

public static int getInstanceCount()

{ return instanceCount.get(); }

}
}





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

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

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

Operating System: All
Platform: All


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

 Description   

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

To reproduce...

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

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

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

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

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

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

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

{3}

-[A-Z]

{2}

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

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

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

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

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

protected XMLGregorianCalendar orderDate;

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

protected DateTime orderDate;

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



 Comments   
Comment by schubertf [ 17/Sep/07 ]

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

Comment by Pavel Bucek [ 21/Jan/09 ]

already fixed in 2.1.10

Comment by cristip32 [ 23/Jun/12 ]

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

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

Comment by Martin Grebac [ 25/Jun/12 ]

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

Comment by Stillglade [ 13/Feb/13 ]

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

Comment by schubertf [ 21/Apr/15 ]

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

Comment by Iaroslav Savytskyi [ 21/Apr/15 ]

May be different OS? Ant/Maven version?

Comment by luismcv [ 23/Jul/15 ]

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

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

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

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

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

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

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

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

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

Comment by csolem [ 09/May/16 ]

I have the same issue with xjc 2.2.8. Global bindings are not applied when having both include and annotation in the schema. I have created a github repository with instructions and xsd files for reproducing the issue. Please have a look at: https://github.com/csolem/xjc-global-bindings





[JAXB-917] Add support for XML schema facets and documentation Created: 04/Sep/12  Updated: 08/May/16

Status: In Progress
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.2.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: yossico Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 21
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all platforms; java se 7


Attachments: Java Archive File jaxb-facets-0.3.jar     Java Archive File jaxb-facets-1.0.jar    
Tags: jaxb

 Description   

While working closely with quite a few enterprise customers implementing ESBs/BPMs I realized the quality bar for xml schemas is constantly rising. It is no longer acceptable to have xml schema with no documentation and xsd facets.

One open source implementation supporting xsd facets can be found here: http://www.infosys.tuwien.ac.at/staff/hummer/tools/jaxb-facets.html but unfortunately it is not maintained as part of JAXB.

There are many good reasons to keep on using Java 1st approach for schema generation and it better not be neglected and supply such fundamental capabilities.
More relevant links:
http://jaxb.java.net/guide/Generating_Schema_that_you_want.html
http://java.net/projects/jaxb/lists/users/archive/2007-06/message/36



 Comments   
Comment by Iaroslav Savytskyi [ 05/Sep/12 ]

Hi, yossico,

To start working with your code we neen you to sign Oracle Contributor Agreement (OCA). Here are some links:

FAQ: http://www.oracle.com/technetwork/oca-faq-405384.pdf
OCA: http://glassfish.java.net/public/GovernancePolicy.html

Thanks a lot.

Comment by yossico [ 05/Sep/12 ]

Hi Iaroslav,

Just to make it clear, the code i have attached is not mine. It is an open source that is managed through this web site: http://www.infosys.tuwien.ac.at/staff/hummer/tools/jaxb-facets.html. Thus, if this code is planned to be used for this solution, it needs to comply with the license agreement published through that web site (contact: Mr. Waldemar Hummer; email: hummer@infosys.tuwien.ac.at).

Comment by yossico [ 09/Oct/12 ]

Hi,

I signed the form and sent it over a while ago.
To what Java release does Oracle plans to accomodate this enhancement?

Thanks,
Yossi C.

Comment by Iaroslav Savytskyi [ 08/Nov/12 ]

Hi, yossico,
I will look at this and hope if everything will be OK we will include it to JAXB 2.2.7 release.

Comment by whummer [ 09/Nov/12 ]

Version 1.0 of JAXB-Facets

Comment by whummer [ 09/Nov/12 ]

Hi,

there is a more recent, updated version 1.0 of JAXB-Facets available, which contains some minor bug fixes and API changes. I am attaching the most recent version.

EDIT: do we need to sign the agreement for each uploaded version..?

Thanks,
Waldemar H.

Comment by blaise_doughan [ 12/Dec/12 ]

Is JAXB-Facets compatible with Bean Validation (JSR-303)? If not changing it to be would help adoption and make it easier to include in a future version of the JAXB specification.

Comment by pellcorp [ 13/Dec/12 ]

it is not compatible and i would agree changing to use jsr 303 annotations would be a great idea. There is a new github repo for jaxb-facets and we are working on test coverage and refinements. i am using jsr 303 in gwt at work so there is definate synergy there. i am on leave until mid january but would be interested in seeing how easy the Facets and Min Max stuff could be refactored to use equivalent jsr 303 annotations.

only question to ponder is do we use the javax.validation annotations directly?

github is: https://github.com/whummer/jaxb-facets

Comment by pellcorp [ 13/Dec/12 ]

a very relevant forum post has already been made on this topic of jsr 303 compatibility which I was not aware of.

http://java.net/projects/jaxb/lists/dev/archive/2011-01/message/2

so compatibility might not be so easy because jsr 303 does not have the same level of validation as xsd and thus jaxb-facets.

Comment by whummer [ 13/Dec/12 ]

However, we do seek integration with JSR-303 in terms of the facets validation.

The @Facets/@MinOccurs/@MaxOccurs annotations are now annotated with @javax.validation.Constraint(validatedBy=...) and we will provide a custom validator implementation. This way, the Facets validation can be seamlessly integrated into the JSR-303 validation framework.

Comment by yossico [ 03/Feb/13 ]

Hello,

What is the estimated delivery time for this feature?
Is there a plan to incorporate this feature to the JAXB specification?

Thanks,
Yossi C.

Comment by puce [ 15/Feb/13 ]

+1 for adding this feature and making it compatible to JSR-303 resp. JSR-349 (Bean Validation 1.1)

Comment by schrepfler [ 24/Mar/13 ]

This would be a really great extension as it will fill a large hole on how we document services.
It would seem however the latest code is being developed here and not on the whummer repo?
https://github.com/pellcorp/jaxb-facets

Comment by tgeor [ 19/Jun/13 ]

In which version are you planning to include this feature? I think this extension is a must have in JAXB

Comment by schrepfler [ 19/Jun/13 ]

Also, would this only track schemagen or xjc as well?

Comment by whummer [ 21/Jun/13 ]

To avoid confusion, the repository we are working on is here:

https://github.com/whummer/jaxb-facets

We have just finished another round of refactoring, and in terms of features we believe that the code is ready for release. How shall we proceed..?

Comment by yossico [ 01/Aug/13 ]

Hello,

Any progress with this issue?
What is the target release for this enhancement?
When should we expect it?

Your reply to these questions will be greatly appreciated.

Thanks,
Yossi C.

Comment by Iaroslav Savytskyi [ 05/Aug/13 ]

I'm trying to contact the owner of jaxb-facets project. We need all projects' contributors to sign OCA. After that we'll be able to do something.

Comment by yossico [ 06/Nov/13 ]

Hello,

This is a gentle reminder

Do you know by now what is the target release for this enhancement? Release date?
Do you continually track bug-fixes/updates from jaxb-facets web site (https://github.com/whummer/jaxb-facets)?

Thanks,
Yossi C.

Comment by sytzevk [ 19/Jan/14 ]

I see that the Java-first approach is (going to be) covered, but what about wsdl-first ? Does the jaxb-facets project aim to support the jaxb java code generation annotated with facets ?

Comment by whummer [ 31/Jan/14 ]

We have added initial support for wsimport in the current release version (2.2.6-facets-1.1.0), which you can check out from github: https://github.com/whummer/jaxb-facets

@Iaroslav, is there any progress concerning the contributor agreements - when can we continue to merge this into the reference impl.? thanks

Comment by schrepfler [ 27/Mar/14 ]

Hi, any updates on progress or when can we expect to see this part of the official jaxb?

Comment by Iaroslav Savytskyi [ 31/Mar/14 ]

Hi,

We are working on the Bean Validation (JSR 303) support. I hope it will cover requirements of current request.

Comment by schrepfler [ 01/Apr/14 ]

Are you planning to release documentation and facet support at the same time? It might be good to decouple if facet+jsr303/349 will take longer to implement.

Comment by davidkarlsen2 [ 20/Apr/14 ]

BTW: There is a project here which can generate JSR303 annotations from the schemas: https://github.com/krasa/krasa-jaxb-tools if interested.

Comment by schrepfler [ 28/May/15 ]

Are we getting any closer to get this merged into the JDK?

Comment by Iaroslav Savytskyi [ 04/Jun/15 ]

I would not expect this to be implemented in JAXB RI in some visible time.
As I know Bean Validation was implemented as part of MOXy JAXB implementation.

Comment by schrepfler [ 08/May/16 ]

It's really a shame that Oracle is not taking this contribution, not only because it adds facets support to JAXB but also because it adds Annotation and Documentation as well. The impact would be positive on other things as well, for example the JAXB schemas generated by Jersey would automatically get documentation tags. Please consider this through!





[JAXB-525] Post-Unmarshall Object Retention Created: 07/Jul/08  Updated: 21/Apr/16  Resolved: 06/Oct/10

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.7
Fix Version/s: 2.2.1

Type: Bug Priority: Major
Reporter: mshaffer55 Assignee: Martin Grebac
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 525
Tags: incomplete

 Description   

In a web services (Metro) environment, in which Unmarshaller instances are held
across requests, the JAXB objects delivered to the web service implementations
are retained by the Unarshallers after the request has been completed. These
objects are not released until they are replaced by those for another request.

Note that this is very similar to a recently fixed defect with Marshallers:

https://jaxb.dev.java.net/issues/show_bug.cgi?id=519



 Comments   
Comment by Martin Grebac [ 11/Sep/09 ]

Hi, would you please provide a testcase for this one? Thanks.

Comment by Martin Grebac [ 06/Oct/10 ]

incomplete for a long time, closing

Comment by jherbers [ 04/Mar/11 ]

Is there a workaround for this issue? We're hitting this with jdk 1.6.0_20 which includes 2.1.10 (appears the latest jdk _24 also does). Is there a way to cause UnMarshaller to release the resources after it's done processing the xml?

Comment by ndjensen [ 09/Jul/14 ]

I think this should be reopened and addressed. We have encountered this too due to pooling unmarshallers. The JAXB guide suggests pooling unmarshallers to boost performance: https://jaxb.java.net/guide/Performance_and_thread_safety.html

Furthermore, the same kind of issue was fixed with marshallers so why are unmarshallers not also fixed? https://java.net/jira/browse/JAXB-843

Comment by peddapola [ 21/Apr/16 ]

work around for this issue is, instead of retaining unmarshaller, retain only JAXBContext in static way.

and create Unmarshaller every time, creating Unmarshaller from static JAXBContext is not a big performance hit.

Creating JAXBContext is very expensive, not Unmarshaller.





[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: 16/Apr/16

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"






[JAXB-973] generated code should be compilable with '-Xdoclint:all' Created: 07/Aug/13  Updated: 31/Mar/16  Resolved: 26/Sep/14

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

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: Lukas Jungmann
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk8


Issue Links:
Duplicate
is duplicated by JAXB-1023 Java SE 8: generated Javadoc comments... Resolved

 Description   

-have a schema
-run xjc on it to generate jaxb sources
-run javac -Xdoclint:all on the generated code

=> error(s) appear(s), ie: "error: bad use of '>'"



 Comments   
Comment by puce [ 17/May/14 ]

+1

Comment by Lukas Jungmann [ 26/Sep/14 ]

https://java.net/projects/jaxb/sources/v2/revision/9fc7d2d05252815cc978ca2973d9b700afaa475d

Comment by schrepfler [ 31/Mar/16 ]

Are we sure this is actually working? I have jaxb 2.2.11 on my maven managed dependencies, I have JDK8u77 (OSX) I even explicitly added jaxb 2.2.11 to the maven-javadoc-plugin additionalDependencies just to try and override any JDK internal jaxb. Yet, I still get

[ERROR] /Users/schrepfler/Documents/sources/project-api/project-web/src/main/java/com/company/project/importmodel/TxGame.java:40: error: bad use of '>'
[ERROR] *         &lt;element ref="{}drawDescId"/>




[JAXB-988] Add a new command line option to xjc for activating @XmlElementWrapper Created: 06/Nov/13  Updated: 18/Mar/16

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

Type: Improvement Priority: Trivial
Reporter: yossico Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Tags: optimization, xjc

 Description   

Currently xjc creates a wrapper class as a container for a collection. This generates verbose code that is quite difficult to use.
The new CLI option will eliminate these wrapper classes and instead will make use of @XmlElementWrapper.
There are some implementations out there for doing this kind of optimization (e.g., https://github.com/dmak/jaxb-xew-plugin) but it seems much more natural for xjc to support it.



 Comments   
Comment by puce [ 18/Mar/16 ]

This issue is now 3 years old. Any update?





[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-934] MarshallerImpl checks for UTF-8 in a case sensitive manner Created: 17/Dec/12  Updated: 11/Mar/16

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

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

Windows 7 64-bit, JDK 1.7.0_09


Attachments: Java Source File MarshallerImplEncodingCaseSensitivityTest.java     Java Source File TestObject.java    
Tags: encoding, marshaller, utf-8

 Description   

When establishing an XmlOutput writer via the createWriter method and also when creating a CharacterEscapeHandler via the createEscapeHandler method, MarshallerImpl checks the desired encoding against the values "UTF-8" and "UTF" (respectively) in a case sensitive manner (equals instead of equalsIgnoreCase and startsWith instead of encoding.toLowerCase().startsWith("utf") or something similar). This causes the marshaller to behave differently when the JAXB_ENCODING is set to UTF-8 or utf-8. Specifically, when utf-8 encoding is specified on the marshaller a NioEscapeHandler is used which unnecessarily escapes certain UTF-8 characters. The W3C Recommendations for XML 1.0 mention that encoding names should be matched in a case insensitive manner (see http://www.w3.org/TR/2006/REC-xml-20060816/#charencoding).

I've attached a small junit test which exercises the issue.



 Comments   
Comment by Dmitry Katsubo [ 11/Mar/16 ]

The problem is also valid for JAXB 2.2.11.





[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-829] schemagen and xjc should add 'if-exists' to bindings when generating an episode file Created: 13/Apr/11  Updated: 03/Mar/16

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

Type: Improvement Priority: Major
Reporter: matunos Assignee: Martin Grebac
Resolution: Unresolved Votes: 23
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When schemagen or xjc generates an episode file (via the -episode command-line argument; or in the case of the schemagen ant task, the episode attribute), the resultant file should set the 'if-exists' attribute on the 2nd-level bindings element.

Rationale: When generating an episode file, you may be generating bindings for multiple namespaces at once (especially if you're using schemagen and adding the episode file to your META-INF section of a jar file). If you then try to consume that bindings file via xjc (as documented at http://weblogs.java.net/blog/2006/09/05/separate-compilation-jaxb-ri-21), it will fail if your input schema doesn't have references to all of the namespaces included in the episode file. At least, it will fail if you're using the Ant xjc task, I haven't tried from the command line.

However, if the bindings had 'if-exists' set on them, the xjc task would simply keep going (the code that checks for this attribute is in SCDBasedBindingSet::Target::apply).

Concise example:

Output is currently generated like this:

<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns" xmlns:tns="http://example.com/SomeSampleNamespace/">
<schemaBindings map="false"/>
<bindings scd="tns:SampleElement">
<class ref="com.example.sample.SampleElement"/>
</bindings>
/.../
</bindings>
</bindings>

If it was instead this (note the if-exists on the bindings with scd attribute):

<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns" xmlns:tns="http://example.com/SomeSampleNamespace/" if-exists="">
<schemaBindings map="false"/>
<bindings scd="tns:SampleElement">
<class ref="com.example.sample.SampleElement"/>
</bindings>
/.../
</bindings>
</bindings>

Then the xjc task would ignore any unused bindings when processing it with the -b or from a jar file's META-INF. I think this would be the desired action when using bindings generated as an episode file.



 Comments   
Comment by famod [ 27/Jul/11 ]

I too stumbled upon this issue.

We have multiple xsd-files with individual namespaces that are used by multiple wsdl files that also have individual namespaces. Each wsdl is using only a subset of the xsd files.
In that scenario I tried using the generated episode file for wsdl2java (via maven) and failed because of this issue.

I ended up creating my own bindings-file with if-exists in place.

Btw: Finding "if-exists" in the code (SCDBasedBindingSet) was the last resort for me. I did not find this feature in the Jaxb documentation.

Comment by cpalm [ 27/Feb/13 ]

+1 for this.
Without the if-exists attribute episodes are pretty much useless for most non-trivial use cases.

Comment by bdrx [ 10/Nov/14 ]

Any progress on this feature?

Comment by benerridge [ 03/Mar/16 ]

Still no progress?





[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-1066] XJC fails on RELAXNG_COMPACT with NPE Created: 26/Feb/15  Updated: 09/Feb/16

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;
}




[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-994] Support for XML Schema 1.1 Created: 16/Dec/13  Updated: 05/Jan/16

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

Type: New Feature Priority: Major
Reporter: frocar Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support for XML Schema 1.1 would be awesome.
Especially things like assertions, conditional includes.



 Comments   
Comment by gideon_k [ 05/Jan/16 ]

We recently ran into this as well from a set of vendor provided schemas (proprietary)
Manually removing the <xs:assert> elements as as well as changing some header info allowed xjc to output java





[JAXB-810] Deploy source code of JAXB 1.x to the central maven repository Created: 24/Jan/11  Updated: 29/Dec/15  Resolved: 29/Dec/15

Status: Closed
Project: jaxb
Component/s: runtime, xjc
Affects Version/s: JWSDP1.6 (JAXB1.0.5)
Fix Version/s: None

Type: Task Priority: Minor
Reporter: lexi Assignee: lexi
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We have several applications which are based on JAXB 1.x. We've got JAXB 1.x addons, extensive usage of jaxb-impl etc., it's really a very tight integration.

At the moment JAXB 1.0.6 is deployed to the central maven repo, but there is no source or javadocs code available. There's also no source code or javadocs for jaxb-api 1.0 as well.

I would really like to have a complete valid deployment of JAXB 1.x in the central maven repo (with sources and javadocs). POMs are also not available for every artifact (i.e. dependency management is deficient).

If you're OK with that, I can overtake this issue, create or modify POMs and deploy the following artifacts:

  • jaxb-api 1.0.MR1
  • jaxb-impl 1.0.6.MR1
  • jaxb-libs 1.0.6.MR1
  • jaxb-xjc 1.0.6.MR1

I can do this via sonatype, but I will need your OK to upload the artifacts in the following groupIds:

  • com.sun.xml.bind (for jaxb-impl, jaxb-libs and jaxb-xjc)
  • javax.xml.bind (for jaxb-api)

In order not to influence existing versions, I'll have to deploy new versions (like 1.0.6.MR1 or 1.0.MR1).

If you are fine with my suggestion, please comment and assign this issue to me.

Thank you!



 Comments   
Comment by Martin Grebac [ 25/Jan/11 ]

Sure, go ahead. I think it would be good if you first commit the poms to svn - that way we can review and update the info there if required.
Also, be aware that in maven notation, 1.0.6 is higher version than 1.0.6.MR1, and same goes for 1.0 vs 1.0.MR1. (Found it the hard way with 2.2.1.1 release).
Recently when I had to release an update of jaxb 2.2.3 I solved it by releasing '2.2.3-1' version which maven considers higher than 2.2.3. So I'd suggest you do the same and use 1.0.6-1 / 1.0-1 versions as well.

Comment by lexi [ 26/Jan/11 ]

I've received deployemnt roles for javax.xml.bind and com.sun.xml.bind:

https://issues.sonatype.org/browse/OSSRH-1233
https://issues.sonatype.org/browse/OSSRH-1235

Comment by lexi [ 26/Jan/11 ]

Hi Martin,

I've started with jaxb-api. Would you mind taking a look at the POM?

http://java.net/projects/jaxb/sources/version1/show/trunk/jaxb-ri/api

Should id CDDL/GPL license header to the source files?

Bye,
/lexi

Comment by Martin Grebac [ 01/Feb/11 ]

I just found out that maven central has jaxb-api artifacts of versions 1.0.1 and 1.0.5 (oh well). In this case, to release higher-versioned artifacts I think it would be better to keep the api version in sync with the impl package - use 1.0.6-1 for both api and impl artifacts. Would it work for you?

Comment by lexi [ 02/Feb/11 ]

Maybe just 1.0.6? It's neither in here

http://download.java.net/maven/2/javax/xml/bind/jaxb-api/

nor in here:

http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/

I've updated version 1.0.6 and organisation name to "Oracle Corporation" (as it was in few other poms). Would you please recheck and give me green light? I'll release this one and go on with other artifacts then.

Comment by Martin Grebac [ 03/Feb/11 ]

OK, 1.0.6 is fine as well. Thanks for taking care of this.

Comment by lexi [ 06/Feb/11 ]

JAXB API 1.0 released under the version 1.0.6:

http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/1.0.6/

I'll continue with further artifacts.

Comment by lexi [ 29/Dec/15 ]

I'm no longer interested in this.





[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-1000] com.sun.xml.bind.v2.ClassFactory has memory leak Created: 28/Jan/14  Updated: 19/Dec/15  Resolved: 08/Sep/14

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

Type: Bug Priority: Critical
Reporter: herman.bovens Assignee: Iaroslav Savytskyi
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7



 Description   

This error is seen in tomcat 7 logs:

SEVERE: The web application [/secportal] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@301013d6]) and a value of type [java.util.WeakHashMap]

This is caused by JAXB creating but never clearing a ThreadLocal of type ClassFactory.



 Comments   
Comment by herman.bovens [ 28/Jan/14 ]

Apparently there was JAXB-831 for an earlier version, but it seems it was never really resolved. I can't reopen that bug.
I don't know if it's possible at all to create a test case for it. If no thread pooling is done, this isn't really an issue, but it is in application servers like Tomcat.

Comment by Iaroslav Savytskyi [ 29/Jan/14 ]

You are absolutely right. Unfortunately JAXB doesn't have any chance to clean up caches. Simply because in API we don't have any 'finalization' process.

To avoid this bug Martin changed com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl signature and make is closeable. So in your code when you are done call close on your unmarshaller instance.

Thanks.

Comment by jhrobbin [ 21/May/14 ]

I am running into this issue and see that it has been reported several times over many years (JAXB-1000, JAXB-831, and JAXB-563).

Is this SEVERE warning something that can be ignored? Perhaps only affecting redploy of a war to Tomcat, where the previous classloader cannot be GC'd. Or is it a true memory leak in a running application that needs to be resolved?

@Iaroslav, can you suggest how I might close the unmarshaller instance using Jersey/JAXB/Spring?

Comment by hartmannt [ 04/Sep/14 ]

I have the same issue with apache-tomcat-7.0.55 and JAXWS 2.2.8 which includes JAXB-2.2.7 (Java is 1.7.0_51b13 on Win7 64bit)

Aug 28, 2014 6:03:28 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/xxxx] created a ThreadLocal 
with key of type [com.sun.xml.bind.v2.ClassFactory$1] 
(value [com.sun.xml.bind.v2.ClassFactory$1@313f20fb]) 
and a value of type [java.util.WeakHashMap] 
(value [{class com...=java.lang.ref.WeakReference@486219fa, ...]) 
but failed to remove it when the web application was stopped. 
Threads are going to be renewed over time to try and avoid a probable memory leak.
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

@jhrobbin I think if you are using JAXB directly (have access to Unmarshaller instance) than you have a chance to deal with it. In other case - I don't have any other ideas.

Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

Until JAXB API change we are not able to deal with this.

Comment by gavenkoa [ 19/Dec/15 ]

I have same WARNING in catalina.log for Tomcat 8. After investigating issue with VidualVM I find nearest root to GC looks like:

this - value: org.apache.catalina.loader.WebappClassLoader #3
<- <classLoader> - class: com.sun.xml.bind.DatatypeConverterImpl, value: org.apache.catalina.loader.WebappClassLoader #3
<- <class> - class: com.sun.xml.bind.DatatypeConverterImpl, value: com.sun.xml.bind.DatatypeConverterImpl class DatatypeConverterImpl
<- theConverter (sticky class) - class: javax.xml.bind.DatatypeConverter, value: com.sun.xml.bind.DatatypeConverterImpl #1

Quick search shown that this problem comes from com.sun.xml.bind:jaxb-impl package. Because Java 7 include own implementation (JAXB RI) I just exclude that package from dependencies:

<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>$

{jersey.version}

</version>
<exclusions>
<exclusion>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
</exclusion>
</exclusions>
</dependency>

See more at http://stackoverflow.com/questions/11361036/javax-xml-bind-datatypeconverter-leaking-class-loaders/





[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-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: 1
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-952] JAXB fails to generate ValidationEvents for several errors Created: 19/Mar/13  Updated: 25/Nov/15

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

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

Any Java enviroment (seen on Windows and RHEL)



 Description   

With JAXB 2.0, you can set an EventHandler to inform JAXB whether or not to continue processing whenever it detects an error. However, the current implementation fails to properly generate this event on several occasions, amongst others:

While these errors perhaps should not stop the continued JAXB processing per se, the event should be generated and the event handler should be able to decide whether or not the processing should stop (as its documentation states).

I have some test cases and made some changes to the JAXB classes, so the fix is fairly trivial (and in some cases, for instance in DatatypeConverterImpl, the exceptions were already there, just commented out - was this from 1.0, before the ValidationEvent were introduced?)
Would like to share the changes with you if I can get git access.



 Comments   
Comment by Iaroslav Savytskyi [ 22/Mar/13 ]

Hi,

To be able to contribute please sign Oracle Contributor Agreement [1] (OCA), scan it and e-mail the result to oracle-ca_us(at)oracle.com. More about it you can read in [2].

[1]: http://www.oracle.com/technetwork/oca-405177.pdf
[2]: http://www.oracle.com/technetwork/oca-faq-405384.pdf

Comment by mapar70 [ 25/Nov/15 ]

I'm also running into this issue. Is there any update? Thanks.





[JAXB-172] More Schema Annotations/Documentation to Javadoc Created: 06/Jun/06  Updated: 16/Nov/15

Status: Reopened
Project: jaxb
Component/s: xjc
Affects Version/s: 2.0 FCS
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: vorburger Assignee: Martin Grebac
Resolution: Unresolved Votes: 49
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://jaxb.dev.java.net/servlets/ReadMsg?list=users&msgNo=5469


Attachments: XML File test.xsd    
Issue Links:
Duplicate
is duplicated by JAXB-839 More Schema Annotations/Documentation... Resolved
Issuezilla Id: 172

 Description   

As discussed on the "Schema Annotations/Documentation to Javadoc" thread on
users@jaxb.dev.java.net (see
https://jaxb.dev.java.net/servlets/ReadMsg?list=users&msgNo=5469) :

>> If you find cases where it doesn't work as you expected,
>
> . not the same complexType's sequence/element* documentation (which
> I'd think you'd expect on the respective getters/setters, instead of
> that pretty useless "Gets the value of the ... property."), nor a
> simpleType's annotation/documentation that turns into a @XmlEnum
> public enum, where one would expect both JavaDoc of the class as well
> as the individual enum values, from the
> simpleType/restriction/enumeration/annotation/documentation.
> (Additionally maybe putting schema/annotation/documentation into
> package-info.java as JavaDoc; although not sure how to deal with one
> namespace schema in several .xsd... not sure how that looks in XSOM by
> the time you process this?)

Please let me know if you need more details, schemas or code - hoping above is
clear.

When you do commit code for this, I'd would be happy to try a nightly build and
provide feedback; please add a comment to this Bugzilla and we'll give the next
build a shot. Thanks!



 Comments   
Comment by kohsuke [ 16/Jun/06 ]

Created an attachment (id=105)
Schema I used to test the problem.

Comment by vorburger [ 21/Jul/06 ]

FYI: http://jira.codehaus.org/browse/XFIRE-507

Comment by kohsuke [ 24/Sep/07 ]

Also in this category is javadoc for enumeration values.

Comment by kohsuke [ 06/Feb/08 ]
      • Issue 431 has been marked as a duplicate of this issue. ***
Comment by kohsuke [ 06/Feb/08 ]

issue #431 that was marked as a duplicate for this had 25 votes on its own, so
this appears to be a highly requested feature.

Comment by Aleksander Adamowski [ 22/Oct/09 ]

CCing myself (Bugzilla doesn't allow without a comment).

Comment by dkulp [ 22/Oct/09 ]

This is also the blocker for a CXF issue:

https://issues.apache.org/jira/browse/CXF-2486

Comment by skells [ 26/Oct/09 ]

I have a plugin that adds documentation to the getters, setters and the fields,
that works withthe placement that xmlspy used for the documentation. I would
not say that it is complete, but it works OK for the cases that we use.

Theer are some problems with it mostly related to the API the generate the
javadoc, and I would not say that the code is clean ....

I can share the code if anyone is interested in taking it forward

Comment by dkulp [ 26/Oct/09 ]

If you'd like to donate the code to CXF, we could certainly use it. CXF
already has a couple plugins to workaround XJC issues.

Just log a JIRA at:
https://issues.apache.org/jira/browse/CXF
and attach the code.

Comment by dkulp [ 11/Feb/10 ]

skells,

In CXF, we've recently setup a subproject to house additional XJC plugins
that the community finds useful. We'd love to have your contribution if the
offer still stands.

Comment by kpsdevi [ 11/May/11 ]

The schema is provided by the service provider and they have defined integer enumeration values with documentation but without names as given below.
<xsd:simpleType name="XYZCodeSimpleType">
<xsd:annotation>
<xsd:documentation>A data type for an enumeration of XYZ Codes.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="0">
<xsd:annotation>
<xsd:documentation>Undefined</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="1">
<xsd:annotation>
<xsd:documentation>Left</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="2">
<xsd:annotation>
<xsd:documentation>Right</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>

1) JAXB 2 has not generated classes for those enum types. So I added global bindings as given below

<jaxb:globalBindings typesafeEnumMemberName="generateName">

Then I was able to generate classes as given below with prefix "VALUE_" in the name, which was confusing as my enum values start with 0.

public enum XYZCodeSimpleType {

/**

  • Undefined
  • */
    @XmlEnumValue("0")
    VALUE_1("0"),

/**

  • Left
  • */
    @XmlEnumValue("1")
    VALUE_2("1"),

/**

  • Right
  • */
    @XmlEnumValue("2")
    VALUE_3("2");

2) So I have used external bindings to define name as given below.

<jaxb:bindings node="//xsd:simpleType[@name='XYZSimpleType']">
<jaxb:typesafeEnumClass>
<jaxb:typesafeEnumMember value="0" name="UNDEFINED" />
<jaxb:typesafeEnumMember value="1" name="LEFT" />
<jaxb:typesafeEnumMember value="2" name="RIGHT" />
</jaxb:typesafeEnumClass>
</jaxb:bindings>

With this external binding I was able to generate classes with names as given below but I lost the documentation which is there in the schema. Because of that I need to duplicate documentation as well in jaxb bindings which I don't want to.

public enum XYZCodeSimpleType {

@XmlEnumValue("0")
UNDEFINED("0"),
@XmlEnumValue("1")
LEFT("1"),
@XmlEnumValue("2")
RIGHT("2");

3) I looked at JAXB 2.2.3 source code and figured out the cause of this issue. Issue is in the method "buildCEnumConstants" of "com.sun.tools.xjc.reader.xmlschema.SimpleTypeBuilder". The documentation from schema is getting overwritten even when the javadoc is not specified in the bindings and getting nullified if there is no value in the bindings.

if( mem!=null )

{ name = mem.name; mdoc = mem.javadoc; }

So the above code should be modified as given below

if( mem!=null ) {
name = mem.name;
if (mem.javadoc!=null)

{ //Fix mdoc = mem.javadoc; }

}

I request you to fix this issue and release the update of JAXB2.2.3 as soon as possible.

Comment by Martin Grebac [ 30/May/11 ]

Unfortunately have to close this one as incomplete because the original thread wast lost and I'm not able to grasp the roots of the bug here. Recently I fixed one javadoc issue with enums thanks to a specific submission, but other than that I think I need more info on what is requested here. Feel free to reopen if you have that. Thanks.

Comment by os111 [ 31/May/11 ]

Not sure why this was closed?

As I understood it the original intent was to include documentations from the XSD in the Javadoc of autogenerated code.

For example the following from schema snippet

<attribute name="documentedAttribute" type="string" use="optional">
<annotation>
<documentation>This attribute can be either 1, 2, or 3.</documentation>
</annotation>
</attribute>

Generates the following javadoc:

/**

  • Gets the value of the documentedAttribute property.
  • @return
  • possible object is
  • {@link String }
  • */

The javadoc should also include the schema's documentation.

Comment by vorburger [ 01/Jun/11 ]

JAXB-839 (new) created to avoid this being swiped under the carpet.

Comment by Martin Grebac [ 01/Jun/11 ]

Understood, thanks for the clarifications here.

Comment by marcelstoer [ 20/Oct/13 ]

Just found here thanks to a really helpful SO answer.

Comment by kwakeroni [ 12/Mar/15 ]

Just wanted to indicate that the reverse might also be useful: include javadocs as annotation/documentation in the generated xsd.

Comment by duncant [ 16/Nov/15 ]

This would be extremely useful, in both directions. Hoping for a fix!





[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-1001] Cannot pass language for generated Javadoc Created: 28/Jan/14  Updated: 28/Oct/15

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

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


 Description   

Content of Javadoc depends on the locale of the developer machine. E.g., in my case it is de_DE but I need the language of the generated content to be in English. I cannot pass -Duser.language=en. Please add as switch to make this controlable.



 Comments   
Comment by Iaroslav Savytskyi [ 29/Jan/14 ]

I think the easiest way is to change user locale to English just before calling xjc. And if you need - you can switch it back afterwards.

Comment by Iaroslav Savytskyi [ 29/Jan/14 ]

If this solution is acceptable I'm going to close the issue.

Comment by Michael Osipov [ 29/Jan/14 ]

Actually, I can't. I do not use xjc directly but the JAXB Maven Plugin. I do not intend to modify Maven's environment just for one plugin.

Comment by puce [ 18/Mar/14 ]

Any workaround for this in a Jenkins started Maven build using the org.jvnet.jaxb2.maven2:maven-jaxb2-plugin Maven plugin?

Comment by puce [ 17/May/14 ]

This issue still persists and is very annoying. Any news?

Comment by Michael Osipov [ 17/May/14 ]

puce, no changes from Oracle.

Comment by lexi [ 03/Oct/14 ]

I've added the feature in the `maven-jaxb2-plugin`, see [MAVEN-JAXB2-PLUGIN-87].
Would be actually nice if XJC would have an option to switch the locale. I don't know how to do it with the command-line XJC. When calling it via java -jar then it should be possible via -Duser.language and co., but for the xjc.exe? No idea.

Comment by e11k [ 28/Oct/15 ]

How can I change the locale just before calling xjc? I've tried exporting environment variables such as:

export JAVA_ARGS="-Duser.language=en -Duser.region=US"
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"

but the xjc command still generates source files with my machine's locale. Any ideas what I should try next?





[JAXB-563] Possible memory leak in com.sun.xml.bind.v2.ClassFactory Created: 31/Oct/08  Updated: 12/Oct/15  Resolved: 04/Nov/08

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.0.5
Fix Version/s: 2.1.9

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

Operating System: All
Platform: All


Issuezilla Id: 563

 Description   

Hi,

We have a JAX-WS 2.0 based web service endpoint deployed on a Java EE
Application server. This web service endpoint is packaged in a .war file and
deployed. After few deployment and undeployment cycles we see that the
application classloader doesn't get garbage collected.

After profiling the application we figured out that JAXB 2.0's
com.sun.xml.bind.v2.ClassFactory has a threadlocal which keeps a WeakHashMap
with Class object as the key and its Constructor as the value. Since the
Constructor has an implicit reference to Class object, the key(Class object)
would never get GC'ed and hence the Application Classloader.

Since, in an Application server the Web worker threads are pooled, threadlocal
entries would remain throughout the run resulting in a leak.



 Comments   
Comment by Martin Grebac [ 04/Nov/08 ]

This issue was fixed in 2.1.9 already.

Comment by Martin Grebac [ 04/Nov/08 ]

setting tm

Comment by jonseymour [ 28/Feb/11 ]

I don't believe the issue reported in this report was actually fixed in 2.1.9.

There was an issue - JAXB-538 - regarding ThreadLocal use in a different class, but the source code for ClassFactory has not changed between 2.1.7 and 2.2.3 and so the issues relating to the ThreadLocal in ClassFactory would appear to remain.

The basic problem is that unless ThreadLocal.remove() is called there is no guarantee that the values in a java.lang.ThreadLocal.ThreadLocalMap will be expunged. As a result, an application's classloader can be pinned across each restart, resulting in significant memory loss and therefore a degradation of the availability of any J2EE application container hosting applications that contain an implementation of jaxb-impl.jar and need to be restarted frequently.

I will try to produce a test case that demonstrates the issue and submit a new report (or append it to this one if it is re-opened).

jon.

Comment by Martin Grebac [ 01/Mar/11 ]

Thanks, feel free to reopen this one with testcase.

Comment by a_gallardo [ 12/Oct/15 ]

I don't understand why this has been closed. It looks a lot like JAXB-1000, which is marked as "won't fix". It took me quite a while to realize that this, in fact, has not been fixed.

I'm currently seeing this issue in a relatively complex application, using jaxb as a 3rd-transitive-grade dependency.





[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-1009] JAXB spec should be updated to support new JDK8 Date/Time apis Created: 01/Apr/14  Updated: 28/Sep/15

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

Type: Improvement Priority: Critical
Reporter: Martin Grebac Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by puce [ 28/Sep/15 ]

There should be helper classes to make customization as simple as for java.util.Calendar:

https://jaxb.java.net/guide/Using_different_datatypes.html

https://docs.oracle.com/javase/8/docs/api/javax/xml/bind/DatatypeConverter.html





[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-910] Ant XJC task corrupts JVM security configuration Created: 20/Jul/12  Updated: 08/Aug/15  Resolved: 19/Aug/14

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

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

Windows Server 2003, Ant 1.8


Tags: metro2_2_1-waived

 Description   

An Ant script that includes an XJC task will corrupt future tasks that require the security library.

I have the following in my build script:

<xjc binding="Components/Development/bindings.xjb" package="$

{xjc.package}

" header="false" destdir="$

{project}/${xjc.source_directory}" extension="true" removeoldoutput="true">
<schema dir="${project}

/$

{xjc.schema_directory}

" includes="$

{xjc.schema_includes}

"/>
<produces dir="$

{source_directory}

/$

{xjc.package_directory}

" includes="*/"/>
</xjc>

Further down, as part of the deployment, I have the following call to update the application database:

<sql driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" url="jdbc:sqlserver://$

{common.database_server_name}

:$

{common.database_server_port}

;databaseName=$

{database_name}

$

{common.database_name_suffix}

" userid="GatewayOwner" password="$

{database.owner_password}

" src="$temp_script.sql" encoding="UTF-8" autocommit="true" delimiter="GO" delimitertype="row" strictDelimiterMatching="false">
<classpath>
<filelist refid="library.SQL_Server_JDBC"/>
</classpath>
</sql>

This causes an exception:

C:\gateway\source\Deployment\database.xml:124: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server
by using Secure Sockets Layer (SSL) encryption. Error: "RSA premaster secret error". ClientConnectionId:54c63693-c8e3-42a5-84c8-83dc4638682c
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1667)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1668)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1323)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:991)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:827)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:1012)
at org.apache.tools.ant.taskdefs.JDBCTask.getConnection(JDBCTask.java:370)
at org.apache.tools.ant.taskdefs.SQLExec.getConnection(SQLExec.java:942)
at org.apache.tools.ant.taskdefs.SQLExec.execute(SQLExec.java:614)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.taskdefs.Sequential.execute(Sequential.java:68)
at net.sf.antcontrib.logic.IfTask.execute(IfTask.java:217)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:154)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.taskdefs.Sequential.execute(Sequential.java:68)
at net.sf.antcontrib.logic.ForEach.executeSequential(ForEach.java:178)
at net.sf.antcontrib.logic.ForEach.execute(ForEach.java:254)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
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:811)
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)
Caused by: javax.net.ssl.SSLKeyException: RSA premaster secret error
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:97)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:744)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:238)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1170)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1197)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1181)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1618)
... 83 more
Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)
... 92 more

If I remove the XJC task, everything works fine.



 Comments   
Comment by Iaroslav Savytskyi [ 24/Jan/13 ]

Hi,

To be hones this is very strange bug. How can I reproduce it? Can you please provide small test case?

Thank you.

Comment by Kevin Dean [ 30/Jan/13 ]

Creating a replicable case is proving harder than I anticipated. A simple script with just XJC and a call to SQL Server works just fine; the version of my build script that was current at the time I posted this case fails with the above error unless I comment out the XJC call. When I use the latest version of my build script, which isn't appreciably different from the original, it works fine.

I don't know when I will have time to narrow down my test case so I'll keep this open for a while.

Comment by mkm13 [ 19/Aug/14 ]

I can confirm this problem. After the xjc-task, ivy:resolve (via https) reliably fails with the message "Server access Error: RSA premaster secret error".

Our workaround is to fork xjc like this, which avoids the corruption:

<target name="xjc">
  <java classname="org.apache.tools.ant.Main" fork="true" clonevm="true" dir="${basedir}">
    <arg value="-f" />
    <arg value="${basedir}/build.xml" />
    <arg value="xjc_run" />
  </java>
</target>

<target name="xjc_run">
  <!-- do actual xjc magic here -->
</target>
Comment by Iaroslav Savytskyi [ 19/Aug/14 ]

Thanks for providing workaround.
I'm going to close the issue until will have reproducible testcase.

Comment by mkm13 [ 20/Aug/14 ]

I thought I provided just that
Trying an ivy:resolve over https after using xjc reliably exhibits the problem with Java 1.6.0_41.
With the java.net repo (https://maven2-repository.java.net/) it should be possible to reproduce this.

Comment by jimsingh [ 08/Aug/15 ]

I also ran into a situation where JVM security stopped working after a call to the XJC task in ant and I believe i've found the root cause and implemented a fix, at least for my use case.

Tasks executed after XJC could not load security providers from the extensions libraries (jre/lib/ext) and instead would throw a ClassNotFoundException. In fact, nothing that hadn't already been loaded from jre/lib/ext would load after a call to XJC. After looking into it further, it seems someone had called .close on the ExtClassLoader. Oracle made URLClassLoader closable in JDK1.6 and 1.7 in a micro release and the XJC base task, com.sun.istack.tools.ProtectedTask, was walking the class loader chain and calling close on all class loaders – including extension – when the task completed. You can see this on line 128 and 155 of ProtectedTask.java http://grepcode.com/file/repo1.maven.org/maven2/com.sun.xml.bind/jaxb-xjc/2.2.10/com/sun/istack/tools/ProtectedTask.java/

My solution to this problem was to dynamically change ExtClassLoader before xjc could get a hold off it and disable the close method by replacing the URLClassPath object instead with a subclass I created that does not accept closing. The right fix is probably modify ProtectedTask to not close instances of Launch$ExtClassLoader.





[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: 27/Jun/15

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.






[JAXB-430] JAXB Validation Without Schema Created: 15/Oct/07  Updated: 12/Jun/15

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.1.5
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: shelleyb Assignee: Martin Grebac
Resolution: Unresolved Votes: 17
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 430

 Description   

Enhance JAXB to allow validation based on annotations, without requiring a schema.

One of the benefits of JAXB 2 is that a schema is not required; annotating Java
classes alone allows for XML serialization/deserialization. With the deprecation
of the Unmarshaller.setValidating() in favor of the unmarshaller.setSchema()
method, however, validation is only available when an XSD is present. Ideally,
validation can occur during unarshalling (or marshalling) without a physical
schema file.



 Comments   
Comment by tuukkamustonen [ 07/Feb/11 ]

It's now year 2011 and this ticket was created roughly 2,5 years ago. No comments here, but seems like it has been discussed "many times". See at least http://stackoverflow.com/questions/3844701/jaxb-validation-of-xml-during-unmarshalling and http://old.nabble.com/Using-JAXB2-Commons-with-the-jaxws-maven-plugin--td29108017.html

Despite of this feature being (maybe) not implemented, updating the ticket with the current status of consideration wouldn't be a bad thing?

Comment by pastafarian [ 27/Jun/11 ]

+1 on the need for better annotation-based validation. Every time we make a change to our data objects, we (re)generate our XSDs from code and share them with other projects / clients.

Without better XML schema validation options, we might as well be using JSON

Comment by lennartj [ 04/Nov/11 ]

This is a rather important issue, since everyone using annotated POJOs - rather than XML schema - as the model source at present need to create their own custom validation for generated objects due to the lack of validation facilities for this scenario within JAXB.

Validation of JAXB structures should really be part of the JAXB family of tasks; otherwise we condemn project to using XSDs (as opposed to POJOs) as the data model source. POJO entities should also be first-class citizens, without the need to generate intermediary XML Schemas simply to enable some kind of validation).

... which implies we need to provide validation facilities without XML Schema.

Comment by cruelfate [ 13/Jan/12 ]

Indeed. I'm not looking for much .. heck I'd take something that only regarded XmlElement(required=true) so I wouldn't have to resort to this horror show:

Use Case

import javax.xml.bind.annotation.XmlElement;
import JaxbValidator.ValidationException;
import org.testng.annotations.Test;

public class JaxbValidatorTest {

    static class Llama {
        @XmlElement(required = false)
        private final String no;

        @XmlElement(required = true)
        private final String yes;

        public Llama(String no, String yes) {
            super();
            this.no = no;
            this.yes = yes;
        }
    }
    @Test
    public void validateRequired() {
        try {
            Llama o = new Llama("a", "b");
            // THE MAIN EVENT - see if 'required' is honored
            JaxbValidator.validateRequired(o, Llama.class);
        } catch (ValidationException e) {
            assert false : "Should not have thrown validation exception.";
        }
        try {
            Llama o = new Llama(null, null);
            // Again - see if 'required' is honored
            JaxbValidator.validateRequired(o, Llama.class);
            assert false : "Should have thrown validation exception for 'yes'";
        } catch (ValidationException e) {
            assert e.getMessage() != null: "Expected validation message, got null." ;
        }
    }
}

Implementation

import java.lang.reflect.Field;
import java.lang.reflect.Method;
import javax.xml.bind.annotation.XmlElement;
import org.apache.log4j.Logger;

/**
 * oh so minimal consideration of JAXB annotation
 */
public class JaxbValidator {

    private static final Logger LOG = Logger.getLogger(JaxbValidator.class);

    public static class ValidationException extends Exception {
        public ValidationException(String message, Throwable cause) {
            super(message, cause);
        }
        public ValidationException(String message) {
            super(message);
        }
    }

    /**
     * Enforce 'required' attibute.
     *
     * Requires either no security manager is used or the default security manager is employed. 
     * @see {@link Field#setAccessible(boolean)}.
     */
    public static <T> void validateRequired(T target, Class<T> targetClass)
        throws ValidationException {
        StringBuilder errors = new StringBuilder();
        Field[] fields = targetClass.getDeclaredFields();
        for (Field field : fields) {
            XmlElement annotation = field.getAnnotation(XmlElement.class);
            if (annotation != null && annotation.required()) {
                try {
                    field.setAccessible(true);
                    if (field.get(target) == null) {
                        if (errors.length() != 0) {
                            errors.append(" ");
                        }
                        String message = String.format("%s: required field '%s' is null.",
                                                       targetClass.getSimpleName(),
                                                       field.getName());
                        LOG.error(message);
                        errors.append(message);
                    }
                } catch (IllegalArgumentException e) {
                    LOG.error(field.getName(), e);
                } catch (IllegalAccessException e) {
                    LOG.error(field.getName(), e);
                }
            }
        }
        if (errors.length() != 0) {
            throw new ValidationException(errors.toString());
        }
    }

And yes ... it doesn't do deep inspection. I wasn't sure if JAXB handles cyclic graphs, so I didn't attempt recursion without knowing if I needed to detect loops.

Comment by roos [ 30/Oct/12 ]

Its 10/2012 now and still nothing.

Comment by ovy9086 [ 16/Jul/13 ]

now it's 2013... and still no updates on this. I just started with JAXB and in the first day I needed this and... BUMMER. Not available...

Comment by areami [ 16/Jul/13 ]

please have a look at https://github.com/whummer/jaxb-facets; they may have implemented this there

Comment by Iaroslav Savytskyi [ 16/Jul/13 ]

May be MOXy JAXB implementation can help.

http://www.eclipse.org/eclipselink/moxy.php

Comment by lennartj [ 16/Jul/13 ]

Actually, being able to validate XSDs generated from annotated POJOs in a simple
and useable form is still very important for JAXB. It is puzzling that this is not a
trivial operation in the year 2013.

My workaround has been the implementation in

<dependency>
    <groupId>se.jguru.nazgul.core.xmlbinding.spi.jaxb</groupId>
    <artifactId>nazgul-core-xmlbinding-spi-jaxb</artifactId>
    <version>1.5.0</version>
</dependency>

It generates schema from annotated POJOs and performs validation during marshalling and unmarshalling.

Comment by olmath [ 12/Jun/15 ]

It's now year 2015. This jira issue is open since 2007. Is there a chance to have this improvement implemented in a near future ?
Could you please update this ticket with the current status of consideration ?





[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-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-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-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-614] JAXB generates illegal XML characters Created: 18/Mar/09  Updated: 13/May/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ranboii Assignee: Martin Grebac
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=59068


Issuezilla Id: 614

 Description   

Some characters (such as 0x1f) that are legal in Java strings are illegal in XML
(and XML does not provide a way to escape such characters to make them legal).
When JAXB marshals objects that contain these illegal characters in strings, it
currently includes those characters in the XML, thus generating invalid XML.
Later when it comes time to unmarshal the XML back into objects, an exception
is thrown due to the illegal character. This could spell disaster for a system
that, for example, write objects as XML or fast infoset into a database and then
cannot read them back out later.
JAXB should not be allowed to ever generate invalid XML. If an exception is
going to be thrown, it should be thrown when generating the XML, not when trying
to decode it. So a minimum requirement should be that JAXB throw an exception
when attempting to generate invalid XML, or that it should at least strip out
the characters that would be invalid (or have a property on the marshaller that
allows this to be set).
However, JAXB is also supposed to be converting an object to XML and back
losslessly, so an even better solution would be to do a consistent kind of
escaping of the offending characters in such a way that when the strings are
marshalled back in, the original string can be reconstructed.
It should be straightforward to come up with an escaping scheme that
guarantees lossless translation from Strings to XML and back (e.g., convert 0x1f
to "\u001f" or "JAXB_UNICODE_001f" or something unlikely to appear by
accident). I don't know that it's possible to guarantee that XML generated
through some other process won't ever be accidentally interpreted as containing
"escaped" strings, but it can be made very unlikely.
Below is the simplest unit test I could come up with that exposes the problem.

public void testBinary() throws JAXBException

{ JAXBContext jxbc = JAXBContext.newInstance(OneString.class); OneString orig = new OneString(); orig.setString("\u001f"); ByteArrayOutputStream s = new ByteArrayOutputStream(); Marshaller m = jxbc.createMarshaller(); m.marshal(orig, s); String xml = s.toString(); OneString result = (OneString) jxbc.createUnmarshaller().unmarshal(new ByteArrayInputStream(xml.getBytes())); assertEquals("\u001f", result.getString()); }

@XmlRootElement(name = "oneString")
private static class OneString {
String string;
public String getString()

{ return string; }

public void setString(String s)

{ this.string = s; }

}

There are workarounds for this issue, e.g., at http://tinyurl.com/cq9u58; but as
it currently exists, this is a dangerous bug that can make data unreadable.



 Comments   
Comment by ranboii [ 18/Mar/09 ]

Actually, I meant to post this URL demonstrating a workaround:
http://blog.lesc.se/2009/03/escape-illegal-characters-with-jaxb-xml.html
which at least illustrates I'm not the only one to have seen this issue. Of
course, a fix would be much better than a workaround.

Comment by Pavel Bucek [ 02/Apr/09 ]

partially fixed in trunk.

IllegalArgumentException should be thrown whether you try marshal string with
invalid xml content. But there is a catch. Invalid characters can occur when
UTF-32 is used (it happens because of encoding its characters to UTF-16 which is
java native encoding).

Anyway, it is still far from perfect and needs some additional work.

Adjusting priority and assigning to myself.

Comment by Pavel Bucek [ 02/Apr/09 ]

reassigning

Comment by mnsam [ 11/May/12 ]

As per the workaround, is this the list of unsupported characters ?

"\u0000\u0001\u0002\u0003\u0004\u0005" +
"\u0006\u0007\u0008\u000B\u000C\u000E\u000F\u0010\u0011\u0012" +
"\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001A\u001B\u001C" +
"\u001D\u001E\u001F\uFFFE\uFFFF"

Comment by aldaranalton [ 13/May/15 ]

What about an option to remove automatically all not printable characters?

str.replaceAll("\\P{Print}", "");




[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-546] Custom IDResolver gets wrong target type with IDREF collections Created: 02/Sep/08  Updated: 21/Apr/15

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.7
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Java Source File Reflect.java    
Issuezilla Id: 546
Tags: 2_2_8

 Description   

The issue is described in the forum:
http://forums.java.net/jive/thread.jspa?threadID=45481&tstart=120

When using IDREFed collections:

@XmlIDREF
Set<Y> ySet;

the resolve() method of a custom IDResolver gets Object.class as targetType,
but it should be Y.class. This results on wrong ID resolving.

If I use an empty derived class instead:

class YSet extends HashSet<Y> {}
...
@XmlIDREF
YSet ySet;

then I get the right targetType in the resolve() method.



 Comments   
Comment by Pavel Bucek [ 04/Mar/09 ]

Would you please provide the schema file and/or reproducible testcase? Thanks in
advance.

Comment by Pavel Bucek [ 06/Mar/09 ]

I agree with Wolfgang - see attached mail:

(workaround available and this is not part of jsr222 -> adjusting priority to P4)

================================================
The reason resolve() is called with Object.class for the target type when
a field of some parameterized type is annotated with @XmlIDREF is
simply because that's the way Java works. At runtime, Set<Foo> is
erased to Set<? extends Object> or Set<?>. See this simple test
program and its output:

mport java.util.*;
import java.lang.reflect.*;
public class Reflect {
public List<String> sList;
public ArrayList<String> sArrayList;
private static void dr( String fname ) throws Exception {
Class reflectClass = Reflect.class;
Field sListField = reflectClass.getField( fname );
System.out.println( sListField.toString() );
Class sListClass = sListField.getType();
System.out.println( sListClass.toString() );
if( sListClass instanceof GenericDeclaration )

{ TypeVariable<?>[] typeVars = sListClass.getTypeParameters(); System.out.println( "generic " + typeVars.length + " parameter" ); Type[] types = typeVars[0].getBounds(); System.out.println( "bounds " + types.length + ": " + types[0].toString() ); System.out.println( "name " + typeVars[0].getName() ); }

}
public static void main( String[] args ) throws Exception

{ dr( "sList" ); dr( "sArrayList" ); }

}
=========================================
public java.util.List Reflect.sList
interface java.util.List
generic 1 parameter
bounds 1: class java.lang.Object
name E
public java.util.ArrayList Reflect.sArrayList
class java.util.ArrayList
generic 1 parameter
bounds 1: class java.lang.Object
name E
==========================================

The code in com/sun/xml/bind/v2/runtime/reflect/Lister.java,
latest release, around line 140 seems to indicate that the
declared parameter type is available, but perhaps I've
not understood it in full.

The ID Resolver is an extension of Sun's implementation.
The official JAXB documentation doesn't contain any hint for
this; as far as I know, Kohsuke's blog is the only place where this
feature is published.

The original reporter has found a reasonable workaround by
declaring a dedicated wrapper type for the parameterized
container class, so that ID resultion into separate namespaces
is applicable for IDREFs in containers as well.

================================================

Comment by Pavel Bucek [ 06/Mar/09 ]

I forgot change priority...

Comment by ktcorby [ 06/Mar/09 ]

I think it would be much more convenient if there was an additional parameter to
the annotation, like @IDRef(targetType=String.class) or possibly an additional
annotation (@IDRefType(String.class)), so that the resolver could map to the
proper type at runtime.

I realize this may not be a possible short-term solution, but I wanted to
mention it.

Comment by larsrc [ 07/Aug/09 ]

Created an attachment (id=322)
Update example source showing the old example plus a part that shows that getGenericType can find the right type.

Comment by larsrc [ 07/Aug/09 ]

Using getGenericType() instead of getType() allows you to find the actual type.
With getType(), you're affected by erasure.

Comment by realsonic3 [ 05/Sep/12 ]

Hello. Can you please tell can this issue be fixed? Thanks.

Comment by Iaroslav Savytskyi [ 11/Sep/12 ]

Hi,realsonic3,

As I see with "getGenericType" is looks optimistic. So we will try to add it to 2.2.7.

Comment by realsonic3 [ 26/Sep/12 ]

Sorry, but in which java version will be JAXB 2.2.7? Thanks a lot.

Comment by Iaroslav Savytskyi [ 26/Sep/12 ]

It's no need to wait for JDK integration. You can use JAXB as standalone application.

Comment by realsonic3 [ 12/Nov/12 ]

Can you please fill "Fix Version/s:" field?

Comment by realsonic3 [ 20/Jun/13 ]

Hello. Can you please update when this issue will be fixed? Thanks.

Comment by Iaroslav Savytskyi [ 21/Jun/13 ]

Hi,

I hope I'll be able to fix it in 2.2.8

Comment by realsonic3 [ 10/Sep/13 ]

Let me please update you. This bug causes a problem that two or more objects with same ID but different types are unmarshalled as one type.

Comment by realsonic3 [ 15/Oct/13 ]

Any chances it will be fixed in 2.2.8?

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

We are quite busy with maintenance now. So I can't promise.

Comment by realsonic3 [ 21/Apr/15 ]

Hi. Are there any chances to get the issue resolved?..





[JAXB-875] Import schema (via multiple transitive path) causes error of "'XxxType' is already defined", when episode feature comes in play. Created: 03/Jan/12  Updated: 21/Apr/15

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

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

Attachments: Java Source File NGCCRuntimeEx.java     Zip Archive schema-episode.2011-12-22_15-57.ComplexImports.zip    
Tags: episode, import, jaxb-xjc, metro2_2-waived, schema

 Description   

I'm using maven-jaxb2-plugin to generate Java classes from schema files, and want to put the schema files into different modules, using its episode feature.

The same set of schema files can be compiled altogether in one shot without issue. But when split them into two modules, the issue surfaces. The <import/> relationship among my schema files is comparatively complex.

The issue turns out to be rooted in the jaxb-xjc (Sun RI), the version I've tested is 2.2.4u1.

Please use the attached maven project to reproduce the issue. It's stemmed from a real project.

I've patched the class NGCCRuntimeEx in jaxb-xjc version 2.2.4u1. That patch is just the starting point of fixing the issue, and it works for me. It may not be the right/ultimate solution though. The basic idea is to enhance the ParserContext to remember what schemas have been imported.



 Comments   
Comment by phantom_john [ 03/Jan/12 ]

Error Stack Trace:

[ERROR] Error while parsing schema(s).Location [ jar:file:/C:/Workbench/Project/References/schema-episode/one/target/schema-episode-one-1.0.0.jar!/META-INF/schema/SC.types.xsd

{14,13}

].
org.xml.sax.SAXParseException: 'SCT' is already defined
at com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.java:180)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:175)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:178)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.checkDoubleDefError(NGCCRuntimeEx.java:150)
at com.sun.xml.xsom.impl.parser.state.Schema.action5(Schema.java:127)
at com.sun.xml.xsom.impl.parser.state.Schema.onChildCompleted(Schema.java:1287)
at com.sun.xml.xsom.impl.parser.state.NGCCHandler.revertToParentFromText(NGCCHandler.java:183)
at com.sun.xml.xsom.impl.parser.state.complexType.text(complexType.java:1634)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.processPendingText(NGCCRuntime.java:236)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:312)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.importSchema(NGCCRuntimeEx.java:258)
at com.sun.xml.xsom.impl.parser.state.importDecl.action0(importDecl.java:85)
at com.sun.xml.xsom.impl.parser.state.importDecl.leaveElement(importDecl.java:184)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:314)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.importSchema(NGCCRuntimeEx.java:258)
at com.sun.xml.xsom.impl.parser.state.importDecl.action0(importDecl.java:85)
at com.sun.xml.xsom.impl.parser.state.importDecl.leaveElement(importDecl.java:184)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.endElement(NGCCRuntime.java:314)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.util.SubtreeCutter.endElement(SubtreeCutter.java:112)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.endElement(CustomizationContextChecker.java:199)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.endElement(DOMForestScanner.java:140)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:255)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:92)
at com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:100)
at com.sun.tools.xjc.reader.internalizer.DOMForestParser.parse(DOMForestParser.java:104)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:267)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:128)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:168)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:157)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:518)
at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:376)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:172)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:118)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:45)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:35)
at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:22)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:282)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:147)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Comment by Niels Bertram [ 01/May/14 ]

Any chance someone can comment on "Applying" the patch? I have used the attached NGCCRuntimeEx.java sources and patched the xsom version 20130531 library. Then I rebuild JAXB-RI 2.2.7 (also tried 2.2.10-SNAPSHOT) and ran the provided test case. Does not seem to make any difference to fixing the problem described. This is a really anoying bug that pretty much renders JAXB inoperable for multi-episode compilation. If anyone has pointer this would be much appreciated.

Comment by maciej.bajolek [ 26/May/14 ]

I'm getting similar exception when I try to use MOXY provider to marshal dynamically XML to JSON.
The application loads multiple .xsd's that define in different targetNamespaces. The intention is to be able to use dynamic binding without a need of generating jaxb POJO classes using commandline xjc compiler nor maven-jaxb2 plugin.

From some reasons I cannot attach source code.

Comment by Niels Bertram [ 27/May/14 ]

I got the originally posted path to work with XSOM, JAXB 2.2.7 and also the 2.2.10-SAPSHOT. I documented the steps needed to apply it on GitHub. Maybe that helps anyone that runs into this problem.

Comment by Niels Bertram [ 17/Jan/15 ]

Hi Martin,

any chance we can coordinate a proper fix for this significant issue with the team that writes the xsom library? JAXB 2.2.11 is out and I find myself having to patch every new version, which really sucks. What does it take to fix this?

Kind Regards,
Niels

Comment by Michael Osipov [ 30/Jan/15 ]

Interesting to say that I have a similiar usecase with JAXB and the Maven JAXB2 Plugin which does work but the very same setup with wsimport leads to this error. Since there is no activity from Oracle, I presume either Oracle has abandoned this project or expect suffering users to pay $$$ for the fix.

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

No, no The project isn't abandoned.
Let me check what can I do with this.

Comment by Michael Osipov [ 03/Feb/15 ]

Can't wait to test a fix. That would probably solve a serious wsimport bug.

Comment by Niels Bertram [ 16/Apr/15 ]

Looks like JAXB is truly abandoned. The problem is within XSOM and that library is baked into the JAXB RI build process last time I checked. The original fix proposed by phantom_john fixes the issue. Will anyone care if I submit a pull request for XSOM and JAXB-RI to incorporate the patch documented at https://github.com/bertramn/xsom-patch ?

Comment by Michael Osipov [ 21/Apr/15 ]

Niels Bertram, this is so annoying. I'd like to test your patch but I am really sick of maintaining a fork of every single component Oracle is not capable/ or unwilling to fix. Let me have a look at it later that week and I will come back to you.

Comment by Niels Bertram [ 21/Apr/15 ]

Agreed, especially if there is no real workaround and the patching is not really trivial given one has to first patch the xsom library and then also stuff around in about 35 locations in the JAXB-RI pom model to get this thing to shade the patched xsom code in. I did see that the JAXB-RI maven build is slowly getting "uncoupled" under the glassfish banner. Maybe some day we would just be able to maven exclude the defective xsom library from jaxb-xjc and add a fixed one to the dependencies section. This ticket is slowly becoming a larger issue for us in building component based JAXB binding modules so maybe we collectively need to raise Oracle Support tickets.





[JAXB-1011] Base complex type "AdditionalParametersBaseType" is derived by restriction, while this complex type "AdditionalParametersType" is derived by extension. OGC WCS 2.0.0 - Created: 07/Apr/14  Updated: 06/Apr/15

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

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

Windows 7 64bit
Java 6



 Description   

Trying to generate the bindings for
http://schemas.opengis.net/wcs/2.0/wcsAll.xsd

E:\schemas\inspire\wcs\wcs-2_0_1\wcs\2.0.1>"E:\quaglan\software\jaxb-ri-2.2.7\ja
xb-ri-2.2.7\bin\xjc" wcsAll.xsd -d "E:\quaglan\projects\subversion\sdi\Geoportal
\Common\MavenProjects\INSPIREGeoportalBindings\src\main\java" -target 2.1 -b bin
dings.xjb -extension -catalog catalog.xml
parsing a schema...
[ERROR] Base complex type "AdditionalParametersBaseType" is derived by restricti
on, while this complex type "AdditionalParametersType" is derived by extension.
This is not currently handled by XJC, but we are seeking input on this issue. Pl
ease report this to the JAXB team.
line 54 of http://schemas.opengis.net/ows/2.0/owsAdditionalParameters.xsd

Failed to parse a schema.



 Comments   
Comment by jbaldo [ 26/Aug/14 ]

H
Is there any activity on this issue?

Comment by tastle [ 06/Apr/15 ]

Hit the same thing recently. This is going to be a problem with anything based on OWS 2.0 from the OGC.





[JAXB-895] JAXB NullPointerException With Nested HashMap in GF 3.1.2 Created: 10/Apr/12  Updated: 01/Apr/15  Resolved: 12/Apr/12

Status: Resolved
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.5
Fix Version/s: 2.2.6

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

JAXB 2.2.5 embedded in GF 3.1.2. Operating System is Mac OS X Snow Leopard 10.6.8


Attachments: Zip Archive nested-map-example.zip    
Tags: 2-2-5, glassfish-3-1-2, hashmap, jaxb, nested, nullpointerexception

 Description   

It seems that JAXB 2.2.5 is causing a NPE where versions 2.2.4 and older did not. I wrote a simple test EJB inside a Maven project to demonstrate the problem and attached the files.

I have a class named HashMapWrapper that contains a HashMap and provides getters and setters into that map. In the case where an Object value is a nested HashMapWrapper, JAXB throws a NPE when unmarshaling the XML.

I've taken the same test EJB and deployed it in GF 3.1.1 where it works fine, but when I deploy it in 3.1.2, it breaks.

The XML it is attempting to unmarshal is shown below and at the bottom is the exception that is thrown.

<pre>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<hashMapWrapper>
<map>
<entry>
<key>NestedKey</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="hashMapWrapper">
<map>
<entry>
<key>NameKey</key>
<value xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">NestedWrapper</value>
</entry>
</map>
</value>
</entry>
<entry>
<key>NameKey</key>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">OuterWrapper</value>
</entry>
</map>
</hashMapWrapper>
</pre>

<pre>
Caused by: java.lang.NullPointerException
at com.myexample.HashMapWrapper$JaxbAccessorM_getMap_setMap_java_util_HashMap.set(MethodAccessor_Ref.java:60)
at com.sun.xml.bind.v2.runtime.property.SingleMapNodeProperty$1.leaveElement(SingleMapNodeProperty.java:183)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:526)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:158)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2939)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:218)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:219)
at com.myexample.HashMapWrapper.unmarshal(HashMapWrapper.java:89)
at com.myexample.TestBean.testUnmarshal(TestBean.java:29)
at com.myexample.TestBean.init(TestBean.java:18)
</pre>



 Comments   
Comment by Iaroslav Savytskyi [ 12/Apr/12 ]

Fixed NPE caused by cleaning ThreadLocals in case of nested maps elements

Comment by Iaroslav Savytskyi [ 12/Apr/12 ]

Added new test test/j2s/test/bugs/bug895
Fix barrida: 537

Comment by Nathan Johnson [ 12/Apr/12 ]

If I want to pull that fix into my GF 3.1.2 installation, do I just need to build the jaxb-osgi and jaxb-api-osgi jars and drop them into the GF modules directory and endorsed directory? Or are there other jars that support JAXB in GF? Thanks!

Comment by Iaroslav Savytskyi [ 24/Apr/12 ]

In general you are right. I hope it wouldn't cause any problems because of GF dependencies to older JAXB version.

Comment by ragsboss [ 31/Mar/15 ]

I'm hitting this on my box, exactly for the case of nested maps. Following is my stack trace. As you can see I'm running latest Java 7 with update 60. I think this is not an issue of old jars given this issue got fixed more than 3 years back. Would anyone have any clues?

java.lang.NullPointerException
at com.vmware.vcac.composition.content.fields.ComponentFieldValue$JaxbAccessorM_getData_setData_java_util_Map.set(MethodAccessor_Ref.java:45) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.property.SingleMapNodeProperty$1.leaveElement(SingleMapNodeProperty.java:168) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:511) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:143) ~[?:1.7.0_60]
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) ~[xercesImpl-2.10.0.jar:?]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:203) ~[?:1.7.0_60]
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:175) ~[?:1.7.0_60]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:140) ~[?:1.7.0_60]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:123) ~[?:1.7.0_60]
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:754) ~[spring-oxm-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:735) ~[spring-oxm-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.http.converter.xml.MarshallingHttpMessageConverter.readFromSource(MarshallingHttpMessageConverter.java:127) ~[spring-web-4.1.4.RELEASE.jar:4.1.4.RELEASE]
at org.springframework.http.converter.xml.AbstractXmlHttpMessageConverter.readInternal(AbstractXmlHttpMessageConverter.java:61) ~[spring-web-4.1.4.RELEASE.jar:4.1.4.RELEASE]

Comment by Iaroslav Savytskyi [ 01/Apr/15 ]

I've done very brief investigation and I think the reason in that JDK7 contains JAXB 2.2.4 and the bug was fixed in 2.2.5. Plz try to use JDK8. I hope this will fix your problem. If you a not able to upgrade JDK - you will need to use standalone JAXB. In this case you can try JAXB 2.2.11.





[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-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-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-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-687] random failure on globalBindings customization Created: 12/Sep/09  Updated: 03/Mar/15  Resolved: 29/Sep/09

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

Type: Bug Priority: Major
Reporter: Thomas De Smedt Assignee: Martin Grebac
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive test-xjc-687.zip    
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 Thomas De Smedt [ 12/Sep/09 ]

Created an attachment (id=328)
eclipse project with example schema files and test class

Comment by Thomas De Smedt [ 12/Sep/09 ]

I attached a test case that illustrates the problem and checks my analysis. This
is was a very nasty bug to handle, because only some of our developers, sometime
had the problem.

the method

com.sun.tools.xjc.reader.internalizer.DOMForest.getOneDocument()

is used by

com.sun.tools.xjc.reader.internalizer.Internalizer [line: 311]

to (randomly) choose a schema document that gets to carry the xjc globalBinding
settings.
Because the documents are internally stored under a HashMap by systemid, the
choice
of the documents depends on the full path of the actual resource.

If the chosen document is not actually defining a namespace, but happens to be
(syntactically)
included in more than one other schema document, the including documents will
inherit the globalBinding settings.
The code in

com.sun.tools.xjc.reader.xmlschema.BGMBuilder.promoteGlobalBIndings [line:
200]

will report failure because it finds more than one schemas with globalBinding
annotations.

Suggestions for remediation:

  • do not assign global bindings from a binding document to a schema document,
    but leave it in the binding document. The internalizer could assign the
    global bindings an
    empty schema document (with a specific reserved target namespace).
  • alternative: check duplicate globalBindings for compatiblity.
Comment by Martin Grebac [ 14/Sep/09 ]

Thanks for submission, however global scope is at the top of the scope
hierarchy. It covers all the schema elements in the source schema and
(recursively) any schemas that are included or imported by the source schema.
Probably best would be to add a property so that you may choose to ignore global
bindings from underlying schemas.

Comment by Thomas De Smedt [ 18/Sep/09 ]

Reset issue type to defect. I'm aware of the semantics of global scope. The
input documents (see example) declare the global scope binding only once (in the
.xjb file – it makes no difference wether this globalBindings is tied to a
schemalocation or not)

The bug is that xjc assigns these global scope binding to a random schema
document. If this document is included in other schema definition files, you get
fatal errors.

I deem this to be an important defect because:

  • the use case of including an anonymous schema that declares some
    syntactically reusable definitions seems common to me.
  • it is difficult to reproduce, because of the random choice
Comment by Martin Grebac [ 25/Sep/09 ]

Oh, I see, I get it. Thanks a lot for an excellent testcase and evaluation. Need to think of what is the best
way to fix this.

Comment by Martin Grebac [ 29/Sep/09 ]

Fixed in trunk and all branches:
https://jaxb2-sources.dev.java.net/source/browse/jaxb2-sources/jaxb-
ri/xjc/src/com/sun/tools/xjc/reader/xmlschema/BGMBuilder.java?r1=1.24&r2=1.25
https://jaxb2-sources.dev.java.net/source/browse/jaxb2-sources/jaxb-
ri/xjc/src/com/sun/tools/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java?r1=1.31&r2=1.32

Comment by Niels Bertram [ 25/Jul/14 ]

I am still having the exact issue at random in 2.2.10 branch. One project builds perfectly fine, but if I copy it to a different folder location it sometimes spews the following error over and over again until it dies. No further clue as to what may have caused the problem but only referring to the exact same location. Perhaps a regression or simply problem not fixed?

[ERROR] Error while parsing schema(s).Location [ file:/C:/dev/workspaces/model/someproject/src/main/resources/global.jaxb.xml{7,83}].
com.sun.istack.SAXParseException2; systemId: file:/C:/dev/workspaces/model/someproject/src/main/resources/global.jaxb.xml; lineNumber: 7; columnNumber: 83; only one globalBindings customization is allowed in a whole compilation
        at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:86)
        at com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:84)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.promoteGlobalBindings(BGMBuilder.java:215)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.<init>(BGMBuilder.java:171)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:117)
        at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:425)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:174)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:54)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:44)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:29)
        at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:364)
        at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:161)

[ERROR] Error while parsing schema(s).Location [ file:/C:/dev/workspaces/model/someproject/src/main/resources/global.jaxb.xml{7,83}].
com.sun.istack.SAXParseException2; systemId: file:/C:/dev/workspaces/model/someproject/src/main/resources/global.jaxb.xml; lineNumber: 7; columnNumber: 83; (related to above) but one is already given at this location
        at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:86)
        at com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:84)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.promoteGlobalBindings(BGMBuilder.java:217)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.<init>(BGMBuilder.java:171)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:117)
        at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:425)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:174)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.loadModel(XJC22Mojo.java:54)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:44)
        at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:29)
        at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:364)
        at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:161)
Comment by rodrigo.ijk [ 03/Mar/15 ]

The problem still occurs here using 2.2.7.
This is the content of my bindings:

<jxb:globalBindings>
	<xjc:simple/>
	<jxb:serializable uid="1"/>
</jxb:globalBindings>

By removing the serializable part I could run the build successfully:

<jxb:globalBindings>
	<xjc:simple/>
</jxb:globalBindings>




[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-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-840] Generation of JAXBElement with nillable and minOccurs Created: 09/Jun/11  Updated: 16/Feb/15  Resolved: 15/Jul/11

Status: Resolved
Project: jaxb
Component/s: xjc
Affects Version/s: 2.2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: perlilja Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive jaxb-test.zip    

 Description   

When generation source code from the following XML 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>

The generated code for the NillTwo element is not generated as an JAXBElement, while it is generated for the NillOne element.

See the generated code below:

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>
  • <complexType>
  • <complexContent>
  • <restriction base=" {http://www.w3.org/2001/XMLSchema}

    anyType">

  • <sequence>
  • <element name="NillOne" type=" {http://www.w3.org/2001/XMLSchema}

    int" minOccurs="0"/>

  • <element ref=" {http://xml.jaxb.test/test}

    NillTwo" minOccurs="0"/>

  • </sequence>
  • </restriction>
  • </complexContent>
  • </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)
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 = ((JAXBElement<Integer> ) 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; }

}

I have attached a maven project for testing.



 Comments   
Comment by Martin Grebac [ 15/Jul/11 ]

Fixed in trunk, will resolve in 2.2 when tests pass. Potentialy will merge to 2.1 as well after verification.

Comment by Mark A. Ziesemer [ 25/Jul/12 ]

Assuming that this is the fix change: http://java.net/projects/jaxb/sources/version2/revision/3712, this appears to be resolved on the jaxb-2_2-branch on revision 3729 - which appears to be included on any release starting with 2.2.5 (update 0).

(/branches/jaxb-2_2_5u2 came from /tags/jaxb-2_2_5u1:3922, which came from /branches/jaxb-2_2_5_1:3909, which came from /tags/jaxp-2_2_5:3904.)

Comment by lynchie [ 10/Sep/14 ]

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;
    }

}

Can somebody confirm that this is still an issue?

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;

Comment by hudi1 [ 16/Feb/15 ]

Hi,

is this bug finally fixed ? I try this with version 2.2.11 and there is still not generating JAXBElement





[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-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-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-913] XmlAdapter<String, Boolean> should be able to apply to small-b boolean (primitive) bean fields as well as Boolean fields Created: 26/Jul/12  Updated: 16/Jan/15

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

Type: Improvement Priority: Major
Reporter: daveboden Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Registering an XmlAdapter<String, Boolean> with the Unmarshaller and marking the bean field with an @XmlJavaTypeAdapter annotation results in the error message:

...is not applicable to the field type boolean.

Here's someone else with a similar request:
http://stackoverflow.com/questions/6552740/jaxb-suppress-boolean-attribute-if-false

My use case is that although I'm happy for marshalling to convert a boolean to the string "true" or "false" for output in XML, I'd like more flexibility in the unmarshalling. Ideally "true" and "TRUE" would unmarshal successfully to boolean = true.
I'm using Jaxb for a simple unmarshalling task of XML to a bean and am not providing a schema or a binding customisation file. For the record, even for the big-B Boolean case it would be great to be able to register default behaviour for booleans without having to tag the bean field with @XmlJavaTypeAdapter. There seems to be no facility to programatically override this default behaviour at the Unmarshaller level.

I could choose to transform the TRUE into a true as part of a preprocessing step. However, I only want to apply that preprocessing logic when the value is definitely going to be attached to a boolean or Boolean. Because I don't have a schema, any preprocessor would have to change all instances of "TRUE", even if they are destined to be a String and would be far better staying as "TRUE".



 Comments   
Comment by javaprog [ 16/Jan/15 ]

Another user with the same issue: http://stackoverflow.com/questions/14053063/marshaling-a-long-primitive-type-using-jaxb

Also affects version 2.2.7.





[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-273] Java annotations to generate xsd documentation/appinfo elms Created: 01/Nov/06  Updated: 06/Jan/15

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.1 EA1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: wiebe_ruiter Assignee: Unassigned
Resolution: Unresolved Votes: 20
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Duplicate
is duplicated by JAXB-369 Add ability to inject javadoc into sc... Resolved
Issuezilla Id: 273

 Description   

Annotation(s) ( class level, member level ) to have documentation/appinfo
elements generated by schemagen.

E.g. when annotating a class with @XsdAppinfo:

@XsdAppInfo( value="blah" )

The xsd should have a complex type definition:

...
<xs:element name="bar" nillable="true">
<xs:complexType>
<xs:annotation>
<xs:appinfo>blah</xs:appinfo>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ns1:foo">

...

In this example a simple String is used, but optionally xml elements may be
necessary. Probably a user should be able to define a custom ( inherited ? )
annotation to generate xml elements instead of a simple string.



 Comments   
Comment by Dennis Kieselhorst [ 21/Oct/10 ]

The opposite is in issue JAXB-460.

Comment by lisa_winkler [ 13/Jun/12 ]

Can anyone comment on the likelihood of this feature being added? It seems like it would be of widespread benefit.

Comment by lennartj [ 25/Dec/14 ]

If I understand things correctly, SchemaGen does not support copying JavaDoc for classes and methods into XSD documentation annotations. I would consider this a flaw in schemagen, as the generated XSD lacks some potentially important information as found within the JavaDoc of a class or method.

Should we try to file a bug against the tooling of the JDK itself? (It would certainly be more optimal if schemagen was augmented to handle documentation as well). Or would the more pragmatic approach be to fix this in a post-process step of the JAXB plugin (ANT or Maven) instead of having to wait for the schemagen tool to be patched? The functionality is certainly needed.

Basically, I would expect

/**
 * Some information here...
 */
@XmlType(namespace = "http://www.jguru.se/foobar")
@XmlAccessorType(XmlAccessType.FIELD)
public class SomeType { ... }

To have the following generated

<xs:complexType name="someType">
     <xs:annotation>
          <xs:documentation>
               Some information here...
          </xs:documentation>
     </xs:annotation>
     <xs:complexContent> 
     ...
Comment by laune [ 25/Dec/14 ]

Transferring javadoc text into a schemagen generated XSD file is going to be quite difficult as schemagen processes class files, which don't contain javadoc text.

Assuming this minor difficulty can be overcome, the javadoc text isn't very readable when dumped between a pair of XML tags. Apart from the HTML tags, there are inline tags (@link, @see,...) that need interpretation to be useful.

Since a field with getter and setter may contain three sets of javadoc: should they all be combined into a single annotation?

And when all of this has been resolved: how would that wealth of annotation be presented to the user?

Comment by lennartj [ 25/Dec/14 ]

Schemagen processes bytecode - that is indeed true. But we need the JavaDoc information in the XSD world as well; parts of the beauty of an XML binding framework is that it can be used to transfer the information from the Java realm into the XML realm and back.

Loosing some information in the process is problematic, partly because the remaining bits may not be as intuitive in terms of clarity or usability and partly because we need both java code and javadoc documentation to provide clear guidance about how a class or method should be used or what data it carries. Moreover, I would really suggest we avoid introducing yet another set of annotations to clutter the code even more. Instead, I feel it is good enough to work with what we have - namely JavaDoc comments. This is particularly true if our goal is to enable developers to generate *professional quality* XSDs from annotated Java code using JAXB wrapping SchemaGen and JavaDoc working in concert with one another.

I believe this implies two things:

  1. Generating XSD's is (at least) a 2 step process, where we use schemagen and javadoc to generate separate documents which are merged to the final, resulting XSD.
  2. While JavaDoc is the standard tool of choice to convert javadoc comments to HTML, we need a custom JAXB doclet to generate XSD annotations from javadoc comments. For example, we need to use JAXB annotations to find the normative javadoc - in case a class is annotated with @XmlAccessorType(XmlAccessType.FIELD), the javadoc for a property should be read from the field and vice versa.

WRT how to process inline tags, we could either use another processing tool such as Doxia or simply use our own doclet implementation to harvest that information - the purpose should be to enable developers not to loose *all* JavaDoc documentation when generating XSDs. I am certain that the conversion will improve over time.

Comment by Dennis Kieselhorst [ 29/Dec/14 ]

I like the idea of transferring javadoc into the XSD without new annotations. In my view having documentation is better than no documentation.

JAXB-460 should be easier, however it's open for years now.

Comment by lennartj [ 06/Jan/15 ]

Hm... http://docs.oracle.com/javase/8/docs/technotes/tools/unix/schemagen.html claims that SchemaGen works either on .java files or .class files. Is this a change from earlier on?

Anyhow ... I got a working example on how to inject supplied JavaDoc as XML annotations into generated XSDs. While it does require access to Java Sources, one could possibly extract JavaDoc data from existing JavaDoc (thus not requiring that actual .java files be present).





[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-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-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-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-335] wsimport usage of xjc episode files Created: 19/Mar/07  Updated: 24/Nov/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mshaffer55 Assignee: Martin Grebac
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 335

 Description   

I have five schemas that are used in common by multiple services, so I ran them
through xjc -episode together to produce a single episode file containing
bindings for all of them, thinking that I could feed this to all of the
wsimports. But not all five schemas are used by all the services, and I am
getting errors like this out of wsimport, when it encounters bindings for
schemas that don't happen to be used by the service:

[ERROR] SCD "x-schema::tns" didnt match any schema component

So if I want to compile the schemas only once, I must compile them one at a
time, and then use only the specific episode files needed in each wsimport? OK,
but that's going to get cumbersome fast as the schema population grows. It would
be nice to be able to have episode files that could contain bindings for
arbitrary schemas, and xjc/wsimport just used the parts it needs.



 Comments   
Comment by E.Wiles [ 24/Sep/14 ]

Excuse me, but has there been any solution to this issue? I'm in the same boat with multiple XSD files, and having the same issue.

Comment by Michael Osipov [ 24/Sep/14 ]

E.Wiles, I am suffering too. No avail from Oracle. I have found a crappy workaround which does its job but I am not happy with.

Comment by E.Wiles [ 24/Sep/14 ]

I found one too:

1) Change each

<bindings scd="x-schema::tns"

to:

<bindings if-exists='' scd="x-schema::tns"

2) Delete each

<schemaBindings map="false">...</schemaBindings>

block, entirely.

The first tells wsimport to not worry if the schema isn't being used by that particular wsdl.
The second change keeps wsimport from deciding that there are no mappings at all for that package.

Comment by flutter [ 24/Nov/14 ]

This issue still seems to exist in JAXB 2.2 included in JRE 1.7.0_71





[JAXB-514] passing episode file to xjc api creates incorrect Model Created: 11/Jun/08  Updated: 24/Nov/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.7
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: ramapulavarthi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 25
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jaxb_episode.zip     Text File jaxb_episode.zip     Text File jaxb_episode.zip    
Issuezilla Id: 514

 Description   

Attached is the testcase which simulates the way wsimport invokes xjc.
Passing episode works when directly used with xjc ant task. But wsimport uses
xjc api.
This is required for https://jax-ws.dev.java.net/issues/show_bug.cgi?id=368



 Comments   
Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=254)
testcase

Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=255)
Updated testcase

Comment by ramapulavarthi [ 08/Jan/09 ]

Another bug is filed on jax-ws
(https://jax-ws.dev.java.net/issues/show_bug.cgi?id=690) on the same note.

Comment by Pavel Bucek [ 16/Jan/09 ]

I've tried xjc with episodes from command line and via com.sun.tools.xjc.api.XJC
and both ways are working fine.

My code:

SchemaCompiler sc = XJC.createSchemaCompiler();

InputSource file = new
InputSource("/Users/pavel/jaxb/bugs/514/tryout2/b.xsd");
InputSource episode = new
InputSource("/Users/pavel/jaxb/bugs/514/tryout2/a.episode");

sc.parseSchema(file);
sc.getOptions().addBindFile(episode);
// sc.getOptions().scanEpisodeFile(new
File("/Users/pavel/jaxb/bugs/514/tryout2/a.jar")); // works too

S2JJAXBModel model = sc.bind();

JCodeModel jcm = model.generateCode(null, null);
jcm.build(sc.getOptions().createCodeWriter());

It is working even with xsd and episode you've provided with testcase (after
fixed typos in file wrap.xsd (complesElement and AbstrcatType).

In uploaded testase you're checking for Hello class but it's already present in
episode file so xjc won't generate it. I'm not sure if I understood this
correctly so please reply if I'm missing something.

Comment by Pavel Bucek [ 04/Mar/09 ]

marking as incomplete

Comment by Pavel Bucek [ 19/Mar/09 ]

Closing as invalid. Feel free to reopen with additional info.

Comment by ramapulavarthi [ 20/Mar/09 ]

Reopening the issue.
Please see the testcase. As in the testcase, JAX-WS tries to get Element Mapping
from the model. Although the model has proper schema information,
model.get(QName) is not returning anything. I think there is some problem in
populating the JAXBModelImpl.byXmlName map.

Also, please use the newly attached testcase to reproduce the issue.

Comment by ramapulavarthi [ 20/Mar/09 ]

Created an attachment (id=301)
New testcase with the reopened issue.

Comment by Pavel Bucek [ 24/Mar/09 ]

Can you provide file common-targets.xml, please?

– removing incomplete keyword

– ant output:
$ ant
Buildfile: build.xml
/Users/pavel/jaxb/config/common-targets.xml could not be found

BUILD FAILED
java.io.FileNotFoundException: /Users/pavel/jaxb/config/common-targets.xml (No
such file or directory)

– build.xml:
$ cat ./build.xml | grep common-targets
<!ENTITY commonTargets SYSTEM "../../../../config/common-targets.xml">

Comment by ramapulavarthi [ 24/Mar/09 ]

The common-targets does not have much other than setting up the classpath for
xjc and defining xjc task.

Your earlier test case should suffice for reproducing the problem, just check
the model (model.get(QName)), if it can give info about the elements defined in
hello.xsd

Comment by fribeiro [ 14/Apr/09 ]

Any update yet?

Comment by Pavel Bucek [ 16/Apr/09 ]

We have a workaround.

After short brainstorming session with snajper we've discovered that the easiest
way to support this is do two models - one with episode file included and one
without it (so first will be used to generate java classes and second for
mapping check).

We are aware of performance loss in this case but this isn't used in runtime so
it shouldn't be a major issue.

Please, let us know if this is acceptable (at least for now).

Comment by euxx [ 12/May/09 ]

Is there an update on this?

This issue is very critical for us, we have a common schema and number of
extensions that should reuse the same binding files. So, without this fix the
wsimport can produce a conflicting code that fails at the runtime. Thanks.

Comment by fribeiro [ 08/Sep/09 ]

Any update yet?

Comment by Martin Grebac [ 11/Sep/09 ]

Pavle, did you contact Rama/Jitu about this one?

Comment by Martin Grebac [ 17/Sep/09 ]

Adding an evaluation here such that I don't forget again. Also setting target
milestone.

The reason why JAXB standalone testcase works and why wsimport fails is the very
basic definition of episode files - JAXB ignores types specified in episode
files in it's processing. It doesn't have enough info to create a model from
them. However, wsimport is requesting this information - it requests Mapping
instance from model.get(QName) call. That includes Type and Annotation info.

One possibility to fix this would be to make a place in episode files to provide
such info. Better solution I think is this:

When wsimport requests information for a qname which is not found in the model,
jaxb would look up the episode file, find a corresponding classname; it will
load the class from classpath, read the annotation/type info using reflection
and return it back to jax-ws in mapping instance.

There's a risk in this however: we don't know yet what other information jax-ws
would require from the model, so this fix could be just a beginning and could
uncover more hidden issues. I'll check with Jitu/Rama about what info is
required in the model. Pavel will look into this for 2.2 release.

Comment by Martin Grebac [ 27/Oct/09 ]

This is not really a bug in JAXB, it's an enhancement, so updating the issue. We'll target this one for 2.2.1
as it requires larger changes than we expected. We made several enhancements, but it requires more work
since JAX-WS requires a lot more information to be present from the classes.

Comment by fribeiro [ 02/Nov/09 ]

Thanks for the update.

Comment by fribeiro [ 25/Jan/10 ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 ]

Any update yet?

Comment by marcelcasado [ 24/Nov/11 ]

Any update ? Which version will be this available? Is there a work around? Thanks

Comment by cedric.vidal [ 08/Jun/12 ]

I'm also interested for an update on this.

Comment by RyanCarpenter [ 06/Mar/13 ]

I also appear to be running into this issue and would appreciate an update, if one is available. Thanks

Comment by Iaroslav Savytskyi [ 07/Mar/13 ]

Hi,

To be honest now we have quite a lot of BUGs to be closed. But the light became visible in the end of the tunnel. So I hope I'll be able to start working with this in 1-2 months.

Iaroslav

Comment by rcardillo [ 19/Jul/13 ]

Some people (myself included) have been waiting years for this. Any update on where this is going? I mean, we cannot really use episode files with wsimport effectively without this fix.

Can you at least provide a list of known workarounds that should be considered? I've been finding it difficult to workaround because in a project that uses episode files to make XML binding libraries, it's also really easy to get something generated that fails at runtime (e.g., multiple ObjectFactories that support the same element cause JAXBContext issues at runtime).

Comment by Michael Osipov [ 25/Feb/14 ]

Any update on this? I wasted an entire day to figure out that this is actually a bug!

Comment by jahutton [ 14/Mar/14 ]

Any update? without this fixed it kind of makes jaxws generation useless.

Comment by Michael Osipov [ 14/Mar/14 ]

I second jahutton's statement. Without decoupling the model from the SEI, it is impossible to support separation of concerns. Iaroslav Savytskyi, an entire year has passed without any progress. Please act!

Comment by bdrx [ 10/Nov/14 ]

Is this issue actually 'IN PROGRESS' meaning is someone actively working on this? Is there an estimated/target release for this? Is there any jaxb/xjc development happening period? What would one need to do to contribute to this project and/or get this moving?

Comment by Michael Osipov [ 10/Nov/14 ]

The status is just in pretense only. Nothing has changed for month.





[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">
<x