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

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

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


 Description   

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

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

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





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

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

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

JavaSE 1.7


Tags: customizations, plugin, xjc

 Description   

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

Improvement suggestion:

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





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

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

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


 Description   

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

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



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

It's not clear where is the problem.

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

Comment by chengas123 [ 10/Mar/15 ]

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

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

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

Here's the dependency graph with 2.2.7:

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

Here's the dependency graph with 2.2.11:

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

Comment by Iaroslav Savytskyi [ 13/Mar/15 ]

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

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

Here is current dependency tree for JAXB runtime:

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





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

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

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


 Description   

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

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

I propose to change

                        xmlNsSet = new HashSet<XmlNs>();

in

                        xmlNsSet = new LinkedHashSet<XmlNs>();

(at line 327)

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



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

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





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

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

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


 Description   

The xjc /? output prints the following out:

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

This is formulated similar to:

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

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

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

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

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

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

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

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

Thank you.






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

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

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

Attachments: File georss.rnc    

 Description   

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

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


}





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

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




[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: 26/Feb/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: 0
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.





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

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

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

Tags: jaxb, jaxb-xjc, xjc

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

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

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

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

Page 58 of JAXB 2.2 spec

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

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

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



 Comments   
Comment by mystarrocks [ 01/Feb/15 ]

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

Comment by Iaroslav Savytskyi [ 02/Feb/15 ]

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

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

Comment by mystarrocks [ 03/Feb/15 ]

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

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

Like:

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

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

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

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

Comment by mystarrocks [ 03/Feb/15 ]

I'm not quite sure about this statement:

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

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

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

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

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

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

In my opinion, your proposition

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

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

Comment by mystarrocks [ 03/Feb/15 ]

You're right,

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

deviates from the spec. How about:

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

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

Comment by Iaroslav Savytskyi [ 05/Feb/15 ]

Thanks for reporting. Will be fixed.





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

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

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


 Description   

Abstract

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

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

Example

A short example might illustrate the reason here.

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

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

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

Consequence: required, complex cleanup operation

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

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

A better solution

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

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

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






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

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

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


 Description   

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

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



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

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

import org.junit.Test;

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


public class ClassWithCollectionPropertyTest {

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

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

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

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

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

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

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

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

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

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




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

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

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

Attachments: XML File schema.xsd    

 Description   

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

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

Generates:

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

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

Which does not compile.

Apparently, char is somehow not considered to be primitive.

I have attached a sample schema to reproduce this.



 Comments   
Comment by lexi [ 19/Dec/14 ]

I think the problem is here:

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

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

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





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

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

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


 Description   

Hi,

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

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

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

See:

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

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

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

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

Best wishes,
Alexey



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

Should be resolved now.

Comment by lexi [ 17/Dec/14 ]

Now it's good:

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

Thank you very much for the fast reaction.





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

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

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


 Description   

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

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

(Around line 99.)

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

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

Which is not correct.

Please correct it to:

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





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

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

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


 Description   

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

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

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

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

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

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

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

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

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

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



 Comments   
Comment by lexi [ 15/Dec/14 ]

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

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





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

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

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

n/a



 Description   

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

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



 Comments   
Comment by lennartj [ 20/Nov/14 ]

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

Comment by Iaroslav Savytskyi [ 21/Nov/14 ]

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





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

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

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


 Description   

Using the schema

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

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

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

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

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


package test.jaxb.xml.test;

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


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

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

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

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

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

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

}

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

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

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

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

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

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






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

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

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


 Description   

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

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

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

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



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

Hi Miran,

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

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

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





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

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

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

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

 Description   

I am getting the following warning:

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

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

This is minor, not blocking anything.



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

Hi Lexi,

What I have to do to get this errors?

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

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

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

Hm, this is weird.

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

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

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

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

See the eclipse.log.

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

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

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

Comment by lexi [ 15/Oct/14 ]

Asked on SO:

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

Comment by Lukas Jungmann [ 20/Oct/14 ]

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

Comment by lexi [ 13/Dec/14 ]

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

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

And this Eclipse bug:

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





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

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

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

JDK7u67



 Description   

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

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



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

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





[JAXB-1052] Marshaller.marshall throws NPE if an adapter adapts a non-null bound type to null value of another type with single xmlValue annotation Created: 01/Oct/14  Updated: 01/Oct/14

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

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


 Description   

This is basically a very narrow corner-case of JAXB-415, but I thought it might be better to track it as a new bug. I actually discovered it in Scala, but was able to reproduce it with the following Java (which, I tested worked in MOXy - heresy I know).

Also, It doesn't occur if,
1) you add an attribute to Bar
2) you change the single xmlValue to be an xmlElement

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Foo {

@XmlElement
@XmlJavaTypeAdapter(TestAdapter.class)
private Optional<Bar> v;
public Foo()
{
}
public Foo(Optional<Bar> v)

{ this.v = v; }

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

{ Marshaller m = JAXBContext.newInstance(Bar.class, Foo.class).createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); m.marshal(new Foo(Optional.of(new Bar("foo"))), System.out); }

}

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Bar {
@XmlValue
private String v;

public Bar() {
}

public Bar(String v)

{ this.v = v; }

}

public class TestAdapter extends XmlAdapter<Bar,Optional<Bar>>
{
public Optional<Bar> unmarshal(Bar v) throws Exception

{ return null; }

public Bar marshal(Optional<Bar> v) throws Exception

{ return null; }

}



 Comments   
Comment by coconnor [ 01/Oct/14 ]

I used,
guava = "com.google.guava" % "guava" % "18.0"

It might also work if you adapt from completely separate type, but it seemed appropriate to demonstrate the utility I am deriving from this use-case.

Comment by coconnor [ 01/Oct/14 ]

And this is the stacktrace:

Exception in thread "main" java.lang.NullPointerException
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:54)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:379)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.get(Accessor.java:266)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.getUnadapted(Accessor.java:143)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.hasValue(TransducedAccessor.java:251)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl$TransducerImpl.writeLeafElement(RuntimeClassInfoImpl.java:409)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:256)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:130)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:361)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:342)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
at org.caoilte.atomizer.model.Foo.main(Foo.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)





[JAXB-1051] JAXB RI does not implement §5.5.4 of JAXB 2.2 specification Created: 30/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

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

Type: Bug Priority: Major
Reporter: Florian Schoppmann Assignee: Iaroslav Savytskyi
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

§5.5.4 ("isSet Property Modifier") of the JAXB 2.2 specification is not implemented in the JAXB reference implementation. (It is also not implemented in EclipseLink MOXy, though MOXy has an XmlIsSetNullPolicy annotation).

Example:

public class XMLTest {
    @XmlRootElement
    public static final class Foo {
        private final ArrayList<Bar> bars = new ArrayList<>();

        @XmlElementWrapper(name = "bars")
        @XmlElement(name = "bar")
        public List<Bar> getBars() {
            return bars;
        }

        public boolean isSetBars() {
            System.out.println("isSetBars() called!");
            return !bars.isEmpty();
        }

        public void unsetBars() {
            System.out.println("unsetBars() called!");
            bars.clear();
        }
    }

    public static class Bar {
        @XmlElement
        private String name;
    }

    @Test
    public void jaxbTest() throws Exception {
        JAXBContext jaxbContext = JAXBContext.newInstance(Foo.class);
        Marshaller marshaller = jaxbContext.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.marshal(new Foo(), System.out);
    }
}

The above code outputs

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<foo>
    <bars/>
</foo>

but something of the following form would be expected according the the spec:

isSetBars() called!
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<foo/>

Without §5.5.4 it is impossible to distinguish between set and unset list properties in a portable way.



 Comments   
Comment by Florian Schoppmann [ 30/Sep/14 ]

This issue is also related to JAXB-948.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

There is no need for JAXB to call "isSet" method. We have empty list. So we are marshalling it as <bars/>
So if you don't want to see it in the output - set bars to null.

Comment by Florian Schoppmann [ 30/Sep/14 ]

I don't follow that argument for several reasons:

  1. Settings bars to null is not a portable option. For "list properties", the JAXB specification only expects a getter, no setter. Hence, there is no standard way to set a list to null.
  2. There is nothing in §5.5.4 that makes calling isSet property modifiers optional (assuming the modifier exists).
  3. As JAXB-948 demonstrates, disobeying the specs has caused incompatibilities. Why should ignoring the specs be "works as designed"?
Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

1) good catch But specification doesn't forbid you to add setter for the list.
2) If you are going XJC way and you want to work with nulls -> use generateIsSetMethod or optionalProperty
In this case for:

<element name="bars" type="string" maxOccurs="unbounded"/>

XJC will generate for you something like:

Foo.java
   @XmlElement(required = true)
   protected List<String> bars;

   public List<String> getBars() {
        if (bars == null) {
            bars = new ArrayList<String>();
        }
        return this.bars;
    }

    public boolean isSetBars() {
        return ((this.bars!= null)&&(!this.bars.isEmpty()));
    }

    public void unsetBars() {
        this.bars = null;
    }

3) the main idea behind "isSet" methods is to allow user after UNMARSHALLING to know if xml HAS that value or not. (By the way, user has to call "isSet" before trying to get data from the collection.)

That's why there is no need for JAXB runtime to check that values during MARSHALLING. It's on the user to set something there or not.

4) JAXB-948 was fixed. There is no incompatibilities any more. If users specifies setter for the collection and add there additional logic. It's up to him. And JAXB "works as designed" in this case.

The only thing we can improve here is to try to call collection's setter AFTER the it's filled with values. But sure such way has it's disadvantages.

Comment by Florian Schoppmann [ 30/Sep/14 ]

I see. Chapter 5 of the specification is basically only concerned with the direction XML Schema -> Java, and the output of XJC is not normative. That indeed answers 1) - 3). Thanks!

Regarding 4), however, I am still wondering whether the current implementation legitimately breaks the code in my comment to INCK-948 (that code worked fine with JDK 7, and it also works fine with EclipseLink MOXy). Unless that code is in violation of the specs (which I currently fail to see), I think JAXB-948 was not really fixed and should be reopened.





[JAXB-1050] Wrong package test.t1 in txw2 Created: 28/Sep/14  Updated: 28/Sep/14

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

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


 Description   

Java files in txw2/src/test/java say they're in test.t1 whereas they are in t1.



 Comments   
Comment by lexi [ 28/Sep/14 ]

PR: https://github.com/gf-metro/jaxb/pull/5





[JAXB-1049] com.sun.tools.xjc.model.Aspect is missing in XJC Created: 28/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

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

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

Attachments: Text File mvn.log    

 Description   

com.sun.tools.xjc.model.Aspect is probably missing in XJC. Please see the compilation log.



 Comments   
Comment by lexi [ 28/Sep/14 ]

Please see the PR:
https://github.com/gf-metro/jaxb/pull/4

OCA is signed:

http://www.oracle.com/technetwork/community/oca-486395.html#v (Aleksei Valikov)

Comment by Iaroslav Savytskyi [ 29/Sep/14 ]

I know .. It was bad merging Instead of move it just delete and recreated file.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

Fixed within 2.2.11-b140930





[JAXB-1048] com.sun.xsom:xsom:jar:20140513 is missing Created: 28/Sep/14  Updated: 30/Sep/14  Resolved: 30/Sep/14

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

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

Attachments: Text File mvn.log    

 Description   

I'm trying to build the jaxb-ri forked in GitHub.

This is what I get for txwc2:

[ERROR] Failed to execute goal on project txwc2: Could not resolve dependencies
for project org.glassfish.jaxb:txwc2:jar:2.2.11-SNAPSHOT: Failure to find com.sun.xsom:xsom:jar:20140513 in https://maven.java.net/content/repositories/releases/ was cached in the local repository, resolution will not be reattempted until the update interval of releases.java.net has elapsed or updates are forced -> [Help 1]

I don't see this JAR in https://maven.java.net/content/repositories/releases/.

Maven log is attached.



 Comments   
Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

New xsom version 20140925 is released yesterday.





[JAXB-1047] SCD bindings do not support custom/vendor customization elements Created: 28/Sep/14  Updated: 28/Sep/14

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

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


 Description   

I wrote a number of XJC plugins, some of these plugins can be customized via binding files.

For instance, I can do the following:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings schemaLocation="w3c/1999/xlink.xsd" node="/xs:schema">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

If my Jsonix plugin is activated, XJC will know that jsonix:packageMapping is a customization element for Jsonix (plugin API allows saying what your customization namespace URI is and which local names you expect).

SCD seems to be a more advanced way to address schema elements. I.e.

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink" ... />

addresses the XLink schema logically via namespace URI. Forget the files, this is perfect. Much more versatile than schemaLocation and node. I guess episodes would not work without SCD in first place. For my scenarios it would for instance help with JAXB-1047.

My problem is that SCD does not allow custom elements. So this:

<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema" 
	xmlns:jsonix="http://jsonix.highsource.org/customizations"
	jaxb:extensionBindingPrefixes="jsonix">

	<jaxb:bindings scd="x-schema::xlink" xmlns:xlink="http://www.w3.org/1999/xlink">
		<jsonix:packageMapping packageName="org.hisrc.w3c.xlink.v_1_0" spaceName="XLink_1_0"/>
	</jaxb:bindings>
</jaxb:bindings>

I get the following error:

[ERROR] Error while parsing schema(s).Location [ file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb{8,89}].
org.xml.sax.SAXParseException; systemId: file:/C:/Projects/workspaces/ogc-ng/w3c-schemas/xlink/1999/src/main/resources/xlink-v_1_0.jsonix.xjb; lineNumber: 8; columnNumber: 89; cvc-elt.1: Cannot find the declaration of element 'jsonix:packageMapping'.

Clearly, SCD does not process custom configuration elements whereas schemaLocation plus node do process.






[JAXB-1046] Catalog-resolved schema is not considered to be a part of compilation Created: 28/Sep/14  Updated: 02/Oct/14

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

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

Attachments: Zip Archive cd.zip    

 Description   

Please see the cd.zip.

Assume http://www.ab.org/d.xsd is rewritten to ab/d.xsd via catalog:

REWRITE_SYSTEM "http://www.ab.org" "ab"

I want to customize the d.xsd so I do the following in the binding file:

	<jaxb:bindings schemaLocation="ab/d.xsd" 
		node="/xs:schema">
		<jaxb:schemaBindings>
			<jaxb:package name="org.ab.d"/>
		</jaxb:schemaBindings>
	</jaxb:bindings>

I get the following error message:

[ERROR] "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/d.xsd" is not a part of this compilation. Is this a mistake for "file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/ab/c.xsd"?
  line 13 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1046/cd.xjb

I would argue that ab/c.xsd is definitely a part of the compilation - even if resolved via catalog. Otherwise I'm forced to write the absolute URL in the binding's schemaLocation which is ugly.

This is also important because this issue prohibits reusage of binding files. Please let me explain.

Assume we habe two schemas a.xsd and b.xsd, b.xsd imports a.xsd via absolute URL http://www.ab.org/a.xsd.

We want to compile a.xsd in one compilation and b.xsd plus b.xsd in another.

Due to JAXB-1044 we can't compile http://www.ab.org/a.xsd directly (i.e. xjc http://www.ab.org/a.xsd -catalog a.cat).
Even when using a catalog, XJC still tries to download the file. So we have to compile the local copy xjc a.xsd. If we want to use a binding file to customize compilation, we have to write schemaLocation="a.xsd" in the binding file. Ok, all of this is more or less fine.

Now we want to compile b.xsd which imports http://www.ab.org/a.xsd. Now, it would be cool to reuse the binding file from the first compilation. But that binding file says schemaLocation="a.xsd" bit our second compilation needs schemaLocation="http://www.ab.org/a.xsd". Dead end. We have to write another a.xjb with the only difference being relative vs. absolute URL.

One solution would have been to compile http://www.ab.org/a.xsd instead of a.xsd in the first compilation. But as I pointed, this does not work due to JAXB-1044.

FYI I am perfectly aware of features like SCD and episodes. However there are scenarios, where SCD and episodes are not suitable or don't work as desired. For instance, SCD/episodes do not handle vendor customization elements at the moment.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in https://github.com/gf-metro/jaxb/pull/7 (see the DOMForest).

When resolving URIs, add BOTH the original URI as well as the resolved URI to the id/documents map - with the same document, of course.





[JAXB-1045] "Item" is already defined error with catalogs, bindings and mixed absolute and relative URLs Created: 28/Sep/14  Updated: 02/Oct/14

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

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

Attachments: Zip Archive cd.zip     Zip Archive gml-v_3_1_1.zip    

 Description   

This is somewhat complex setup, please take a look at the prepared example (attached) first.

I am trying to do a clean compilation of the GML 3.1.1 schema using catalogs and binding files.

I've created local copies of files in the w3c and ogc folders and rewrite URLs using the following catalog file:

REWRITE_SYSTEM "http://www.w3.org" "w3c"
REWRITE_SYSTEM "http://schemas.opengis.net" "ogc"

In the GML schema there is one schema which imports SMIL via the absolute URL:

defaultStyle.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd"/>

My understanding is that http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd will be resolved to ogc/gml/3.1.1/smil/smil20.xsd via catalog.

The smil20.xsd imports smil20-language.xsd via relative URL:

smil20.xsd
<import namespace="http://www.w3.org/2001/SMIL20/Language" schemaLocation="smil20-language.xsd"/>

The smil20-language.xsd imports the smil20.xsd also via relative URL:

smil20-language.xsd
<import namespace="http://www.w3.org/2001/SMIL20/" schemaLocation="smil20.xsd"/>

When I try to compile this I get the following stream of errors:

[ERROR] 'structureModuleAttrs' is already defined
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 37 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'skipContentAttrs' is already defined
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 45 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'alternateContentAttrs' is already defined
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 51 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'nonNegativeDecimalType' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 58 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animate' is already defined
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 66 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animatePrototype' is already defined
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 67 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animNamedTargetAttrs' is already defined
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 72 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animAddAccumAttrs' is already defined
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 84 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animValuesAttrs' is already defined
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 102 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animSetValuesAttrs' is already defined
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 108 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animTargetAttrs' is already defined
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 111 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animModeAttrs' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 114 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotion' is already defined
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 125 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateMotionPrototype' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 126 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColor' is already defined
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 131 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'animateColorPrototype' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 132 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'set' is already defined
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 137 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'setPrototype' is already defined
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 138 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorAttrs' is already defined
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 145 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorType' is already defined
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 149 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultAttrs' is already defined
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 157 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'syncBehaviorDefaultType' is already defined
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 161 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingAttrs' is already defined
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 169 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartTimingType' is already defined
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 172 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultAttrs' is already defined
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 180 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'restartDefaultType' is already defined
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 183 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrs' is already defined
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 191 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillTimingAttrsType' is already defined
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 194 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultAttrs' is already defined
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 204 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'fillDefaultType' is already defined
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 207 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'beginEndTimingAttrs' is already defined
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 217 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'durTimingAttrs' is already defined
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 221 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'repeatTimingAttrs' is already defined
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 224 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'deprecatedRepeatTiming' is already defined
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 228 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] 'minMaxTimingAttrs' is already defined
  line 235 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

[ERROR] (related to above error) the first definition appears here
  line 231 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/JAXB-1045/ogc/gml/3.1.1/smil/smil20.xsd

Failed to parse a schema.

Note that XJC complains about the identical URLs, also references the same lines (however in a wrong order which is a bit weird).

If I change both of the relative URLs in the SMIL schemas to absolute URLs, it does work. Of course, I don't want this workaround as I don't want to patch external schemas.

I've also reproduced it on a "reduced" test case with simple schemas (see the cd.zip attachment).

The problem arises only if bindings files are used. When compiling without bindings, it works (see success.bat and failure.bat in cd.zip). failure.bat gives the following error trace:

[ERROR] 'd' is already defined
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 9 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] 'DType' is already defined
  line 16 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

[ERROR] (related to above error) the first definition appears here
  line 10 of file:/C:/Projects/workspaces/jaxb2-basics/jaxb-ri-tests/1/ab/d.xsd

Failed to parse a schema.

Lines are quite interesting. The element 'd' is reported two times on the same line. The type 'DType' is reported two times - one on the opening <complexType ...> tag of the type and once on the closing </schema> tag:

01<?xml version="1.0" encoding="UTF-8"?>
02<schema 
03	xmlns="http://www.w3.org/2001/XMLSchema"
04	targetNamespace="urn:d" elementFormDefault="qualified"
05	xmlns:d="urn:d"
06	xmlns:e="urn:e">
07
08	<import namespace="urn:e" schemaLocation="e.xsd"/>
09	<element name="d" type="d:DType"/>
10	<complexType name="DType">
11		<sequence>
12			<element name="s" type="string"/>
13			<element name="e" type="e:EType"/>
14		</sequence>
15	</complexType>
16</schema>

My guess is that the graph:

  • schema 1 -(absolute URL)-> schema 2
  • schema 2 -(relative URL)-> schema 3
  • schema 3 -(relative URL)-> schema 2

somehow causes problems with schema 2. I think the problem might be different paths to schema 2. The URLs are finally rewritten via catalog to the same URL but the same document gets parsed two times.

This is quite a showstopper for me at the moment. I am forced to patch schemas on a very big scale, which is extremely ugly.



 Comments   
Comment by lexi [ 02/Oct/14 ]

Please consider a fix in the https://github.com/gf-metro/jaxb/pull/7

The problem here is that when the entity resolver resolves some systemId, you get an input source with the stream AND a resolved systemId. Subsequent resolutions (when you for instance have an import or an include) will use this resolved system id. This may result in some schemas addressed by an unresolved and by a resolved system id - despite being placed in the same local source.

The fix is simple: when resolving, only provide the stream and don't change the system id (or public id) of the input source. This still works well - parsers take XML from the stream. And this corrects the problem since system id does not change.


I understand that we're talking customer-facing interface here so you probably have to carefully consider if you apply the fixes or not. I am persuaded that what I propose is the correct behaviour, so I will want to fix it anyway (in maven-jaxb2-plugin, at least). I think I can make workarounds via the entity resolver for JAXB-1044 and JAXB-1045 as it is basically the entity resolver logic which is changed here.
What I can't do is JAXB-1046 since it addresses the interna of the DOMForest which is not accessible. But I think this fix is not dangerous at all.

Please let me know what you think of the fixes and if we can work them into the XJC release.





[JAXB-1044] Catalog is not used to resolve the schema URL provided as an argument to XJC Created: 28/Sep/14  Updated: 07/Oct/14

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

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

Attachments: Zip Archive a.zip    

 Description   

I am compiling schemas from public schema repositories, available online.

However, I don't want builds to download these schemas in first place, instead I want them to work with local copies, "redirected" by catalogs.

I have found out that catalogs seem to be not applied to the URL arguments directly passed to XJC.

Please see the attached test case:

xjc a.xsd

works of course.

However assume I want to compile http://www.ab.org/a.xsd directly. This is a legal use case.
But I don't want a.xsd to be downloaded from http://www.ab.org. So I provide a catalog:

REWRITE_SYSTEM "http://www.ab.org" "."

But this catalog does not seem to be applied to the URL I provide as a command-line argument. This fails:

xjc http://www.ab.org/a.xsd -catalog catalog.cat

Fails is a sense that XJC still tries to download a.xsd from http://www.ab.org.

At the same time, if http://www.ab.org/a.xsd would have been included in another schema, this would have worked.



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

Hi Aleksei,

To be honest, it's clear what are you trying to do, but does it makes sense?

Why will somebody call xjc with

xjc http://www.ab.org/a.xsd -catalog catalog.cat

if he already has a.xsd on his local?

Comment by lexi [ 07/Oct/14 ]

It does make sense. Please also see JAXB-1046, it explains the issue in detail.

Assume we have http://www.ab.org/a.xsd which imports b.xsd relatively. And b.xsd imports a.xsd via an absolute URL: http://www.ab.org/a.xsd.

Which schemas will be compiled if we just compile the local copy of a.xsd? The answer is:

So this is one of the reasons people get "MyType is already defined" (see JAXB-1045). You basically get the same schema (i.e. the same local copy) included via two different systemIds. An that's the problem.

This is not just theory. I work with W3C, OGC, and OASIS schemas and they do this all the time. Some schemas import other schemas relatively, some via absolute URLs. An I have spent days trying to compile these schemas, fighting "MyType is already defined" and "my.xsd is not part of this compilation" errors all the way.

Finally I came to the conclusion that I should not mix compiling local copies and absolute URLs with catalogs. I should compile EVERYTHING uniformely. And since absolute URLs are in play, this should be absolute URLs with catalogs.

I have actually already implemented the workaround for JAXB-1044 in the maven-jaxb2-plugin. It now resolves URLs before passing to XJC. Any you know what? It works just splendid. Take a look at this project:

https://github.com/highsource/w3c-schemas

This works way better than anything I've managed to get working in the past. Actually, the combination of JAXB-1044, JAXB-1045 and JAXB-1046 actually forced me to patch local copies of schemas so that they always use relative URLs. It just did not work the other way round.

If you're still in doubt if this makes sense, try to compile this schema from local copies without patching it:

http://schemas.opengis.net/gml/3.1.1/base/gmlBase.xsd

You will run exactly in the problem I describe above. GML uses SMIL schemas, importing them via absolute URLs. SMIL Schemas, however, import each other via relative URLs. Kaboom.

As I said, I've implemented a workaround in the maven-jaxb2-plugin, but I still would like to get it fixed in the core XJC because I have a few projects which use the command-line XJC and I really won't like to start dancing aroud command-line tools as well.





[JAXB-1043] Content of collection properties lost during Unmarshalling Created: 26/Sep/14  Updated: 30/Sep/14

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

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

Bug occurs on version 2.2.10-b140310.1920



 Description   

Recent versions of JAXB handle collection properties differently than before. An empty collection is created at the beginning, and set into the target bean, and then elements are added to the collection, without any interaction with the bean.

So if the bean for instance makes a private copy of the collection when the setter is called, the content of the collection is lost. See the unit test below.

Issue occurs with version 2.2.10-b140310.1920


package test.serialization.jaxb;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;

import java.io.StringReader;
import java.io.StringWriter;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.annotation.XmlRootElement;

import org.junit.Test;

@XmlRootElement
public class A {

	protected List<String> list;

	public List<String> getList() {
		return list;
	}

	public void setList(List<String> list) {
		// Store the list content in a private copy
		this.list = new ArrayList<>(list);
	}

	@Test
	public void test() throws Exception {
		A a = new A();
		a.setList(Arrays.asList("something"));
		
		JAXBContext ctx = JAXBContext.newInstance(A.class);

		StringWriter writer = new StringWriter();
		
		ctx.createMarshaller().marshal(a, writer);
		
		String text = writer.toString();
		System.out.println(text);
		
		A a2 = (A) ctx.createUnmarshaller().unmarshal(new StringReader(text));
		assertNotNull(a2.getList());
		assertEquals(1, a2.getList().size());
		assertEquals("something", a2.getList().get(0));
	}
	
}



 Comments   
Comment by laune [ 26/Sep/14 ]

Consider;
class A1

{ protected List<String> list = new ArrayList<>(); //... }

works, as does
class A2 {
//...
public void setList(List<String> list)

{ this.list = list; }

//...
}
With class A as shown, the client must provide the implementation for List<String>, apparently leaving it up to him whether it's going to be a LinkedList, an ArrayList or whaterver. But that object isn't returned!

Which, after all, would make a client write code like
a.setList( new ArrayList<String>() );
for(String s: ..)

{ ;a.setList( a.getList().add() ); }

because it isn't guaranteed that what you set is what you get; resulting in a markedly inefficient code.

It may be regrettable that JAXB'S behaviour has changed, but I wouldn't expect it to work with a class according to the pattern of class A.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

Hi @killerchamb,

Why do you think this is a bug?

In any case you can clone the collection after unmarshalling, right?

I'm going to close this as 'Not a bug'

Comment by killerchamb [ 30/Sep/14 ]

Hi, and thank you for looking at this.

I agree that the new behaviour is not a bug, not more than the previous behaviour at least. It's just that it does not work in a few more cases than before, when the getter/setter methods of a class modify the data. When you can alter the source code of the serialized classes it is very easy to fix, when you cannot it blocks you.

I let you close the ticket, at least there will be a trace of the discussion.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

The only thing I can imagine is, that we can set already populated collection.
I'll give a try.

Thanks for reporting.

Comment by Iaroslav Savytskyi [ 30/Sep/14 ]

@me -> https://java.net/jira/browse/JAXB-948





[JAXB-1042] Javadoc compilation errors with JDK8 Created: 22/Sep/14  Updated: 26/Sep/14  Resolved: 26/Sep/14

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

Type: Bug Priority: Major
Reporter: petros.splinakis Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Javadoc compilation fails with errors when ran using JDK8.



 Comments   
Comment by Lukas Jungmann [ 26/Sep/14 ]

should be already fixed in current master





[JAXB-1041] inheritence & XmlRootElement Created: 19/Sep/14  Updated: 20/Sep/14

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

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


 Description   

If B class extends the class A, both annotate with XmlType, and C class annotate with XmlType & XmlRootElement, C contains a field of type A.

The Xml can looks like that
<C>
<A xsi:type="B"/>
</C>
.
Now if A is a XmlRootElement the Xml could looks like that
<A xsi:type="B"/>

Currently, jaxb is not able to marshall that (B class doesn't have XmlRootElement annotation),
but is able to unmarshall that.



 Comments   
Comment by laune [ 20/Sep/14 ]

This works according to the specification.

It isn't possible to marshal an element that isn't annotated with XmlRootElement, which is the way the marshaller learns about the local name and the namespace of the root element.

It would be possible to create a JAXBElement and marshal this - see the JAvadoc.

This issue should be closed.

Comment by diorcety [ 20/Sep/14 ]

Ok i didn't know that was a specification restriction. This mean that jaxb can unmarshall that without any trick, but can't marshall without using JAXBElement.

Comment by laune [ 20/Sep/14 ]

It's more a consequence of: "If there is no information about an XML element's name and namespace: how can you create (i.e. marshal) it`?" It's a gap that can't be filled even if the spec's authors would have wanted to.

Comment by diorcety [ 20/Sep/14 ]

According to this post http://blog.bdoughan.com/2010/11/jaxb-and-inheritance-using-xsitype.html?showComment=1354657419516#c7344877388280882872, this is the behaviour of Moxy





[JAXB-1040] JAnnotationUse causes NPE in getAnnotationMembers() Created: 12/Sep/14  Updated: 12/Sep/14

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

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


 Description   

If memberValues field is never added a parameter, then calling JAnnotationUse#getAnnotationMembers() causes NullPointerException. This is actual for annotations like `@XmlMixed`, which by definition don't have params.






[JAXB-1039] Call to JPackage.annotations() causes empty package-info.java to be generated Created: 12/Sep/14  Updated: 12/Sep/14

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

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


 Description   

Currently getter JPackage.annotations() is called, private field annotations is set to not-null value, causing empty {{package-info.java} to be generated.

The line JPackage.java:443

if(annotations!=null || jdoc!=null)

should be changed to:

if((annotations!=null && !annotations.isEmpty) || jdoc!=null)





[JAXB-1038] Allow the inject-code plugin to inject code into enums Created: 10/Sep/14  Updated: 03/Feb/15  Resolved: 03/Feb/15

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

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


 Description   
for (EnumOutline eo : model.getEnums()) {
            CPluginCustomization c =
eo.target.getCustomizations().find(Const.NS, "code");
            if (c == null) {
                continue;   // no customization --- nothing to inject
here
            }

            c.markAsAcknowledged();
            // TODO: ideally you should validate this DOM element to
make sure
            // that there's no typo/etc. JAXP 1.3 can do this very
easily.
            String codeFragment = DOMUtils.getElementText(c.element);

            // inject the specified code fragment into the
implementation class.
            eo.clazz.direct(codeFragment);
}


 Comments   
Comment by kengelke [ 05/Nov/14 ]

Any news on this issue? I was a bit sad to see it wasn't included in 2.2.11. It's such a small change. I have submitted the Contributor Agreement on September 10th. If there is anything that prevents this change from being merged please let me know.

Comment by Iaroslav Savytskyi [ 03/Feb/15 ]

Implemented in JAXB 2.2.12-SNAPSHOT





[JAXB-1037] Duplicate (after name mapping) field name causes IllegalArgumentException Created: 06/Sep/14  Updated: 08/Sep/14

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

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

Linux ubuntu 14.04, jdk1.8.0_20



 Description   

Actually, the xjc version identifies itself as
$ xjc -version
xjc 2.2.8-b130911.1802
But this funny bug tracker tells me that this version 2.2.8 doesn't exist! So how come it is delivered together with the official Java JDK 1.8.0_20???

Compile the XML Schema file below to see the error. Note that "xx" and "XX" cause the crash, whereas "xx" and "Xx" produce an error message (as would be expected in the other case as well).

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="what:ever"
elementFormDefault="qualified">

<xs:complexType name="Media">
<xs:sequence>
<xs:element name="id" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID"/>
</xs:complexType>

</xs:schema>



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

It's was my fault with versions. It's OK now. And I've updated the bug affected version.

Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

I think the bug is that we throw error in this case. ID and id generates different names for getters/setters. So there shouldn't be a problem. I'm going to refactor XJC code to use java.beans.Introspector.





[JAXB-1036] Jaxb cannot unmarshal files containing hash (#) in name. Created: 24/Aug/14  Updated: 08/Sep/14

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

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


 Description   

Jaxb Unmarshaller has unmarshal(File) method.

When passing a file that contains # in name (e.g. some#name.xml), the part of name after the hash is treated as URL anchor and is not recognized properly.

The problem is caused by improper implementation of this method, which internally uses unmarshal(URL) method invocation.



 Comments   
Comment by Iaroslav Savytskyi [ 08/Sep/14 ]

Confirming the bug.
Thanks for reporting.





[JAXB-1035] Locator is not set for elements without attributes Created: 19/Aug/14  Updated: 19/Aug/14

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

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


 Description   

A locator field, defined as follows:
@XmlType(name = "selector")
public class Selector

{ @XmlLocation @XmlTransient public Locator locator; @XmlValue public String value; }

is ignored in classes, that are treated as leaves (in XML).

In effect, having node <selector>text</selector> we are unable to get line of <selector> xml node (locator is null).

When we add some dummy attribute to that class, locator is being set.

I've checked the source code and the problem is with the fact that when arbitrary node contains only text content, it is treated as Leaf, and there is no consideration whether there is Locator attribute defined or not.






[JAXB-1034] Add/respect non-proxy hosts settings Created: 29/Jul/14  Updated: 29/Jul/14

Status: Open
Project: jaxb
Component/s: maven-plugin
Affects Version/s: 2.2.7
Fix Version/s: None

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


 Description   

One can pass a HTTP proxy but not non-proxy hosts. If HTTP is retrieved from settings.xml, sub element nonProxyHosts is ignored but must be respected.

A patch can be provided.

This relates to JAX_WS-1154.



 Comments   
Comment by Michael Osipov [ 29/Jul/14 ]

This is actually crucial in a corporate environment.

Comment by Michael Osipov [ 29/Jul/14 ]

Please close, wrong project.





[JAXB-1033] disableXmlSecurity doesn't work properly Created: 17/Jul/14  Updated: 17/Jul/14

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

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


 Description   

disableXmlSecurity doesn't work properly when Security Manager enabled:

javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING:
Cannot set the feature to false when security manager is present.
at com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:122)
at com.sun.xml.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:128)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:154)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)






[JAXB-1032] "Unique Particle Attribution" exception when choice is A,B or A+B Created: 03/Jul/14  Updated: 15/Jul/14

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

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


 Description   

I currently have a choice of either having 'field1' OR 'field2'. I need to make additionally possible having both 'field1' AND 'field2' as well. So the choice is to have either field1, field2 or both field1 and field2.

I have the following structure in an XSD:

<xsd:choice>
	<xsd:element name="field1" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:int"/>
		</xsd:simpleType>
	</xsd:element>
	<xsd:element name="field2" nillable="false">
		<xsd:simpleType>
			<xsd:restriction base="xsd:string">
				<xsd:minLength value="1"/>
			</xsd:restriction>
		</xsd:simpleType>
	</xsd:element>
</xsd:choice>

Adding a sequence with both field1 and field2 causes the exception:

	(....)
		</xsd:element>
		<xsd:sequence>
			<xsd:element name="field1" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:int"/>
				</xsd:simpleType>
			</xsd:element>
			<xsd:element name="field2" nillable="false">
				<xsd:simpleType>
					<xsd:restriction base="xsd:string">
					<xsd:minLength value="1"/>
				</xsd:restriction>
			</xsd:simpleType>
		</xsd:element>
	</xsd:sequence>
</xsd:choice>

The exception I'm getting is:

[ERROR] Error while parsing schema(s).Location [ file:...removed...].
org.xml.sax.SAXParseException; systemId: ...removed...; lineNumber: X; columnNumber: Y; cos-nonambig: "ns1":field1 and "ns1":field1 (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)


 Comments   
Comment by Tiou2 [ 03/Jul/14 ]

A workaround is to add another field within the sequence, unfortunately it cannot be made optional:

	<xsd:choice>
		<xsd:element name="oid" type="xsd:int" nillable="false"/>
		<xsd:element name="klantnummer" type="xsd:string" nillable="false"/>
	</xsd:choice>
	<xsd:choice>
		<xsd:element name="field1" type="xsd:int" nillable="false"/>
		<xsd:element name="field2" type="xsd:string" nillable="false"/>
		<xsd:sequence>
			<xsd:element name="dont_use"/>
			<xsd:element name="field1" type="xsd:int" nillable="false"/>
			<xsd:element name="field2" type="xsd:string" nillable="false"/>
		</xsd:sequence>
	</xsd:choice>
Comment by lexi [ 15/Jul/14 ]

Moved to JAXB sind this is not a Maven plugin issue.





[JAXB-1031] JAXB 2.1.x generates errorneous episode File Created: 15/Jul/14  Updated: 03/Oct/14

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

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

Attachments: File sun-jaxb.episode    

 Description   

A user has reported that JAXB-XJC version 2.1.14 generates a bad episode file due to the - string contained in the internal version (v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240-SNAPSHOT). When this version is printed out in the comment, this makes XML invalid.

This also makes JAXB-984 or JAXB-1003 blockers since 2.1.14 is not usable and 2.1.15 and above have invalid POMs.



 Comments   
Comment by lexi [ 15/Jul/14 ]

Attached a sample file.

Note the comment:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.14-hudson-jaxb-ri-2.1-pushtomaven-240--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:36:41 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

Same problem with 2.1.16:

  <!--

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.16-hudson-jaxb-ri-2.1-pushtomaven-250--SNAPSHOT 
See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
Any modifications to this file will be lost upon recompilation of the source schema. 
Generated on: 2014.07.15 at 11:44:54 PM CEST 

  -->
Comment by lexi [ 15/Jul/14 ]

2.1.13 is not affected.

Comment by lexi [ 03/Oct/14 ]

This issue still persists in 2.1.17.





[JAXB-1030] Marshal/Unmarshal not symmetric for Strings with newline characters CR LF Created: 10/Jul/14  Updated: 10/Jul/14

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

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

jaxb 2.2.4-2 in Oracle jdk 7u60



 Description   

We've recently discovered an issue with marshal/unmarshal operations not being symmetric for strings containing newline characters (CR, LF or CRLF) (i.e. the resulting string after a marshal/unmarshal cycle isn't what the original string was).
Since XML parsers must normalize attribute values by replacing newline characters with spaces (reference: http://www.w3.org/TR/REC-xml/#AVNormalize), newline characters need to be escaped properly, but there doesn't seem to be a 'standard' way to tell a Marshaller to do this. Interestingly, this is only an issue if a StreamResult is used. If a DOMResult plus a Transformer is used, newline characters are actually escaped properly.
I'll attach a test case, which shows both ways to do this, with only 'testDomAndTransform' working properly so far.

Note that a very similar issue (JAXB-449) has been filed in the past and is marked as fixed. This doesn't actually seem to be the case, as the test case attached to that issue is still failing.



 Comments   
Comment by barney2k7 [ 10/Jul/14 ]

Here's the test case (not sure how i could have attached this as a file...):

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

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMResult;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import junit.framework.TestCase;

import org.w3c.dom.Document;

public class CrLfMarshalUnmarshalTest extends TestCase {
private static final String VALUE = "abc\r\nd\re\nf";
private Bean fElem;
private Marshaller fMarshaller;
private Unmarshaller fUnmarshaller;

@Override
protected void setUp() throws Exception

{ super.setUp(); JAXBContext ctx = JAXBContext.newInstance(Bean.class); fMarshaller = ctx.createMarshaller(); fUnmarshaller = ctx.createUnmarshaller(); fElem = new Bean(); fElem.setAttributeString(VALUE); fElem.setElementString(VALUE); }

public void testWriter() throws Exception

{ StringWriter sw = new StringWriter(); fMarshaller.marshal(fElem, sw); String resultXml = sw.toString(); System.out.println(resultXml); Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml)); assertEquals(VALUE, resultElem.getAttributeString()); assertEquals(VALUE, resultElem.getElementString()); }

public void testDomAndTransform() throws Exception

{ StringWriter sw = new StringWriter(); DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); DocumentBuilder db = dbf.newDocumentBuilder(); Document d = db.newDocument(); DOMResult result = new DOMResult(d); fMarshaller.marshal(fElem, result); Transformer tf = TransformerFactory.newInstance().newTransformer(); tf.transform(new DOMSource(d), new StreamResult(sw)); String resultXml = sw.toString(); System.out.println(resultXml); Bean resultElem = (Bean) fUnmarshaller.unmarshal(new StringReader(resultXml)); assertEquals(VALUE, resultElem.getAttributeString()); assertEquals(VALUE, resultElem.getElementString()); }

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder =

{"fElementString", "fAttributeString"}

)
@XmlRootElement(name = "Bean")
public static class Bean {

@XmlElement(name = "ElementString")
protected String fElementString;

@XmlAttribute(name = "AttributeString")
protected String fAttributeString;

public String getElementString()

{ return fElementString; }

public void setElementString(String elementString)

{ fElementString = elementString; }

public String getAttributeString()

{ return fAttributeString; }

public void setAttributeString(String attributeString)

{ fAttributeString = attributeString; }

}
}





[JAXB-1029] Incorrect marshalling of object with overridden properties Created: 08/Jul/14  Updated: 09/Jul/14

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

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

java version "1.7.0_03"
jaxb 2.2.7



 Description   
Parent.java
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Parent {
    private String field;

    @XmlElement(name = "field")
    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }
}
Child.java
@XmlRootElement(name = "Node")
@XmlAccessorType(XmlAccessType.PROPERTY)
public class Child extends Parent {
    @Override
    @XmlElement(name = "overridedField")
    public String getField() {
        return super.getField();
    }

    public void setField(String field) {
        super.setField(field);
    }
}

Marshalling using jaxb 2.2.7:

<Node><field>test</field><overridedField>test</overridedField></Node>

jaxb 2.1.13:

<Node><overridedField>test</overridedField></Node>

Property overriding was fixed in JAXB-804 but issue remained in case when child class doesn't contains the field. The only option to get round with property access type is to add field in the Child class



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

Hi vtkhir,

Thank you for reporting. This looks like a bug. I'll take a look asap I'll be able to.


Best regards.
Iaroslav





[JAXB-1028] Unmarshaller sets the incorrect element as nil Created: 03/Jul/14  Updated: 02/Feb/15  Resolved: 02/Feb/15

Status: Closed
Project: jaxb
Component/s: runtime
Affects Version/s: 2.2.6
Fix Version/s: 2.2.11

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


 Description   

I have generated classes for the xml schema below using xjc. I have noticed that when unmarshalling an xml message like the one below where the UserReference element is nil the ResourceSpecification is marked a nil according to the object, even so the object is not null. If I then marshal the object into XML the ResourceSpecification is marked as nil and if I unmarshal it again back into an Object the ResourceSpecification is null.

XSD

<xs:schema elementFormDefault="qualified"
targetNamespace="http://mycompany.com/CoreServices/Entities" xmlns:ser="http://schemas.microsoft.com/2003/10/Serialization/"
xmlns:tns="http://mycompany.com/CoreServices/Entities" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
<xs:complexType name="JobType">
<xs:sequence>
<xs:element name="JobReference" nillable="true" type="xs:string" />
<xs:element name="CurrentResources" nillable="true"
type="tns:ActualResourceAllocations" />
</xs:sequence>
</xs:complexType>
<xs:element name="Job" nillable="true" type="tns:JobType" />
<xs:complexType name="ActualResourceAllocations">
<xs:sequence>
<xs:element name="AllocatedResources" nillable="true"
type="tns:ArrayOfResource" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArrayOfResource">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Resource"
nillable="true" type="tns:Resource" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="Resource">
<xs:sequence>
<xs:element name="UserReference" nillable="true" type="xs:string" />
<xs:element minOccurs="0" name="ResourceSpecificationB"
nillable="true" type="tns:ResourceSpecification" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResourceSpecification">
<xs:sequence>
<xs:element name="ResourceSpecificationId" type="xs:int" />
<xs:element name="SpecUserReference" nillable="true" type="xs:string" />
<xs:element name="Description" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>

Example XML

<a:Job xmlns="http://mycompany.com/CoreServices" xmlns:a="http://mycompany.com/CoreServices/Entities"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:JobReference>ESB234-TC015_LG</a:JobReference>
<a:CurrentResources>
<a:AllocatedResources>
<a:Resource>
<a:UserReference i:nil="true" />
<a:ResourceSpecificationB>
<a:ResourceSpecificationId>1</a:ResourceSpecificationId>
<a:SpecUserReference>as</a:SpecUserReference>
<a:Description>Default</a:Description>
</a:ResourceSpecificationB>
</a:Resource>
</a:AllocatedResources>
</a:CurrentResources>
</a:Job>

Example unit test
package com.mycompany.xml;

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

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;

import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.mycompany.ws.mywebservice.JobType;
import com.mycompany.ws.mywebservice.Resource;

/**

  • This is a test
    *
    */
    public class NilTest {

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

@Test
public void testNil() throws Exception {
JAXBContext context = JAXBContext.newInstance(JobType.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
Object a = unmarshaller.unmarshal(new File("src/test/resources/failingmessage.xml"));

JAXBElement<JobType> jobTypeElement = (JAXBElement<JobType>) a;
JobType jobType = jobTypeElement.getValue();
for (Resource r : jobType.getCurrentResources().getAllocatedResources().getResource())

{ LOG.info("resource specification " + r.getResourceSpecificationB()); LOG.info("resource specification is nil " + r.getResourceSpecificationB().isNil()); LOG.info("Descriptor " + r.getResourceSpecificationB().getValue().getDescription()); }

Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
StringWriter sw = new StringWriter();
marshaller.marshal(a, sw);
System.out.print(sw.toString());

StringReader sr = new StringReader(sw.toString());
a = unmarshaller.unmarshal(sr);

jobTypeElement = (JAXBElement<JobType>) a;
jobType = jobTypeElement.getValue();
for (Resource r : jobType.getCurrentResources().getAllocatedResources().getResource())

{ LOG.info("resource specification " + r.getResourceSpecificationB()); LOG.info("resource specification is nil " + r.getResourceSpecificationB().isNil()); LOG.info("Descriptor " + r.getResourceSpecificationB().getValue().getDescription()); }

}

}



 Comments   
Comment by kylape [ 05/Aug/14 ]

I tested the reproducer posted, and it seems to work as reported.

I created a (hopefully) simpler reproducer:

<xs:schema xmlns:tns="http://jaxb.gss.redhat.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0" targetNamespace="http://jaxb.gss.redhat.com/">
  <xs:element name="team" type="tns:team"/>
  <xs:complexType name="team">
    <xs:sequence>
      <xs:element ref="tns:abstractName"/>
      <xs:element ref="tns:member"/>
    </xs:sequence>
  </xs:complexType>
  <xs:element abstract="true"  name="abstractName" nillable="false"/>
  <xs:element abstract="false" name="name"         nillable="true" substitutionGroup="tns:abstractName" type="xs:string"/>
  <xs:element abstract="true"  name="member"       nillable="false"/>
  <xs:element abstract="false" name="programmer"   nillable="true" substitutionGroup="tns:member" type="xs:string"/>
</xs:schema>

Code to test:

package com.redhat.gss.jaxb;

import java.net.URL;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;

public class Test {
  private static JAXBContext ctx = null;

  public static void main(String[] args) throws Exception {
    ctx = JAXBContext.newInstance(ObjectFactory.class, Team.class, String.class);
    URL inputUrl = Test.class.getResource("/no-nil.xml");
    System.out.println("Non-nil test.");
    doTest(inputUrl);
    System.out.println("\nNil test.  Member should NOT be nil");
    inputUrl = Test.class.getResource("/nil.xml");
    doTest(inputUrl);
  }

  public static void doTest(URL inputUrl) throws Exception {
    Unmarshaller unm = ctx.createUnmarshaller();
    Object o = unm.unmarshal(inputUrl);
    Team team = ((JAXBElement<Team>)o).getValue();
    System.out.println("Name: " + team.getAbstractName().getValue());
    System.out.println("Name nil? " + (team.getAbstractName().isNil() ? "YES" : "NO"));
    System.out.println("Member: " + team.getMember().getValue());
    System.out.println("Member nil? " + (team.getMember().isNil() ? "YES" : "NO"));
  }
}

nil.xml:

<team xmlns="http://jaxb.gss.redhat.com/">
  <name xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
  <programmer>Kyle</programmer>
</team>

no-nil.xml:

<team xmlns="http://jaxb.gss.redhat.com/">
  <name>SEG</name>
  <programmer>Kyle</programmer>
</team>
Comment by kylape [ 05/Aug/14 ]

Pull request: https://github.com/gf-metro/jaxb/pull/3

Comment by Iaroslav Savytskyi [ 02/Feb/15 ]

Already fixed in 2.2.11





[JAXB-1027] NullPointerException with @XmlRootElement and @XmlValue Created: 22/Jun/14  Updated: 22/Jun/14

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)






[JAXB-1026] Running XJC with BOTH a binding file and a catalog that re-writes system ID's can lead to multiple type declaration errors Created: 19/Jun/14  Updated: 19/Jun/14

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

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


 Description   

When calling XJC with using a catalog that does a re-write of the SystemID:

REWRITE_SYSTEM "http://foo.blah.com/MySchema.xsd" "MyNewLocation.xsd"

AND there is a binding file added (it can be an empty binding file or a binding file with a globalBinding), and the schema ends up in a circular import loop, it can result in "already defined" errors.

The root cause is on line 296 of DOMForest (xjc version 2.2.11). The InputSource returned from:

 if( entityResolver!=null )
            is = entityResolver.resolveEntity(null,systemId);

could have a new systemId. However, when it calls the parse on line 301, it passes the old system id. That is then used as the key for the call to "core.add" (line 383).

Note: if you DON'T us a binding file, this is not a problem as the optimized code path for that does not suffer from this issue. In that case, line 342 of NGCCRuntimeEx properly calls the source.getSystemId() to get the system ID that it then uses.



 Comments   
Comment by dkulp [ 19/Jun/14 ]

I cannot find an option to attach a file to this issue that includes a test case.

A test case that demonstrates the problem can be found at:

http://dankulp.com/JAXB-1026.tar.gz





[JAXB-1025] Single schema works but not multiple schema Created: 07/Jun/14  Updated: 07/Jun/14

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

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

windows 8.1 Enterprise



 Description   

Validation works with single schema but does not work with multiple schema. Java objects created by xjc are same. My tests works when it is a single schema but gives validation error when I use multiple schema, cvc-elt.1: Cannot find the declaration of element 'itinerary'.

There is no single difference between single and multiple schema except it is divided in number of schemas.

Why is validation failing?

I have used 2.2.7 and 2.2.11-SNAPSHOT. Gives the same error.

I can provide a maven project that can demonstrate this case.

I will appreciate any help.

BR
Lulseged

For single:

Source source = new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd");

For multiple:
Source[] source = new StreamSource[]
{
new StreamSource(getClass().getResourceAsStream("/xsd/travel.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/plane.xsd")),
new StreamSource(getClass().getResourceAsStream("/xsd/itinerary.xsd"))
};

Schema schema = schemaFactory.newSchema(source);

When using

Single schema:
itinerary.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xsd:element name="travel" type="e:travel-type" />

<xsd:complexType name="travel-type" abstract="true">
<xsd:sequence>
<xsd:element name="origin" type="xsd:string" />
<xsd:element name="destination" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>

<!-- plane -->
<xsd:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xsd:complexType name="plane-type">
<xsd:complexContent>
<xsd:extension base="e:travel-type">
<xsd:sequence>
<xsd:element name="flightNumber" type="xsd:int" />
<xsd:element name="meal" type="xsd:string" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<!-- itinerary -->
<xsd:element name="itinerary" type="e:itinerary-type" />

<xsd:complexType name="itinerary-type">
<xsd:sequence>
<xsd:element ref="e:travel" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>

</xsd:schema>

Multiple schema:
travel.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:element name="travel" type="e:travel-type" />

<xs:complexType name="travel-type" abstract="true">
<xs:sequence>
<xs:element name="origin" type="xs:string" />
<xs:element name="destination" type="xs:string" />
</xs:sequence>
</xs:complexType>

</xs:schema>

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

<xs:include schemaLocation="travel.xsd" />

<xs:include schemaLocation="plane.xsd" />

<xs:element name="itinerary" type="e:itinerary-type" />

<xs:complexType name="itinerary-type">
<xs:sequence>
<xs:element ref="e:travel" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:schema>

plane.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://example.org/" targetNamespace="http://example.org/"
elementFormDefault="qualified" attributeFormDefault="qualified">

<xs:include schemaLocation="travel.xsd" />

<xs:element name="plane" type="e:plane-type" substitutionGroup="e:travel" />

<xs:complexType name="plane-type">
<xs:complexContent>
<xs:extension base="e:travel-type">
<xs:sequence>
<xs:element name="flightNumber" type="xs:int" />
<xs:element name="meal" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>






[JAXB-1024] we are having multiple schema which is having same element name and same namespace Created: 03/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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

Windows 7 , jboss EAP 6.1 Final , jdk java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)


Tags: jax-ws, jaxb, jaxb-xjc, jboss, metro

 Description   

our application generates the web service classes using JAXB / XJC compiler. we are giving multiple schema as the input to get the java classes for web services . The schema files will be compiled each one and put into the separate packages. assume we are having X and Y schema , just like below mentioned schema. Each schema having same element name , but having the type of complexType .but different complex type. When compilation it will generate the multiple ObjectFactory. This web service , we are trying to deploy in jboss EAP 6.1 ,results the problem of illegalAnnotationException. Can you please anyone advise?

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
The element name {}row has more than one mapping.
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XType.ObjectFactory.createRow(com.xxx.tws.pojo.XType.XType)
at com.xxx.tws.pojo.XType.ObjectFactory
this problem is related to the following location:
at public javax.xml.bind.JAXBElement com.xxx.tws.pojo.XTESTType.ObjectFactory.createRow(com.xxx.tws.pojo.XTESTType.XTESTType)
at com.xxx.tws.pojo.XTESTType.ObjectFactory

X:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XType"></xsd:element>
<xsd:complexType name="XType">
</xsd:complexType
</xsd:schema

Y:
**
<?xml version="1.0"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty">
<xsd:element name="row" type="XTESTType"></xsd:element>
<xsd:complexType name="XTESTType">
</xsd:complexType
</xsd:schema



 Comments   
Comment by androidgalaxyman [ 26/Jun/14 ]

Please close this issue. we have resolved by giving name space for each schema. Thanks

Comment by Martin Grebac [ 26/Jun/14 ]

Thanks.





[JAXB-1023] Java SE 8: generated Javadoc comments: error: bad use of '>' Created: 17/May/14  Updated: 17/May/14  Resolved: 17/May/14

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

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

Java: 1.8.0_05; Java HotSpot(TM) 64-Bit Server VM 25.5-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_05-b13
System: Linux version 3.11.0-19-generic running on amd64; UTF-8; de_CH (nb)


Issue Links:
Duplicate
duplicates JAXB-973 generated code should be compilable w... Resolved
Tags: java8, javadoc, xjc

 Description   

The Javadoc comments generated by XJC contains '>' instead of '>'.

This results in

error: bad use of '>'

with the default configuration of Javadoc of Java SE 8.

Tested with locale: de_CH

Here is a sample output from the Drombler ACP project:

/**

  • <p>Java-Klasse für application element declaration.
  • <p>Das folgende Schemafragment gibt den erwarteten Content an, der in dieser Klasse enthalten ist.
  • <pre>
  • <element name="application">
  • <complexType>
  • <complexContent>
  • <restriction base=" {http://www.w3.org/2001/XMLSchema}

    anyType">

  • <sequence>
  • <element name="extensions" type=" {http://www.drombler.org/schema/acp/application}

    ExtensionsType" minOccurs="0"/>

  • </sequence>
  • </restriction>
  • </complexContent>
  • </complexType>
  • </element>
  • </pre>
  • */



 Comments   
Comment by puce [ 17/May/14 ]

JIRA reformated some of the texts and I can't edit it. The correct output would be '&gt;'

Comment by puce [ 17/May/14 ]

Here the sample output again:

/**
 * <p>Java-Klasse für application element declaration.
 * 
 * <p>Das folgende Schemafragment gibt den erwarteten Content an, der in dieser Klasse enthalten ist.
 * 
 * <pre>
 * &lt;element name="application">
 *   &lt;complexType>
 *     &lt;complexContent>
 *       &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *         &lt;sequence>
 *           &lt;element name="extensions" type="{http://www.drombler.org/schema/acp/application}ExtensionsType" minOccurs="0"/>
 *         &lt;/sequence>
 *       &lt;/restriction>
 *     &lt;/complexContent>
 *   &lt;/complexType>
 * &lt;/element>
 * </pre>
 * 
 * 
 */
Comment by Lukas Jungmann [ 17/May/14 ]

duplicate of JAXB-973 and JAXB-1022





[JAXB-1022] '>' not escaped in doclet comments Created: 14/May/14  Updated: 18/Feb/15

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

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

Tags: maven, xjc

 Description   

When generating the JAXB classes using XJC, the javadoc example xml instance has the '<' properly encoded while the closing '>' is not.
The result is that if one is making a maven release which triggers the javadoc compilation the errors will break that step thus the whole release.
This was observed on MacOSX and JDK8.



 Comments   
Comment by Lukas Jungmann [ 14/May/14 ]

I'd say this is jdk8 related, duplicate of https://java.net/jira/browse/JAXB-973 and not a blocker, since workaround is to pass -Xdoclint:none to javadoc executable as is documented ie here: http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html

Comment by p.gillissen [ 18/Feb/15 ]

hi schrepfler
I had the same issue (with Java 7) and solved it by updating the Maven JAXB plugin (org.jvnet.jaxb2.maven2:maven-jaxb2-plugin) to version 0.12.3. Now all my > are correctly escaped.





[JAXB-1021] When an element have same name that his element ancestor, jvc generate bad java classes, with a parent and a son with the same name. Created: 13/May/14  Updated: 13/May/14

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

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

Windows 7 64,


Tags: element, name, same

 Description   

If you have en element with the same name that his parent, jvc run without problems but generate bad java classes.
If you tray to binding the name, then jvc generate a run time error like:

D:\PCBCK\Java\jaxb\jaxb-ri-2.2.7\samples\aod>xjc -nv -verbose messages.xsd -b bindingset.xml
Exception in thread "main" java.lang.IllegalArgumentException: Illegal class inheritance loop.
Outer class TargetSpeedElement may not subclass from inner class:
<<classnale>>
at com.sun.codemodel.internal.JDefinedClass._extends(JDefinedClass.java:257)
at com.sun.tools.internal.xjc.generator.bean.ImplStructureStrategy$1._extends(ImplStructureStrategy.java:104)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:197)
at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)






[JAXB-1020] XmlIDREF is ignored in subclass, causing 'A cycle is detected in the object graph. This will cause infinitely deep XML:' Created: 13/May/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

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

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

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

running under Windows 7 64bit



 Description   

The version of JAXB is whatever was included in the JDK.

A Container type class includes a child type class;

public class Container {

@XmlID
public String id = "Container-" + UUID.randomUUID().toString();

public Set<Contained> children = new HashSet<Contained>();
}

The child has a reference to its container via an @XmlIDREF, which means the child will NOT include the container's XML.

public class Contained {

//Because container is a reference only it should not cause 'infinitely deep XML'
@XmlIDREF
public Container container;
}

If I create an object tree and marshall it, this works fine.
HOWEVER if I create a Subclass of Container:

public class ContainerSub extends Container {
}

it DOES NOT.

This is potentially related to https://java.net/jira/browse/JAXB-870

Test case:

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Root {

public Container container;
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

import java.util.HashSet;
import java.util.Set;
import java.util.UUID;

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

@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)
public class Container {

@XmlID
public String id = "Container-" + UUID.randomUUID().toString();

public Set<Contained> children = new HashSet<Contained>();
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

public class ContainerSub extends Container {
}

--------------------------------------------------------------
package uk.co.his.test.jaxb.metrobug;

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

@XmlAccessorType( XmlAccessType.PUBLIC_MEMBER )
public class Contained {

//Because container is a reference only it should not cause 'infinitely deep XML'
@XmlIDREF
public Container container;
}

--------------------------------------------------------------

package uk.co.his.play;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;

import org.junit.Test;

import uk.co.his.test.jaxb.metrobug.Contained;
import uk.co.his.test.jaxb.metrobug.Container;
import uk.co.his.test.jaxb.metrobug.ContainerSub;
import uk.co.his.test.jaxb.metrobug.Root;

public class JAXBbugs {

@Test
public void idRefsDoBreakCyclesInJdkJAXBinSuperClass() throws JAXBException

{ Root root = new Root(); root.container = new Container(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); JAXBContext context = createJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

@Test
public void idRefsShouldBreakCyclesInJdkJAXBinSubclass() throws JAXBException

{ Root root = new Root(); root.container = new ContainerSub(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); JAXBContext context = createJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

@Test
public void idRefsDoBreakCyclesInMoxy() throws JAXBException

{ Root root = new Root(); root.container = new ContainerSub(); Contained child = new Contained(); child.container = root.container; root.container.children.add(child); org.eclipse.persistence.jaxb.JAXBContext context = createMoxyJAXBContext(Root.class); Marshaller m = context.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.marshal(root, System.out); }

private static JAXBContext createJAXBContext(Class<?> clazz) throws JAXBException

{ return JAXBContext.newInstance(clazz); }

private static org.eclipse.persistence.jaxb.JAXBContext createMoxyJAXBContext(Class<?> clazz) throws JAXBException {
Class<?> clazzs[] =

{ clazz }

;
return (org.eclipse.persistence.jaxb.JAXBContext) org.eclipse.persistence.jaxb.JAXBContextFactory.createContext(clazzs, null);
}
}



 Comments   
Comment by iain.wilson [ 14/Oct/14 ]

Just to confirm that I have witnessed the same issue with Version 7 Update 67 and would agree with the status of the Jira.

Some comment on here from the devs would be appreciated so there is some visibility of when or if this issue is likely to be fixed.

Comment by Iaroslav Savytskyi [ 14/Oct/14 ]

Hi Iain,

Thanks for reporting. I can confirm that within JDK7 there is a bug with inherited cycle dependencies.

But it's already fixed in latest JAXB 2.2.11.

Comment by Iaroslav Savytskyi [ 14/Oct/14 ]

Already fixed.





[JAXB-1019] Invalid boolean values added to lists as 'false' (part 2) Created: 12/May/14  Updated: 12/May/14

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

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


 Comments   
Comment by kylape [ 12/May/14 ]

This is a continuation of JAXB-849. While that jira fixed some cases of illegal xs:boolean values, there are still others that return false when they should return null, namely values that start with t and f. It looks like changing these two lines to return null would do the trick:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L270
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L285

In addition, if the string literals "t" and "f" are passed in, this will cause an unmarshalling error:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:203) [rt.jar:1.7.0_55]
        at java.lang.StringBuilder.charAt(StringBuilder.java:72) [rt.jar:1.7.0_55]
        at com.sun.xml.bind.DatatypeConverterImpl._parseBoolean(DatatypeConverterImpl.java:260)

This would map to either of these two lines on master:

https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L264
https://github.com/gf-metro/jaxb/blob/master/jaxb-ri/runtime/impl/src/main/java/com/sun/xml/bind/DatatypeConverterImpl.java#L278

Comment by kylape [ 12/May/14 ]

Pull request for this issue (with added test case): https://github.com/gf-metro/jaxb/pull/2





[JAXB-1018] NPE when using mixed element and episode Created: 10/May/14  Updated: 10/May/14

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

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


 Description   

I'm trying to compile two XSD files using an episode file:

The first one:
xjc -d out -episode schema_1.episode schema_1.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://example.com/schema_1"
	   xmlns:ns1="http://example.com/schema_1"
	   xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:element name="Element">
		<xs:complexType>
			<xs:simpleContent>
				<xs:extension base="xs:string">
					<xs:attribute name="Attribute" type="xs:string" use="optional" />
				</xs:extension>
			</xs:simpleContent>
		</xs:complexType>
	</xs:element>

</xs:schema>

Then I try to compile the second file:
xjc -verbose -d out schema_2.xsd -extension -b schema_1.episode

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
	targetNamespace="http://example.com/schema_2"
	xmlns:ns1="http://example.com/schema_1"
	xmlns:ns2="http://example.com/schema_2"
	xmlns:xs="http://www.w3.org/2001/XMLSchema">

	<xs:import namespace="http://example.com/schema_1" schemaLocation="schema_1.xsd" />

	<xs:complexType name="Abstract" abstract="true" mixed="true">
		<xs:sequence>
			<xs:element ref="ns1:Element" minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>

</xs:schema>

This will result in.

Exception in thread "main" java.lang.NullPointerException
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:173)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:146)
        at com.sun.tools.internal.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:114)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:97)
        at com.sun.tools.internal.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:62)
        at com.sun.tools.internal.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:67)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:759)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:540)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:243)
        at com.sun.tools.internal.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
        at com.sun.tools.internal.xjc.model.Model.generateCode(Model.java:275)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:342)
        at com.sun.tools.internal.xjc.Driver.run(Driver.java:184)
        at com.sun.tools.internal.xjc.Driver._main(Driver.java:107)
        at com.sun.tools.internal.xjc.Driver.access$000(Driver.java:64)
        at com.sun.tools.internal.xjc.Driver$1.run(Driver.java:87)

If I drop the mixed="true" or if I place both elements in one XSD the compilation will succeed.






[JAXB-1017] Messages.properties: Incorrect value for CONFLICTING_XML_ELEMENT_MAPPING Created: 07/May/14  Updated: 07/May/14

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

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


 Description   

When JAXB wants to read the string for following error:

CONFLICTING_XML_ELEMENT_MAPPING = \
    The element name '{'{0}'}'{1} has more than one mapping.

the original error will be lost because the formatting of the string fails and a new exception will be thrown:

java.lang.IllegalArgumentException: can't parse argument number ''{0}''
	at java.text.MessageFormat.makeFormat(MessageFormat.java:1339)[:1.6.0_25]
	at java.text.MessageFormat.applyPattern(MessageFormat.java:458)[:1.6.0_25]
	at java.text.MessageFormat.<init>(MessageFormat.java:350)[:1.6.0_25]
	at java.text.MessageFormat.format(MessageFormat.java:811)[:1.6.0_25]
	at com.sun.xml.bind.v2.model.impl.Messages.format(Messages.java:133)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.TypeInfoSetImpl.add(TypeInfoSetImpl.java:306)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.RegistryInfoImpl.<init>(RegistryInfoImpl.java:121)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.addRegistry(ModelBuilder.java:362)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:332)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:460)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:298)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:141)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1163)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)[jaxb-impl-2.2.5-2.jar:2.2.5-2]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_25]
	at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)[:1.6.0_25]
	at javax.xml.bind.ContextFinder.find(ContextFinder.java:363)[:1.6.0_25]
	at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:267)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at java.security.AccessController.doPrivileged(Native Method)[:1.6.0_25]
	at org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:265)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:172)[cxf-api-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:464)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:330)[cxf-rt-databinding-jaxb-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:478)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:690)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:540)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:252)[cxf-rt-core-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:205)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:90)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:156)[cxf-rt-frontend-simple-2.7.4.jar:2.7.4]
	at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:156)[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]

I used the version 2.2.5 but I've been taking a look to the newest version(2.2.7 and 2.2.7-b63) and there the message string is still the same. So I think this issue is still present



 Comments   
Comment by soilworker [ 07/May/14 ]

I see now that it only appears with the german language(Messages_de.properties).





[JAXB-1016] Importing elements from schema with no namespace into schema with a namespace fails Created: 30/Apr/14  Updated: 30/Apr/14

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

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

Windows 7 or Linux, Java 6u18



 Description   

I have a complex schema most of which uses the empty namespace, except for one file, CDQobjects.xsd. The elements in there need to rely on some elements from the empty namespace and imports the appropriate file CreditCurves.xsd. However when I run xjc on the schema it fails with error:

parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'RelativeCreditSpreadCurve' to a(n) 'element declaration' component.
line 13 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

[ERROR] src-resolve: Cannot resolve the name 'CreditSpreadCurve' to a(n) 'element declaration' component.
line 14 of file:/opt/app/ci/workspace/trunk/domain/pricing/src/main/xsd/CDQobjects.xsd

However, if I remove all of the other schema files and leave just the one with the error and the one it relies on, without editing them:

  • CDQobjects.xsd
  • CreditCurves.xsd

Then xjc creates the java classes correctly.

I tried to whittle down the test case to a simpler schema to make it easier for you to reproduce the problem but I ran into some strange and seemingly improbable dependencies:

  • I got the test set down to just 3 files, and the addition the 3rd (unreferenced) xsd file would cause the error to appear. However, when I moved this schema to a different dir to package them up, I noticed that the error did not occur on the copy!
  • In a different test, I changed the name of CreditCurves.xsd to BeforeCDQobjectsCreditCurves.xsd and the error went away when I used xjc on Windows 7, but still occurred on our build server on Linux.

The error seems to consistently occur on Windows with the package of Schema files that I have attached. I hope you can reproduce it locally and then just delete bits until you get to a simple case that reliably fails and helps you uncover the problem.

Ah. I just started looking for the attach button to include the schema and there doesn't seem to be one! How should I send you the test case?






[JAXB-1015] Quote character is not replaced by U+0022 during marshalling Created: 29/Apr/14  Updated: 07/May/14

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

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

Java1.8u05 + Maven3



 Description   

There is a problem when marshalling object that contains XML string with quote character.
Character " is not replaced by '"'.
Here is JUnit test that fails:

public class WrappedXMLMarshallingTest {

    @Test
    public void shouldMarshallWrappedXML() throws JAXBException {
        // given
        Message message = new Message("<frame type=\"1.0\">test</frame>");
        Marshaller marshaller = createMessageMarshaller();
        ByteArrayOutputStream result = new ByteArrayOutputStream();

        // when
        marshaller.marshal(message, result);

        // then
        String expectedResult =
                "<message><content>&lt;frame type=&quot;1.0&quot;&gt;test&lt;/frame&gt;</content></message>";
        assertEquals(expectedResult, result.toString());
    }

    private Marshaller createMessageMarshaller() throws JAXBException {
        JAXBContext context = JAXBContext.newInstance(Message.class);
        Marshaller marshaller = context.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");
        marshaller.setProperty(Marshaller.JAXB_FRAGMENT, true);
        return marshaller;
    }

    @XmlAccessorType(XmlAccessType.FIELD)
    @XmlType(name = "", propOrder = {
            "content"
    })
    @XmlRootElement(name = "message")
    static class Message {
        private String content;

        private Message() {
        }

        private Message(String content) {
            this.content = content;
        }

        String content() {
            return content;
        }
    }
}


 Comments   
Comment by j.malek [ 07/May/14 ]

It looks like I made a mistake, """ is used to allow attribute values to contains double quotes, in this scenario quote is used in xml element so marshalling works fine.





[JAXB-1014] eclipse Luna reports an error in classes generated by JAXB Created: 22/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

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

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

Windows 8.1 x64, eclipse Luna M6, JRE 7u55



 Description   

When generating Java classes for a simple xsd file, one of the generated Java classes shows the error
The expected XML type associated with 'int' is not valid for XML element 'ARQPriority'
but the xsd file seems correct, and the generated Java code also seems correct.
Since I don't see a way to attach a file to the report, here is the sample xsd file, the error is in the Java class generated for ARQParameterSetType. If desired, I can provide the whole eclipse Luna project.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="xs3p.xsl"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns="http://test" 
            xmlns:mdl="http://test" 
            targetNamespace="http://test" 
            elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xsd:element name="MDLRoot" type="MDLRootType"/>
  <xsd:complexType name="MDLRootType">
    <xsd:sequence>
      <xsd:element name="RadioLink" type="RadioLinkType" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="RadioLinkType">
    <xsd:sequence>
      <xsd:element name="ARQParameterSet" type="ARQParameterSetType" minOccurs="0" maxOccurs="8"/>
    </xsd:sequence>
    <xsd:attribute name="ID" type="xsd:ID" use="required"/>
  </xsd:complexType>
  <xsd:complexType name="ARQParameterSetType">
    <xsd:sequence>
      <xsd:element name="ARQPriority" type="ARQPriorityType"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:simpleType name="ARQPriorityType">
    <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="0"/>
      <xsd:maxInclusive value="7"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>


 Comments   
Comment by Pavel Bucek [ 22/Apr/14 ]

just a side-question: why are you filing this bug against JAXB when you state that the problem is most likely on Eclipse Luna side?

Comment by andreaMz [ 22/Apr/14 ]

It is my understanding that Eclipse simply reports an error that is generated by JAXB, since in the Problems view the Type is listed as "JAXB Problem". Besides, the problem is reported the same way in Eclipse Juno.

Comment by Pavel Bucek [ 22/Apr/14 ]

Ok, sounds more valid now.

Next time, you can include that info as well (generally, you want to add as much relevant info as possible...). It could be useful to know which component reports these issues to confirm that the info Juno is displaying is from JAXB; have you tried to marshal/unmarshal with registered ValidationEventHandler? Did that produced anything?

And please add a link to the issue reported agains Eclipse Juno, it might be useful (especially if that contains more informations).

Thanks!

Comment by andreaMz [ 22/Apr/14 ]

As you can imagine, the sample xsd file I included in my report is a subset of a much larger and complex third party xsd file. I was able to unmarshal and marshal xml files corresponding to the original xsd without any validation issue reported. The only "problem" are these errors showing up in many of the classes generated from the original xsd file.
If that would help reproduce the problem, I could upload a zip of the eclipse project that produces it, but I need to know how (where) to upload it. Also, since not many people use Eclipse Luna yet, should I upload a project for Eclipse Juno? would that be simpler to use?

Comment by Pavel Bucek [ 22/Apr/14 ]

The best would be if you could find minimal XML schema which will reproduce the issue, without any other complex external schemas and then "upload" your project somewhere (preferably github). I guess you don't really need to upload project files for "all" other versions, just state that this issue is reproducible on older (Juno, ..) eclipse versions, so it is not a regression.

// the link to issue agains Eclipse Luna is still missing

Comment by andreaMz [ 22/Apr/14 ]

I have further simplified the sample vsd, and I think I have found what causes the problem.
This xsd generates the error message:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="xs3p.xsl"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns="http://test" 
            targetNamespace="http://test" 
            elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xsd:element name="MDLRoot" type="MDLRootType"/>
  <xsd:complexType name="MDLRootType">
    <xsd:sequence>
      <xsd:element name="RadioLink" type="ARQPriorityType" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:simpleType name="ARQPriorityType">
    <xsd:restriction base="xsd:integer">
      <xsd:minInclusive value="0"/>
      <xsd:maxInclusive value="7"/>
    </xsd:restriction>
  </xsd:simpleType>
</xsd:schema>

while simplifying the xsd:restriction element removes the error message:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="xs3p.xsl"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns="http://test" 
            targetNamespace="http://test" 
            elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xsd:element name="MDLRoot" type="MDLRootType"/>
  <xsd:complexType name="MDLRootType">
    <xsd:sequence>
      <xsd:element name="RadioLink" type="ARQPriorityType" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:simpleType name="ARQPriorityType">
    <xsd:restriction base="xsd:integer"/>
  </xsd:simpleType>
</xsd:schema>

Actually, the xsd:minInclusive and xsd:maxinclusive elements don't really generate any code, so, could it be that JAXB generates the error because it cannot generate code that fully matches the given xsd? In that case, wouldn't it be a better idea to make it "warnings" instead of "errors"?

I am sorry, I don't know how to link the issue against Eclipse Luna. Can you please explain it to me?

Comment by Pavel Bucek [ 22/Apr/14 ]

Well, I thought that this issue is already filed also agains Eclipse project. Seems like it is not. (And it should be!)

Can you reproduce this "error" by using any JAXB API? Because if not, it seems like you don't have any proof that Eclipse is using JAXB to generate these messages, thus we don't really know where the code which is producing this message really is. It might be useful to capture a screen with that message, so we can at least search for that particular message in JAXB codebase. Anyway, I still think that this report is invalid (issue is not in JAXB impl).

Comment by andreaMz [ 22/Apr/14 ]

Well, it happens in an Eclipse "JAXB Project" that claims to use "Generic JAXB 2.2", and reports the problem as a "JAXB Problem", so it seems to be likely that eclipse uses JAXB...
Anyway, I will try to generate the classes outside of Eclipse and see what happens. As for the exact text of the error, should you want to search for it in the JAXB codebase, it is:
The expected XML type associated with '<Java type>' is not valid for XML element '<element name>'

Comment by andreaMz [ 23/Apr/14 ]

I generated the Java classes invoking directly the xjc.exe of the JDK, and I did not see any error.

The only difference between the classes generated using the eclipse JAXB project and those generated from the JDK is that the classes generated from the eclipse JAXB project specify

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.2-147

while those generated from the JDK specify

This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.4-2

Do you know where the vhudson-jaxb-ri-2.2-147 comes from? Is there a way to download / invoke it directly to see if it would generate the error?

Comment by Martin Grebac [ 23/Apr/14 ]

I believe it should be the 2.2 release: https://jaxb.java.net/2.2/ (note it's almost 5y old).

Comment by Pavel Bucek [ 23/Apr/14 ]

2.2-147 seems like version 2.2 released to maven central. Manifest file states that this is build 146, but that should be the same.

link: http://search.maven.org/#artifactdetails%7Ccom.sun.xml.bind%7Cjaxb-impl%7C2.2%7Cjar

Comment by andreaMz [ 23/Apr/14 ]

I have downloaded version 2.2 from maven central (file jaxb-impl-2.2.jar), but I really don't see how to use the classes it contains to generate Java classes from a schema file. Obviously I have reached the point where my non-understanding of JAXB internals has become an issue. Somebody with more expertise needs to take over from here, or give me detailed instructions on how to proceed.

I have posted my problem to the eclipse Dali forum, hopefully somebody will have an idea about what happens, but so far we need to wait for the moderator to post my question.

Thank you for your help.

Comment by Pavel Bucek [ 23/Apr/14 ]

Well, jaxb-xjc is the jar you are looking for: http://search.maven.org/#artifactdetails%7Ccom.sun.xml.bind%7Cjaxb-xjc%7C2.2%7Cjar

but! you can use the bundle from jaxb.java.net site, which Martin pointed out: https://jaxb.java.net/2.2/. It will install jaxb with command line commands (like xjc), so that should be easier and more familiar.

Comment by andreaMz [ 23/Apr/14 ]

I used the bundle from the jaxb.java.net site to generate the Java classes. This time the generated class specifies
This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.2-147
like the classes generated by the eclipse JAXB project, and I still don't see any error message.

There is still the possibility that the eclipse JAXB project would use some additional arguments that could cause a stricter validation, but I have not found anything that could have that effect, and I don't know how to see the xjc invocation done by the JAXB project.

At this point I think I just need to wait to see if there will be any reaction to my post on the eclipse Dali forum.

Thank you again for your help.

Comment by Iaroslav Savytskyi [ 23/Apr/14 ]

As I understand the problem is not in JAXB RI. I'll close the issue. If you will find a way (parameters, flags, etc) how to reproduce it with JAXB RI - please let me know.

Comment by andreaMz [ 23/Apr/14 ]

Before closing it, could you please do a quick search in the JAXB sources to see if the message
The expected XML type associated with '<Java Class>' is not valid for XML element '<element name>'
is generated anywhere?
Thank you

Comment by Iaroslav Savytskyi [ 23/Apr/14 ]

We don't have this message in JAXB. But it could be JAXP validation message.

Comment by andreaMz [ 23/Apr/14 ]

You must be absolutely correct: when I removed the validation builder (org.eclipse.wst.validation.validationbuilder) from the project, the error message disappeared.
So I fully agree: you should close this issue.
Thank you all for your help!





[JAXB-1013] xjc:substitutable does not work in JAXB 2.2.7 anymore Created: 16/Apr/14  Updated: 16/Apr/14

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

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


 Description   

The original Jira JAXB-289 proposed a solution to fix the substitution resulting in rather inconvenient JAXBElement<T> used when the type was abstract and part of a substitution group. Also the documentation at https://jaxb.java.net/2.2.7/docs/ch05.html#substitutable suggests that this feature should work.

However it does not seem to work with JAXB-RI 2.2.7 anymore.

I have attached the original test files from JAXB-289 as simple maven project using the maven-jaxb22-plugin. The project contains a default profile to show the output that is undesirable. You can run and inspect using following maven command:

mvn clean install

The profile substitutable will just trigger a generation using the annotated schema as per documentation and the Jira issue. You can run this build with following maven command:

mvn clean install -Psubstitutable

The exact stack trace error is:

com.sun.istack.SAXParseException2; systemId: file:///.../base/Model.xsd; lineNumber: 8; columnNumber: 37; compiler was unable to honor this substitutable customization. It is attached to a wrong place, or its inconsistent with other bindings.
...
com.sun.istack.SAXParseException2; systemId: file:///.../base/Model.xsd; lineNumber: 5; columnNumber: 43; (the above customization is attached to the following location in the schema)


 Comments   
Comment by Niels Bertram [ 16/Apr/14 ]

Tried to attach the example testcase but have no access. You can find the example on GitHub at https://github.com/bertramn/jaxb-substitutable-example .





[JAXB-1012] No default constructor found on class javax.xml.bind.JAXBElement - Need know why Created: 07/Apr/14  Updated: 08/Apr/14

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

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

Win 7 64b, JavaSE 7


Tags: unmarshalling

 Description   

Hi,

I have generated Java code from XSD, using xjc tool, sheme is here : http://dd.eionet.europa.eu/schemas/id2011850eu/AirQualityReporting.xsd

I can marshall XML from it, and its valid against XSD: http://www.valachnet.cz/lvanek/0/CZ_E2a_hourly.xml

While unmarshall back, I get exception:

com.sun.xml.bind.v2.ClassFactory create0
INFO: No default constructor found on class javax.xml.bind.JAXBElement
java.lang.NoSuchMethodException: javax.xml.bind.JAXBElement.<init>()
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getDeclaredConstructor(Unknown Source)
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:104)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.createInstance(ClassBeanInfoImpl.java:286)

I discovered, that JAXB creates in method 'ClassBeanInfoImpl::createInstance'
jaxbType = javax.xml.bind.JAXBElement - But it's not have default constructor.

I need to know which XML fragment causes my problem, but NoSuchMethodException isn't informative.
It is possible surround calling: bean = ClassFactory.create0(jaxbType); in 'ClassBeanInfoImpl::createInstance' method with try/catch and throw more descriptive exception ?

Bye,
Lumir Vanek



 Comments   
Comment by laune [ 07/Apr/14 ]

The indicated XML schema loads several other xsd files from the net and does not compile, needing customizations. Please provide the customization as you have used it. Also, the top level element of the XML file gml:FeatureCollection is not defined in the schema file. Also, complete code to reproduce the unmarshalling should be provided.

Hoewever, it's very likely that this is a case of incomplete customization and/or JAXB use and should not be discussed in this JIRA, where bubs are reported. Please use the user list for further discussion since JIRA is rather inconvenient for this.

Comment by vanekl [ 08/Apr/14 ]

Hi,
my customization is:

http://www.valachnet.cz/lvanek/0/bindings.xjb

Ant script, that generate Java code is:

http://www.valachnet.cz/lvanek/0/generate_jaxb_code.xml

And unmarshalling code:

import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBElement;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.ValidationEvent;
import javax.xml.bind.ValidationEventHandler;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Validator;

import org.xml.sax.SAXException;

import net.opengis.gml._3.FeatureCollectionType;

public static void main(String[] args)
{
try
{
System.out.println("Creating JAXB Context");
final JAXBContext jaxbContext = JAXBContext.newInstance(FeatureCollectionType.class);

/*

  • Input XML
    */
    String fileName = ".\\output
    CZ_E2a_hourly.xml";

/*

  • Loading XSD
    */
    System.out.println("Loading XSD");
    SchemaFactory schemaFactory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
    // Schema schema = schemaFactory.newSchema(new File("..\\AirQualityReportingModel\\XSD
    AirQualityReporting_0.3.7c.xsd"));
    Schema schema = schemaFactory.newSchema(new URL("http://dd.eionet.europa.eu/schemas/id2011850eu/AirQualityReporting.xsd"));

/*

  • Validation
    */
    System.out.println("Validating " + fileName + "...");

try

{ Validator validator = schema.newValidator(); validator.validate(new StreamSource(new File(fileName))); System.out.println("OK"); }

catch (Exception e)

{ e.printStackTrace(); return; }

/*

  • Unmarsalling
    */
    final Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
    unmarshaller.setSchema(schema);

unmarshaller.setEventHandler(new ValidationEventHandler()
{
@Override
public boolean handleEvent(ValidationEvent event)
{
System.out.println(event.getMessage());
return true;
}}
);

JAXBElement<FeatureCollectionType> featureCollection = unmarshaller.unmarshal(new StreamSource(fileName), FeatureCollectionType.class);
System.out.println(featureCollection.getName());

final FeatureCollectionType featureCollectionType = featureCollection.getValue();
System.out.println(featureCollectionType.getDescription());
}
catch (JAXBException | SAXException | MalformedURLException e)

{ e.printStackTrace(); }

}

Bye,
Lumir

Comment by laune [ 08/Apr/14 ]

Works for me, using data as posted and xjc and java from /extra/JDK7u21/jdk1.7.0_21/. Some other effect has caused validation warnings which I haven't investigated. (I'll not continue this thread via JIRA.)

Comment by vanekl [ 08/Apr/14 ]

Hi,
after some hours of debugging I found cause of problem:

Class (generated by jxc): net.opengis.om._2.OMObservationType

have declared:

@XmlElement(required = true, type = JAXBElement.class)
protected Object result;

After removing "type = JAXBElement.class" Unmashalling works fine.

I am still belived, that throwing more descriptive exceptions (ideally containing tag name)
in this case would be welcomed by JAXB users.

class UnmarshallingContext::createInstance( JaxBeanInfo beanInfo ) may be good place to cath
NoSuchMethodException and send it to Loader.reportError().

You can close this issue, thanks for help.

Best Regards,
Lumir Vanek





[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-1010] allow generate episode to use if-exists attribute Created: 22/May/12  Updated: 03/Apr/14

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

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


 Description   

We forked the jaxb maven plugin a while back and I'm trying to replace it with the latest "open-source, off-the-shelf" version. The earlier maven plugin didn't generate episode files correctly (or at all?) so we wrote our own plugin to generate episodes. One nice attribute in episode files if the "if-exists" attribute as shown below:

<bindings if-exists="true" scd="~tns:Foo">
<class ref="com.acme.common.Foo"/>
</bindings>

This eliminates the need to re-import every schema when compiler later schemas with this episode file.



 Comments   
Comment by lexi [ 19/Jan/13 ]

I'm not quite sure, how is this related to the maven plugin for JAXB.

Comment by emystein [ 27/Mar/13 ]

tdrury could share your fork that generates episodes with if-exists attribute on bindings?
Thanks in advance,

Comment by tdrury [ 28/Mar/13 ]

I didn't fork the plugin. Instead, I wrote my own maven plugin that generates episode files from the package-info.java file that xjc creates.

Comment by lexi [ 03/Apr/14 ]

Hi Iaroslav,

here's an idea for bindings customization. Was filed in my maven-jaxb2-plugin project, but is clearly not in scope there.

Best wishes,
/Alexey





[JAXB-1009] JAXB spec should be updated to support new JDK8 Date/Time apis Created: 01/Apr/14  Updated: 01/Apr/14

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: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JAXB-1008] Misleading xjc Error Message Created: 27/Mar/14  Updated: 27/Mar/14

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

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


 Description   

Using xjc against a schema file that specifies an invalid version for the xmlns jaxb version results in the following error message:
[ERROR] JAXB version attribute must be "1.0"

However, other versions are applicable such as 2.0 and 2.1

Example:

Schema with the following root element declarations:
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
jaxb:version="2.2"






[JAXB-1007] NPE from marshalling an IDREF that point to a missing ID attribute value Created: 20/Mar/14  Updated: 20/Mar/14

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

Type: Bug Priority: Minor
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   

NPE is thrown prematurely in case of an id attribute being null instead of a more appropriate validation event (Object "..." is found in an IDREF property but this object doesnt have an ID.). In order to fix this see AttributeProperty.serializeAttributes method that deals with the null correctly.

It seems that other people have had to deal this problem before (http://stackoverflow.com/questions/10705532/in-jaxb-marshalling-how-to-identify-which-child-element-caused-jaxb-marshallin). I guess that pinpointing of the cause can be quite problematic with the current behavior.

  • * StackTrace * *
    AttributeProperty<BeanT>.getIdValue(BeanT) line: 128
    ClassBeanInfoImpl<BeanT>.getId(BeanT, XMLSerializer) line: 322
    TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>.print(BeanT) line: 290
    TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>(DefaultTransducedAccessor<T>).writeLeafElement(XMLSerializer, Name, T, String) line: 69
    SingleElementLeafProperty<BeanT>.serializeBody(BeanT, XMLSerializer, Object) line: 130
    ClassBeanInfoImpl<BeanT>.serializeBody(BeanT, XMLSerializer) line: 361
    XMLSerializer.childAsXsiType(Object, String, JaxBeanInfo, boolean) line: 696





[JAXB-1006] Add @XmlSchemaType(name = "dateTime|date|time|...") annotation Created: 14/Mar/14  Updated: 14/Mar/14

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

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


 Description   

XJC does not add @XmlSchemaType(name = "dateTime|date|time|...") annotation on a XMLGregorianCalendar. The result of this is that if JAX-WS uses these classes, the auto-generated schema has xs:anySimpleType instead of the correct type.






[JAXB-1005] Generation of classes with jaxb fails when an element is named "PRN" Created: 11/Mar/14  Updated: 11/Mar/14

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

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

Eclipse Helios, Windows 7



 Description   

I am generating classes from a large xsd file. (Rightclick on pom in projectexplorer, run-as "maven generate sources") When I name an Element with "PRN" the generation process get stuck. It do not break and get also not to finished.
When I rename the Element to PRN2 the same code works.
Environment Helios, java 7, maven, maven-jaxb2 plugin 0.8.0 with basics and annotate 0.6.2. Jaxb version 2.2.7 (also tried 2.2.8 and 2.2.0 ...)
Cant explain such a strange behavior, where the name of an element makes the generation to be stuck.

Extraction from pom.xml
<build>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.0</version>
<configuration>
<schemaDirectory>src/main/resources</schemaDirectory>
<bindingDirectory>src/main/resources</bindingDirectory>
<generatePackage>migration.xml</generatePackage>
<strict>true</strict>
<extension>true</extension>
<forceRegenerate>true</forceRegenerate>
<generateDirectory>src/main/java</generateDirectory>
<!-- <readOnly>true</readOnly> -->
<verbose>true</verbose>

<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.6.2</version>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics-annotate</artifactId>
<version>0.6.2</version>
</plugin>
</plugins>
<args>
<arg>-Xannotate</arg>
<!-- <arg>-XtoString</arg> -->
</args>
</configuration>
<executions>
<execution>
<id>generate-sources</id>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>

<!-- plugin to add the jars to the generated jar. -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>src/assemble/exe.xml</descriptor>
</descriptors>
<archive>
<manifestFile>src/main/java/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
</plugins>
</build>

The XSD fragment which do not work.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="PRN">
<xs:annotation>
<xs:documentation xml:lang="en">
ProductRelation
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="A" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">
ProductIdRef
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:IDREF">
<xs:minLength value="4"/>
<xs:maxLength value="14"/>
<xs:pattern value="(PDT|PDT-)([0-9])+"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="B" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">
AmountValue
</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:long">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="2147483647"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>






[JAXB-1004] Specific enum member ignored and Enum class not generated Created: 06/Mar/14  Updated: 21/Mar/14  Resolved: 21/Mar/14

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

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


 Description   

Consider this XML snippet:

<xs:simpleType name="uom">
		<xs:restriction base="xs:string">
			<xs:enumeration value="kg" />
			<xs:enumeration value="m/s" />
			<xs:enumeration value="m³" />
			<xs:enumeration value="L" />
		</xs:restriction>
	</xs:simpleType>

XJC simple does not generate the Enum Uom. If you change to m3 it works.



 Comments   
Comment by Iaroslav Savytskyi [ 11/Mar/14 ]

Hi, Michael,

I've tried this on trunk, on jaxb 2.2.7 and besides it takes quite long I always have positive result:

Uom.java
XmlType(name = "uom", namespace = "")
@XmlEnum
public enum Uom { 
...
 @XmlEnumValue("m\u00b3")
 M("m\u00b3"),
...
}
Comment by Michael Osipov [ 21/Mar/14 ]

Thanks for the feedback. I tried several variations of it with XJC directly and through the Maven plugin and was not able to reproduce it anymore. Feel free to close as NOTABUG.





[JAXB-1003]  Invalid pom: jaxb-xjc 2.1.16 has a wrong dependency to jaxb-core 2.1.16 Created: 06/Mar/14  Updated: 15/Jul/14

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

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

Tags: dependency, jaxb-xjc, pom

 Description   

The pom states a dependency to jaxb-core 2.1.6 which does not exist for the 2.1.x versions.

This bug for 2.1.16 was already reported in a comment of JAXB-984, and one stated to fix it, but the bug is closed now (without a fix).
So nobody is currently able to use 2.1.17, unless they use a fixed private pom.

Please fix all the versions stated in JAXB-984, too.



 Comments   
Comment by roos [ 06/Mar/14 ]

Typos in the comment. 2.1.6 > 2.1.16, 2.1.17 > 2.1.16. Unable to edit the text, sorry.

Comment by Iaroslav Savytskyi [ 07/Mar/14 ]

Hi,

I have pushed jaxb-core 2.1.14. Can you use it as workaround?

Comment by lexi [ 15/Jul/14 ]

Workaround:

		<dependency>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-impl</artifactId>
			<version>${jaxb21.version}</version>
			<exclusions>
				<exclusion>
					<groupId>com.sun.xml.bind</groupId>
					<artifactId>jaxb-core</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>com.sun.xml.bind</groupId>
			<artifactId>jaxb-xjc</artifactId>
			<version>${jaxb21.version}</version>
			<exclusions>
				<exclusion>
					<groupId>com.sun.xml.bind</groupId>
					<artifactId>jaxb-core</artifactId>
				</exclusion>
			</exclusions>
		</dependency>




[JAXB-1002] "com.mypackage.A" is substituting "com.mypackage.BaseType", but "com.mypackage.A" is bound to an anonymous type. Created: 28/Jan/14  Updated: 28/Jan/14

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

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

Windows



 Description   

I am facing an issue while marshalling a JAXB model tree to a xml file using JAXB.

Its classes has been created by the JDK's xjc.
The xml schema files seem to be valid according xjc (and other xml tools).
The creation of the class files completed without any errors.

However, I am unable to marshall them, the exception which I get is:

com.sun.istack.internal.SAXException2: "com.mypackage.A" is substituting "com.mypackage.BaseType", but "com.mypackage.A" is bound to an anonymous type.
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:237)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:652)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementNodeProperty.serializeItem(ArrayElementNodeProperty.java:54)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementProperty.serializeListBody(ArrayElementProperty.java:157)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:335)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:335)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:146)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:116)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:318)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:325)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:61)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayReferenceNodeProperty.serializeListBody(ArrayReferenceNodeProperty.java:103)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:143)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementNodeProperty.serializeItem(ArrayElementNodeProperty.java:54)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayElementProperty.serializeListBody(ArrayElementProperty.java:157)
at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:343)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:685)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:141)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:116)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:318)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:325)
at com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:61)
at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:483)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:308)
at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:236)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
(...)

I am asking whether

  • if this is a jaxb bug
  • I am doing something wrong
  • if the schema files are somewhat errornous which xjc does not detect

Important:
I cannot modify the XSD files - they are defined by federal authorities and according to several xml/xsd tools they seem to be correct.






[JAXB-1001] Cannot pass language for generated Javadoc Created: 28/Jan/14  Updated: 03/Oct/14

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: 6
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.





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





[JAXB-999] Not well-formed XML output by Marshaller in conjunction with @XmlAnyAttribute Created: 26/Jan/14  Updated: 04/Feb/14

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

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

Max OS X, JDK 1.7.0_51


Tags: marshaller, well-formed, xmlanyattribute

 Description   

Summary

I encountered a situation where a javax.xml.bind.Marshaller produces not well-formed XML, despite throwing no exception nor raising a validation event. The problem arises when using @XmlAnyAttribute-Annotation in a special way.

Details

Consider the following scenario (imports omitted):

Test.java
@XmlAccessorType(XmlAccessType.NONE)
@XmlRootElement
public class Test {
	
	@XmlAttribute
	public String id;
	
	@XmlAnyAttribute
	public Map<QName,String> other;

}
test.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
    <xs:element name="test">
    	<xs:complexType>
    		<xs:anyAttribute processContents="skip"/>
    	</xs:complexType>
    </xs:element>
</xs:schema>
Main.java
public class Main {

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

		Test t = new Test();
		t.id = "5";
		t.other = new HashMap<QName, String>();
		t.other.put(new QName("id"), "10");

		JAXBContext jc = JAXBContext.newInstance(Test.class);
		Marshaller m = jc.createMarshaller();
		SchemaFactory sf = SchemaFactory
				.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
		Schema schema = sf.newSchema(new File("test.xsd"));
		m.setSchema(schema);
		m.setProperty(Marshaller.JAXB_NO_NAMESPACE_SCHEMA_LOCATION, "test.xsd");
		m.setEventHandler(new ValidationEventHandler() {

			@Override
			public boolean handleEvent(ValidationEvent event) {
				System.out.println("Validaten event received.");
				return false;
			}
		});
		m.marshal(t, new File("test.xml"));

	}

}

The invocation of Main.main does the following:

  • No exception is raised.
  • The handleEvent-method is not called.
  • A file "test.xml" is written, in which the element "test" carries the attribute "id" twice. Once with value "5", and once with value "10". Hence, it is not well-formed XML.

Since the operation silently succeeds, a user expects a valid XML with respect to the XML schema. As far as I know, validity w.r.t. schema implies that it is also well-formed. Assuming no schema is used, a user would expect that the output is well-formed if no error or warning is given.

The ugly workaround is to add an additional check on top of the Marshal validation for well-formedness, as long as this shortcoming exists.

Side-notes

I am aware of the fact that this usage of the XmlAnyAttribute-map can be considered as an edge case. Nevertheless, the Marshaller should check for validity of the input. At the moment, the silent-fail-outcome is highly undesirable.

Proposals

Proposals in which direction a fix could go:

  1. A Marshaller raises an exception if the output would not be well-formed XML. The postcondition, that the output is always well-formed, should be included in the javadocs.
    1. In the special case where a regularly mapped attribute is again specified in the XmlAnyAttribute-map, this error is explained in the exception.
  2. If proposal 1 can not be implemented: When using a XML schema on a Marshaller, the validation succeeds only if the XML is also well-formed.

Thanks for looking into this!



 Comments   
Comment by m4t [ 04/Feb/14 ]

A situation where also not well-formed XML is produced, but doesn't build on attribute collision, is the following:

If you store an attribute with empty name into the QName-map. Replace

new QName("id")

with

new QName("")

in the above example. No exception is raised, the produced string is not XML (attribute with empty name). I guess also invalid characters for XML would not be intercepted.





[JAXB-998] running with option -fullversion fails Created: 22/Jan/14  Updated: 22/Jan/14

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

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

Mac Mavericks


Tags: cli, command, command-line

 Description   

jenss-mbp:bin jkv$ ./xjc.sh -fullversion
Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number: build.number
at java.text.MessageFormat.makeFormat(MessageFormat.java:1420)
at java.text.MessageFormat.applyPattern(MessageFormat.java:479)
at java.text.MessageFormat.<init>(MessageFormat.java:363)
at java.text.MessageFormat.format(MessageFormat.java:835)
at com.sun.tools.xjc.Messages.format(Messages.java:54)
at com.sun.tools.xjc.Driver.run(Driver.java:232)
at com.sun.tools.xjc.Driver.run(Driver.java:200)
at com.sun.tools.xjc.Driver._main(Driver.java:123)
at com.sun.tools.xjc.Driver.access$000(Driver.java:80)
at com.sun.tools.xjc.Driver$1.run(Driver.java:103)
Caused by: java.lang.NumberFormatException: For input string: "build.number"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at java.text.MessageFormat.makeFormat(MessageFormat.java:1418)
... 9 more






[JAXB-997] Provide a fluent interface on set methods Created: 09/Jan/14  Updated: 09/Jan/14  Resolved: 09/Jan/14

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

Type: Improvement Priority: Major
Reporter: martinspamer Assignee: Iaroslav Savytskyi
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: codemodel, fluent-interface, improvement

 Description   

Currently the code generated for setting the property of an Element is

/**

  • Sets the value of the name property.
  • @param value
  • allowed object is
  • {@link String }
  • */
    public void setName(String value)

    { this.name = value; }

If instead the following code was generated

public XmlElementName setName(String value)

{ this.name = value; return this; }

This would go a long way to providing a fluent interface for setting up the Object Model and lead to much more elegant production code for developers using jaxb.



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

I'm not sure it's possible.

According to specification [1] we have to follow JavaBeans-style.

What you can do is to write a JAXB plugin [2]. Which will make what you want.

1: https://jcp.org/aboutJava/communityprocess/mrel/jsr222/index2.html
2: https://jaxb.java.net/plugin.html





[JAXB-996] Slow performance of Unmarshaller when reading xsd:any element Created: 24/Dec/13  Updated: 14/Jul/14

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

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

Windows 7, standard JDK 1.7.0_04



 Description   

I had already reported this issue to Oracle, but I don't think it got attention (and maybe I was reporting it to the wrong people anyway). On the users@jaxb.java.net mailing list Iaroslav guided me here. So below is a copy/paste of my bug report. In short: unmarshalling xml files with a lot of 'any' elements takes an unacceptable long time in JDK 1.7u4.

Date Created: Thu Mar 28 08:28:09 MST 2013
Type: bug
Customer Name: Pieter Buzing
Customer Email: Buzing@...
SDN ID:
status: Waiting
Category: jaxb-xsd
Subcategory: runtime
Company: Riscure BV
release: 1.0.4
hardware: x64
OSversion: windows_7
priority: 3
Synopsis: Performance degradation between java 7u3 and 7u4 for xml
parsing of "xsd:any"
Description:
FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b22) Java HotSpot(TM)
64-Bit Server VM (build 23.0-b21, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
We observe a performance degradation between java 7u3 and 7u4 with
regard to the xml parsing of an "xsd:any" element with JAXB2. Also
later java updates have the same poor performance.

Given:

  • an xsd schema which contains an "xsd:any" element and which is
    compiled with xjc (version 2.2.4)
  • an xml file that conforms to the above xsd schema and contains (a lot
    of) <xsd:any> elements
  • a java class that unmarshals the above xml file
  • a Windows 7 computer with both jdk 7u3 and a later update installed

When we run the java unmarshal code with jdk1.7.0_04\bin\java.exe (7u4)
we observe that the required time is at least twice the runtime needed
by jdk1.7.0_03\bin\java.exe (7u3).

REGRESSION. Last worked in version 1.0.4

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Prepare an xsd file with an xs:any element (like in the comments in
the java code), compiling it with xjc.
2. Prepare a matching xml file that contains (a lot of) xs:any elements
(see also the comments in the java file).
3. Compile and run java code that unmarshals the xml data (like the
supplied example code).
4. Observe that running the code with jdk7u3 is at least twice as fast
compared to later updates.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected behavior would be an equal runtime for both java 7u3 and
7u4.
ACTUAL -
We observed a performance difference between different java runtime
environments:

java version = 1.7.0_03
.file size = 1613 bytes, read took 36 ms

java version = 1.7.0_04
.file size = 1613 bytes, read took 75 ms

When we increase the size of the xml file (or read multiple xml files)
the relative performance difference grows. Also for later updates like
7u17 we see the same performance degradation compared to 7u3.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import anyexample.Root;
import anyexample.Root.Anyproperties;

/**
This code demonstrates a performance bug in java 7u4. Steps to
replicate this bug:

1. Save and compile this xsd schema:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name='Root'>
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="unbounded"
name="anyproperties">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

The code assumes that the resulting class files are stored in a
directory called anyexample.

2. Store the following xml file as 'anyprops.xml':
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Root>
<anyproperties>
<Prop1>0</Prop1>
<Prop2>Inverse</Prop2>
<Prop3>bits</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>1</Prop1>
<Prop2>out</Prop2>
<Prop3>bits</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>3</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>4</Prop1>
<Prop2>bla</Prop2>
<Prop3>bar</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>5</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>6</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo1</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>7</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo2</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>8</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo3</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>9</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo4</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
<anyproperties>
<Prop1>10</Prop1>
<Prop2>bla</Prop2>
<Prop3>foo5</Prop3>
<Prop4>a</Prop4>
<Prop5>b</Prop5>
<Prop6>c</Prop6>
</anyproperties>
</Root>

3. Run the code below with both jdk7u3 and jdk7u4 (or later) and
observe a significant performance difference.
*/
public class AnyPropertiesTest {

private JAXBContext anyContext;
private Unmarshaller anyUnmarshaller;

public static final String PATH = "anyprops.xml";

public AnyPropertiesTest() {
System.out.println("java version = " +
System.getProperty("java.version"));
try {
if (anyContext == null)

{ anyContext = JAXBContext.newInstance(Root.class); anyUnmarshaller = anyContext.createUnmarshaller(); }

} catch (JAXBException e)

{ e.printStackTrace(); }

}

public void testAny()

{ long startTime = System.nanoTime(); File inputFile = new File(PATH); List<Anyproperties> propertiesList = getProperties(inputFile); long duration = (System.nanoTime() - startTime) / 1_000_000; String s = String.format("read %d properties in %d ms", propertiesList.size(), duration); System.out.println(s); }

private List<Anyproperties> getProperties(File path) {
List<Anyproperties> properties;

try

{ System.out.printf("file size = %d bytes, ", path.length()); properties = read(new FileInputStream(path)); }

catch (JAXBException e)

{ System.out.println(String.format( "File '%s' could not be read by JAXB: might not be a valid XML file", path.getAbsolutePath())); properties = null; }

catch (FileNotFoundException e)

{ // Impossible as path was obtained from listFiles String errorMessage = String.format("File '%s' obtained by File.listFiles() does not exist", path.getAbsolutePath()); throw new RuntimeException(errorMessage, e); }

return properties;
}

private synchronized List<Anyproperties> read(InputStream stream)
throws JAXBException

{ List<Anyproperties> templates = null; long startTime = System.nanoTime(); //It is the unmarshall method that takes a considerable amount of time on java 7u4, compared to 7u3 Root root = (Root) anyUnmarshaller.unmarshal(stream); long duration = (System.nanoTime() - startTime)/1_000_000; System.out.printf("read took %d ms\n", duration); templates = (List<Anyproperties>) root.getAnyproperties(); return templates; }

public static void main(String[] argv)

{ AnyPropertiesTest test = new AnyPropertiesTest(); test.testAny(); }

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
In order to deal with this issue we ship our product with java 7u3.
Upgrading to update 4 or later has a considerable performance impact
(we use large xml files).
The obvious solution is to avoid <xsd:any> elements, but this is not
always feasible.



 Comments   
Comment by ilyaz [ 01/May/14 ]

This issue has not yet been addressed but is still very important to us (I'm from the same company as the reporter of this issue).
It is now blocking our migration from Java7 to Java8, because in a critical feature of our product some of the options shown to our users in the user interface are defined in XML. JDK 7u4+ makes the reading (and therefore the perceived rendering) too slow for our users.

Furthermore, there are some bug fixes in JDK 7u4+ (such as the file explorer crashing in Windows when users sort an open file dialog by date) that we cannot provide to our users because of this issue.

Is any work on this issue expected?

Comment by elena-lorena [ 14/Jul/14 ]

Could you please update us if there is any planning to fix this issue in the coming release(s)?
We have started to migrate our projects to Java 8 and this issue is still blocking for us... (I'm from the same company as pcb and Ilyaz)
Your feedback would be much appreciated.
Thank you!





[JAXB-995] Regression: Maven Plugin does not work with JDK 8 Created: 17/Dec/13  Updated: 03/Oct/14  Resolved: 03/Oct/14

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

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

v2.2.8-b130911.1802
Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b62
Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b120
System: Windows 7 version 6.1 running on amd64; Cp1252; de_CH (nb)



 Description   

Running with JDK 8 EA b120, the maven plugin stops without any error message at:
"Parsing input schema(s)..."

No files get generated -> Blocker



 Comments   
Comment by puce [ 17/Dec/13 ]

Wrong component and I can't edit it.

I created a new issue: https://java.net/jira/browse/MAVEN_JAXB2_PLUGIN-83

Comment by lexi [ 03/Oct/14 ]

Does this still persist? If it does, please provide a sample project.

Comment by puce [ 03/Oct/14 ]

No, as far as I remember, it works fine with the latest Java SE 8 release and version 0.9.0 of the plugin.

I think this issue can be closed.





[JAXB-994] Support for XML Schema 1.1 Created: 16/Dec/13  Updated: 16/Dec/13

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: 5
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.






[JAXB-993] Proporder doesn't recogonize property if it is inherited Created: 10/Dec/13  Updated: 10/Dec/13

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

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

Ubuntu, jdk1.6.0_45



 Description   

Whenever I inherit a property from a base-class, propOrder doesn't recognize it, and throws an exception:

Exception in thread "main" com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
Property traceId appears in @XmlType.propOrder, but no such property exists.
at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:106)
...

Example to reproduce:
----------------------PropOrderDemo.java---------------------------------
public class PropOrderDemo
{
public static void main(String[] args) throws Exception

{ javax.xml.bind.JAXBContext jaxbContext = javax.xml.bind.JAXBContext.newInstance(FaultObject.class); javax.xml.bind.Marshaller marshaller = jaxbContext.createMarshaller(); FaultObject exception = new FaultObject(13); marshaller.marshal(exception, System.out); }

}

----------------------FaultObject.java---------------------------------

@javax.xml.bind.annotation.XmlType(propOrder =

{ "traceId" }

)
@javax.xml.bind.annotation.XmlRootElement
@javax.xml.bind.annotation.XmlAccessorType(javax.xml.bind.annotation.XmlAccessType.PROPERTY)
public class FaultObject extends AbstractTraceableObject
{
private int traceId;

public FaultObject()
{
}

public FaultObject(int traceId)

{ this.traceId = traceId; }

@Override public int getTraceId()
{ return this.traceId; }

@Override public void setTraceId(int traceId)
{ this.traceId = traceId; }

}

--------------------------AbstractTraceableObject.java--------------------------------------
public class AbstractTraceableObject
{
public int getTraceId()

{ return 0; }

public void setTraceId(int traceId)
{
}
}






[JAXB-992] Property "Value" is already defined in /com/sun/xml/xsom/impl/parser/datatypes.xsd[14,33] Created: 29/Nov/13  Updated: 26/Feb/14

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

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

Windows 7 + Java 1.7.45 + Maven 3.11 + Eclipse Kepler



 Description   

Attempting to compile a schema exposes duplicate propertty in datatypes.xsd

[ERROR] jar:file:/C:/Users/MSpamer/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.1.13/jaxb-xjc-2.1.13.jar!/com/sun/xml/xsom/impl/parser/datatypes.xsd[14,33]
com.sun.istack.SAXParseException2; systemId: jar:file:/C:/Users/MSpamer/.m2/repository/com/sun/xml/bind/jaxb-xjc/2.1.13/jaxb-xjc-2.1.13.jar!/com/sun/xml/xsom/impl/parser/datatypes.xsd; lineNumber: 14; columnNumber: 33; Property "Value" is already defined. Use <jaxb:property> to resolve this conflict.
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at com.sun.tools.xjc.reader.ModelChecker.checkPropertyCollision(ModelChecker.java:108)
at com.sun.tools.xjc.reader.ModelChecker.check(ModelChecker.java:94)
at com.sun.tools.xjc.reader.ModelChecker.check(ModelChecker.java:67)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:189)
at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:116)
at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:415)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:167)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:113)
at com.sun.tools.xjc.Driver.run(Driver.java:313)
at org.codehaus.mojo.jaxb2.AbstractXjcMojo.execute(AbstractXjcMojo.java:327)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
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:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
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)
at org.codehaus.classworlds.Launcher.main(Launcher.java:46)



 Comments   
Comment by Iaroslav Savytskyi [ 02/Dec/13 ]

Hi,

Please provide more info:

1) What exactly are you trying to do?
2) Why are you using JAXB 2.1.x?

Thanks.

Comment by martinspamer [ 09/Jan/14 ]

I'm writing an automation test suite for a system that has a unrigourously defined schema from a third party over which I have no control.

I was using http://mojo.codehaus.org/jaxb2-maven-plugin/ because I wanted to utilise its feature for creating test classes for the element object model. That plugin uses 2.1.13.

Comment by Iaroslav Savytskyi [ 09/Jan/14 ]

Can you please send me testcase to iaroslav.savytskyi at oracle.com so I will attach it here.

Thanks.

Hopefully we will update maven plugin for JAXB-RI soon.

Comment by anupamb82 [ 26/Feb/14 ]

I also faced the same issue when I tried to generate the class out of this xsd file.

ftp://ftp.ncbi.nlm.nih.gov/pubchem/data_spec/pubchem.xsd

I hope this will help to resolve the problem.

Regards
Anupam





[JAXB-991] Handle loading errors of XJC plugins gracefully to ignore dependencies from unnecessary plugins Created: 29/Nov/13  Updated: 29/Nov/13

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

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


 Description   

When loading additional XJC plugins with the service discovery mechanism, java.util.ServiceLoader throws a ServiceConfigurationError (introduced in Java 6) if a plugin class cannot be loaded or instantiated. I suggest to output a warning in this case and continue the discovery process with further plugins.

Also consider the remark from the ServerceLoader's iterator() Javadoc description:

To write robust code it is only necessary to catch ServiceConfigurationError when using a service iterator.

In my case I wanted to use the ToString plugin from JAXB2 Basics, which is bundled with other plugins. Of these namely the Inheritance plugin requires the JavParser library as dependency. Currently I have to include the library in my classpath (though I don't use it) just to avoid the following Error:

java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider 
org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin could not be instantiated: 
java.lang.NoClassDefFoundError: japa/parser/ParseException
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:116)
	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.eclipse.ant.internal.launching.remote.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at org.eclipse.ant.internal.launching.remote.InternalAntRunner.run(InternalAntRunner.java:423)
	at org.eclipse.ant.internal.launching.remote.InternalAntRunner.main(InternalAntRunner.java:137)
Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider 
org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin could not be instantiated: 
java.lang.NoClassDefFoundError: japa/parser/ParseException
	at java.util.ServiceLoader.fail(ServiceLoader.java:207)
	at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
	at com.sun.tools.xjc.Options.findServices(Options.java:957)
	at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
	at com.sun.tools.xjc.Options.parseArgument(Options.java:688)
	at com.sun.tools.xjc.Options.parseArguments(Options.java:809)
	at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474)
	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:39)
	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)
	... 10 more
Caused by: java.lang.NoClassDefFoundError: japa/parser/ParseException
	at org.jvnet.jaxb2_commons.plugin.inheritance.InheritancePlugin.<init>(InheritancePlugin.java:219)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at java.lang.Class.newInstance0(Class.java:355)
	at java.lang.Class.newInstance(Class.java:308)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
	... 25 more
Caused by: java.lang.ClassNotFoundException: japa.parser.ParseException
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 33 more





[JAXB-990] xjc -fullversion does not work Created: 27/Nov/13  Updated: 28/Nov/13  Resolved: 28/Nov/13

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

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

Windows, German locale



 Comments   
Comment by hdelfs [ 27/Nov/13 ]

Sorry, but the originally entered description got lost:

The command line option "-fullversion" for the XJC does not work but displays an exception. This is caused by the ${build.number} property used in the resource bundle definitions for Driver.FullVersion in (probably) all locales.

C:\Java\jaxb-ri-2.2.7\bin>xjc -fullversion
classLoader = java.net.URLClassLoader@118f375
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@f84386
Exception in thread "main" java.lang.IllegalArgumentException: can't parse argument number build.number
        at java.text.MessageFormat.makeFormat(MessageFormat.java:1339)
        at java.text.MessageFormat.applyPattern(MessageFormat.java:458)
        at java.text.MessageFormat.<init>(MessageFormat.java:350)
        at java.text.MessageFormat.format(MessageFormat.java:811)
        at com.sun.tools.xjc.Messages.format(Messages.java:54)
        at com.sun.tools.xjc.Driver.run(Driver.java:232)
        at com.sun.tools.xjc.Driver.run(Driver.java:200)
        at com.sun.tools.xjc.Driver._main(Driver.java:123)
        at com.sun.tools.xjc.Driver.access$000(Driver.java:80)
        at com.sun.tools.xjc.Driver$1.run(Driver.java:103)

Also -version and -fullversion don't work with the xjc Ant task, which would be a nice enhancement.

Comment by Iaroslav Savytskyi [ 28/Nov/13 ]

Thank you for reporting.
I've checked in jaxb 2.2.8 - it's fixed.

Comment by Iaroslav Savytskyi [ 28/Nov/13 ]

Fixed

Comment by Iaroslav Savytskyi [ 28/Nov/13 ]

We have migrated JAXB project to maven. So ant tasks are not as prioritized as before.





[JAXB-989] Java's JAXB implementation does not handle underscores properly Created: 26/Nov/13  Updated: 26/Nov/13

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

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

Tags: java, jaxb, jaxb-xjc, jersey

 Description   

The usecase to recreate the issue is to try and translate the following schema to java:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Foo_Bar">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="choices" type="TypeMyEnum" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="TypeMyEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="ALPHA_1_0_0"/>
<xs:enumeration value="BETA_2_0_0"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

By default, xjc will create a file called FooBar.java and a file called TypeMyEnum.java. Notice how xjc "ate" the underscore in Foo_Bar. Also, by default, the internals of TypeMyEnum look like this:

ALPHA_1_0_0,
BETA_2_0_0;

To get the underscore back in Foo_Bar, one has to use a bindings file as follows:

<jxb:bindings version="1.0"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb">
<jxb:globalBindings underscoreBinding="asCharInWord"/>
</jxb:bindings>

Now, the code generates a Foo_Bar.java file as desired but horribly changes the internals of TypeMyEnum to look like:

@XmlEnumValue("ALPHA_1_0_0")
ALPHA__1_0__0("ALPHA_1_0_0"),

@XmlEnumValue("BETA_2_0_0")
BETA__2_0__0("BETA_2_0_0");
private final String value;

It seems every underscore in an enum value is changed to three underscores. This is the issue. This is easily reproducible and beyond me why xjc would do this.

There is no known way to get xjc to retain the underscore in the class name (i.e Foo_Bar.java) AND generate a sane enum file.






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

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: 0
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.






[JAXB-987] nillable elements with required attributes Created: 24/Oct/13  Updated: 24/Oct/13

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

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


 Description   

Unfortunately I need to bring this issue up again since I'm again bitten by this bug (See JAXB-822, which I strongly suggest to re-open, but I'm not allowed to do so).

A nillable element with element content and required attributes cannot be processed using JAXB, since XJC doesn't create an JAXBElement wrapper.

It's occuring for example in the official German federal standard XJustiz set of XML schemas which we are obliged to use.

If this bug cannot be fixed, would you please care to explain a bit longer than the short comment by M. Grebac in JAXB-822 on 2011-Nov-22? As I wrote in the follow-up comment (which a developer might not have read as the issue was already closed then), that "solution" is not very helpful if one is forced to support a given schema.

Right now, our solution is to generate the code once every time there is an update on the schema and then, by hand, look for all instances where an JAXBElement wrapper is needed, modifying the generated code. This is a very frustrating task.

Please see also https://issues.apache.org/jira/browse/CXF-3732






[JAXB-986] Using marshaller on xjc generated classes causes Exception. Works in jdk7, not in jdk 8. Created: 24/Oct/13  Updated: 09/Jan/15

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: 8
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.





[JAXB-985] Different marshallization behaviour with OutputStream and Writer Created: 18/Oct/13  Updated: 21/Oct/13

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

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


 Description   

We discovered a difference in the behaviour of the marshaller when using a Writer and when using an OutputStream.

In our case, we needed to marshall (formatted):

<foo>text<bar />text<bar>baz</bar></foo>

This worked when using an OutputStream, but new lines were inserted when using a Writer.

On investigation, I noticed that in com.sun.xml.bind.v2.runtime.MarshallerImpl has two distinct methods called createWriter(..) - one taking a Writer, and one taking an OutputStream.
The version taking an OutputStream is doing something special in case the encoding is UTF-8 (Why??). The difference is in the usage of IndentingUTF8XmlOutput, which correctly implements the desired functionality - whenever there's text content before the element, no new line+indentation is appended.

However, OutputStream+UTF-8 is the only case *UTF8XmlOutput classes are used, otherwise they aren't. The indentation behaviour might be just one example of behaviour difference, so I would suggest to make the behaviour consistent (i.e. - work for both OutputStream and Writer implementations, and preferably for all encodings)

And while at it, in that class there is one check if (encoding.equals("UTF-8"))

{..} and one if (encoding.startsWith("UTF")) {..}

. This is pretty bad, as it doesn't work with lower-case utf-8 or without a dash, and also would yield different results for these combinations - for UTF8 one if-clause will work, the other won't. If different behaviour based on encoding is really needed (I would say it shouldn't be), then please use normalization/canonicalization of the string - via Charset.forName(..) for example.



 Comments   
Comment by Iaroslav Savytskyi [ 21/Oct/13 ]

I know about the difference. But why 'new lines' is the case?

Comment by glam [ 21/Oct/13 ]

Well, in our case we needed not to have new lines. The behaviour implemented by IndendtingUTF8XmlOutput, and not implemented elsewhere.

For example, we have a unit-test that fails because of that - we process the document multiple times, sometimes by writers, sometimes by output streams, and the outputs don't match.





[JAXB-984] Invalid pom: jaxb-xjc 2.1.x has a wrong dependency to jaxb-core 2.1.x Created: 15/Oct/13  Updated: 16/Oct/13  Resolved: 16/Oct/13

Status: Closed
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.14, 2.1.15, 2.1.16
Fix Version/s: 2.1.14

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

Tags: jaxb-xjc, maven, pom

 Description   

The jaxb-xjc pom was changed for release 2.1.14 and now refers to jaxb-core, which is only available for JAXB 2.2. I think the correct dependency is jaxb-impl as in the pom of release 2.1.13.



 Comments   
Comment by Dennis Kieselhorst [ 15/Oct/13 ]

Same error is in the jaxb-impl pom.

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

Thanks for reporting.

It was bad copy/paste from trunk.

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

I've released fake jaxb-core 2.1.14 artifact. Which has dependency to jaxb-api 2.1.

Comment by Dennis Kieselhorst [ 16/Oct/13 ]

What about 2.1.15 and 2.1.16?

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

I think we will fix this in 2.17. Or if it will be critical - will do the same fix as for 2.14

Comment by Iaroslav Savytskyi [ 16/Oct/13 ]

I meant 2.1.17 and 2.1.14 respectively.





[JAXB-983] JAXB does not support meta class annotations Created: 14/Oct/13  Updated: 01/Apr/14

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

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

Tags: jaxb

 Description   

JAXB reads annotations directly from scanned classes by calling directly java.lang.Class.getAnnotation(Class<A>) This means that Java classes must be annotated directly by e.g. @XmlRootElement, @XmlType etc.

JAXB should read also meta annotations of scanned class annotations i.e. let's take the following example:

Bean.java
@XmlRootElement
@XmlType
// ... other annotations
@Retention(RUNTIME)
@Target(TYPE)
public @interface Bean {
}

and then a Java bean:

Input.java
@Bean
public class Input {

  BigInteger amount;
  Account account;
  // remainder omitted
}

In such case if you execute this:

Main.java
Input input = new Input();
input.setAmount(new BigInteger(1000));
// remainder omitted
JAXBContext.newInstance(Input.class).createMarshaller().marshal(input, System.out);

you will get an error:

Exception in thread "main" javax.xml.bind.MarshalException
 - with linked exception:
[com.sun.istack.SAXException2: unable to marshal type "Input" as an element 
because it is missing an @XmlRootElement annotation]

IMHO it's a bug. JAXB should support annotations annotated with javax.xml.bind annotations. I will send you a patch for class annotations but it should be also the case for fields and methods, I think.



 Comments   
Comment by Przemyslaw Bielicki [ 14/Oct/13 ]

patch sent to dev@jaxb.java.net

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

patch available on github: https://github.com/pbielicki/jaxb/commit/4bafc09fc6a2be203329e3e2423bf9143698828b





[JAXB-982] XMLAnyElement wmissing lax=true with xjc simple Created: 11/Oct/13  Updated: 11/Oct/13

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

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

Windows machine, xjc triggered via jaxws-maven-plugin version 2.3


Tags: jaxb-xjc

 Description   

When generating code from a wsdl that contains an xs:any tag with processContents="lax" and the xjc "simple" option (set via "<xjc:simple/>" in the jaxb custom binding XML), the generated code has a @XMLAnyElement tag without the ( lax = true ) property.

If the processContents is set to "skip" or if the "simple" option is not set the tag is generated with the attribute.

As the xsd is not one I master (it is the ws-trust XSD), I cannot permanently change it.






[JAXB-981] Customize default local name for XML element, type and property Created: 10/Oct/13  Updated: 01/Apr/14

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

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

Tags: jaxb

 Description   

The following class:

CalculatorInput.java
@XmlRootElement
public class CalculatorInput {

  BigDecimal leftOperand;
  BigDecimal rightOperand;
  Operation operation;

  // setters and getters omitted for brevity

will be serialized by JAXB to the following XML:

CalculatorInput.xml
<calculatorInput>
<operation>MULTIPLY</operation>
<leftOperand>150</leftOperand>
<rightOperand>7</rightOperand>
</calculatorInput>

It is desirable to change the default element, type and property naming convention by the user e.g. one would like to have one of the following outputs (without touching CalculatorInput.java):

CalculatorInput.xml
<CALCULATOR_INPUT>
<OPERATION>MULTIPLY</OPERATION>
<LEFT_OPERAND>150</LEFT_OPERAND>
<RIGHT_OPERAND>7</RIGHT_OPERAND>
</CALCULATOR_INPUT>

or

CalculatorInput.xml
<CalculatorInput>
<Operation>MULTIPLY</Operation>
<LeftOperand>150</LeftOperand>
<RightOperand>7</RightOperand>
</CalculatorInput>

At this moment JAXB does not allow to customize default behavior to obtain results above.

The same problem applies when you annotate your class as @XmlType.



 Comments   
Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

sent patch with a solution proposal to dev@jaxb.java.net

Comment by Iaroslav Savytskyi [ 10/Oct/13 ]

It's possible to customize mapping names with "name" attribute of annotations.
e.g. @XmlRootElement (name="CALCULATOR_INPUT")
Fields can be annotated as @XmlElement(name="LeftOperand")

Comment by laune [ 10/Oct/13 ]

Do you have a proposal how to define these renaming actions in a way that is reasonably simple to handle at run time? Note that you say "without touching <the Java source file>". Also, note that this must work both ways, i.e., for unmarshalling, too.

A very simple XSLT would achieve such transformations easily - most certainly taking less time to write than what would be required in a Java source file context.

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

Yes I know this but it's not what is needed here.

What if one of my customers needs CALCULATOR_INPUT and another one CalculatorInput as root XML element? Should I maintain two different versions of class CalculatorInput.java with different annotations?

This is not a imaginary requirement - we have it in production.

It's not an acceptable solution.
Please take a look at my patch. I fixed it in an elegant way.

Cheers,
Przemyslaw

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

@Iaune - yes I have the fix

Comment by Przemyslaw Bielicki [ 10/Oct/13 ]

@Iaroslav - could you please reopen this issue. It's perfectly valid.

Thanks

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

patch available on github: https://github.com/pbielicki/jaxb/commit/25a20c8a88bdc7eea83f2ccefffc6347bd6abc34





[JAXB-980] Unable to set a generic factory method for @XmlType - factoryMethod / factoryClass Created: 04/Oct/13  Updated: 01/Apr/14

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

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


 Description   

JAXB implementation does not allow a generic factory method. Let's take a look at this simple example:

CalculatorInput.java
import javax.inject.Inject;
import javax.inject.Named;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlRootElement(name = "CalculatorInput")
@XmlType(factoryMethod = "getBean", factoryClass = BeanFactory.class)
@Named
public class CalculatorInput {
  
  @Inject
  Context someContext;
IocContainerObjectFactory .java
import javax.inject.Named;
import javax.inject.Singleton;

@Named
@Singleton
public class IocContainerObjectFactory {

  // bean factory init omitted 

  public static <T> T getBean(Class<T> clazz) {
    return beanFactory.getBean(clazz);
  }
}

Example provided above is impossible to implement in current JAXB. The problem here is that you either let JAXB invoke no-arg constructor of CalculatorInput class or explicit static factory method inside this class or in specific factory class. Note that you must have one factory method per class which is extremely bulky, not object-oriented, boilerplate, blah blah blah. Basically it's a mistake.
I know better than JXAB how to create my objects - I need JAXB only to fill these beans with parsed XML content.

Another argument is that JAXB in the current state completely ignores existence of Dependency Injection (which is a part of Java EE specification). In case JAXB creates my CalculatorInput, someContext attribute will be ignored (thus null) by DI container as it has absolutely no knowledge on this instance. The only correct way to make the injection work is to obtain the new instance from the DI bean / object factory - see IocContainerObjectFactory. OK, it is possible but only in such form (again, bulky, boilerplate, ugly):

IocContainerObjectFactory .java
import javax.inject.Named;
import javax.inject.Singleton;

@Named
@Singleton
public class IocContainerObjectFactory {

  // bean factory init omitted 

  public static CalculatorInput getCalculatorInput() {
    return beanFactory.getBean(CalculatorInput.class);
  }

  public static CurrencyConverterInput getCurrencyConverterInput() {
    return beanFactory.getBean(CurrencyConverterInput.class);
  }

  // etc.

}

Imagine what happens if you have more than couple of beans...

Note on JSR-222 specification

JavaDoc of javax.xml.bind.annotation.XmlType says:

XmlType.java
/**
 * Name of a no-arg factory method in the class specified in <tt>factoryClass</tt> factoryClass(). 
 * 
 */
String factoryMethod() default "";

But, the JSR-222 specification does not explicitly say that it must be a no-arg factory method.

Please correct me if I'm wrong.



 Comments   
Comment by Przemyslaw Bielicki [ 04/Oct/13 ]

how can I upload a patch file? I fixed this problem and I would like to submit my proposal

Comment by Przemyslaw Bielicki [ 04/Oct/13 ]

I sent my patch to dev@jaxb.java.net

Cheers,
Przemek

Comment by Przemyslaw Bielicki [ 01/Apr/14 ]

Patch available on GitHub: https://github.com/pbielicki/jaxb/commit/c70183967936ed3e3b0be46eb65694e95c4d583c





[JAXB-979] ClassFactory constructor cache could be more efficient Created: 16/Sep/13  Updated: 16/Sep/13

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

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


 Description   

ClassFactory currently uses a ThreadLocal Map<Class,Constructor> in order to cache the default constructor lookups used in unmarshalling.

issues:

  • The Cache is only valid with the current thread, thus each thread (possibly hundreds in an app server) has to populate it's own cache
  • Use of ThreadLocal's within an application server can lead to ClassLoader leaks, as each Thread can retain a reference to a ThreadLocal even though it is unreachable

The common solution to the ThreadLocal issue is to call ClassFactory.clearCache() in a Servlet filter or similar which removes the ThreadLocal map.

I propose (see mailing list for patch) that the cache can be implemented using a non locking copy on write algorithm that would will be the same or very close performance with a much reduced memory overhead (once populated) and better hit ratio.






[JAXB-978] UnmarshallerImpl has an ineffective finalize() method Created: 16/Sep/13  Updated: 24/Oct/13

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

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


 Description   

During upgrading a web service we observed that a the Parallel new garbage collector was unable to achieve the previously seen thoughput when running with JAXB 2.2.5+

On investigation it seems the reason for this is the addition of the `finalize()` method on `UnmarshallerImpl`, this causes the object not to be collected but to be placed to to the finalizer queue. This is problematic for two reasons

  • it increases the contention on the finalizer queue
  • The last unmarshalled object (a large WS response object in our case) is retained until the finalizer invokes the `finalize()` method

In addition, the implementation of the `finalize()` method:

   protected void finalize() throws Throwable {
        try {
            ClassFactory.cleanCache();
        } finally {
            super.finalize();
        }
    }

is broken because the `ClassFactory.cleanCache()` method needs to be called in the same thread as the original use of the `Unmarshaller`, but this won't be true as it will be called the Finalizer thread.

Will be posting a patch to remove the method to the dev mailing list.



 Comments   
Comment by Iaroslav Savytskyi [ 16/Sep/13 ]

Hi,

Thanks for reporting. I'll fix it.

Comment by rshekar [ 23/Oct/13 ]

Hi Iaroslav,

I am seeing a similar issue when using CXF client, 50% of the heap is java.lang.ref.Finalizer objects.

Can you please let me know if the fix planned for a release, and if so any ETA.

Thank you,
Raj.

Comment by Iaroslav Savytskyi [ 24/Oct/13 ]

The problem is that we are not able to determine when we have to clean our cache.

I think we will try to do something with this in 2.2.8... But unfortunately I'm not able to give any estimations when we will start working on this. This year???

Comment by gadavis [ 24/Oct/13 ]

how you clear the cache isn't really important to removing this finalise method. The finalise method does nothing to clear the cache and only messes with the garbage collector.





[JAXB-977] XMLCatalog not used from xjc/xjctask when strict validation is enabled (JAXB-616 not actually fixed) Created: 27/Aug/13  Updated: 27/Aug/13

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

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


 Description   

When using XJC from ANT and providing an XML Catalog and using strict schema validation, the XML Catalog is ignored. This was originally reported in JAXB-616 (and again in JAXB-795) and was supposed to have been fixed in 2.2.5. However, the fix does not solve the problem. Specifically, the fix was made in class:

com.sun.tools.xjc.reader.xmlschema.parser.SchemaConstraintChecker

Notice the commented out line though... which means the EntityResolver isn't actually used:

private static Source[] [More ...] getSchemaSource(InputSource[] schemas, EntityResolver entityResolver) throws SAXException {
SAXSource[] sources = new SAXSource[schemas.length];
for (int i = 0; i < schemas.length; i++)

{ sources[i] = new SAXSource(schemas[i]); // sources[i].getXMLReader().setEntityResolver(entityResolver); }

return sources;
}

I'm not an expert with respect to JAXB, but after examining some other code I modified it as follows, recompiled, and this does resolve the problem (at least for me):

private static Source[] getSchemaSource(InputSource[] schemas, EntityResolver entityResolver) throws SAXException {
SAXSource[] sources = new SAXSource[schemas.length];
for (int i = 0; i < schemas.length; i++) {
sources[i] = new SAXSource(schemas[i]);
if (entityResolver != null)
{
XMLReader reader = sources[i].getXMLReader();
if (reader == null)
{
SAXParserFactory spFactory = SAXParserFactory.newInstance();
spFactory.setNamespaceAware(true);
try

{ reader = spFactory.newSAXParser().getXMLReader(); }

catch (ParserConfigurationException ex)

{ throw new SAXException(ex); }

}
reader.setEntityResolver(entityResolver);
sources[i].setXMLReader(reader);
}
}
return sources;
}



 Comments   
Comment by christopherincanada [ 27/Aug/13 ]

Here is an improved version of the fix that is more efficient:

private static Source[] getSchemaSource(InputSource[] schemas, EntityResolver entityResolver) throws SAXException
{
SAXSource[] sources = new SAXSource[schemas.length];
for (int i = 0; i < schemas.length; i++)
{
XMLReader reader = null;
if (entityResolver != null)
{
try

{ reader = getSAXParserFactory().newSAXParser().getXMLReader(); }

catch (ParserConfigurationException ex)

{ throw new SAXException(ex); }

reader.setEntityResolver(entityResolver);
}
sources[i] = new SAXSource(reader, schemas[i]);
}
return sources;
}

private static SAXParserFactory spFactory;

private static SAXParserFactory getSAXParserFactory()
{
if (spFactory == null)

{ spFactory = SAXParserFactory.newInstance(); spFactory.setNamespaceAware(true); }

return spFactory;
}





[JAXB-976] XJC generated field name is not consistent with getter/setter method names Created: 23/Aug/13  Updated: 23/Aug/13

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

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

Tags: naming, property, wrong, xjc

 Description   

When an attribute name contains an underscore character, the name of the generated field doesn't match the getter/setter method names.

E.g.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.foo.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="tag">
        <xs:complexType>
            <xs:attribute name="a_b_c" type="xs:string"/>
        </xs:complexType>
    </xs:element>
</xs:schema>

generates:

@XmlAttribute(name = "a_b_c")
protected String abc;

public String getABC() {
    return abc;
}

It would be better if the field is named ABC or aBC, accordingly to the accessor method names.

This gives some trouble when I want to know at runtime the property name binded to an xml attribute. I would usually look up for the XmlAttribute annotation and take the related field name, but with this mismatch I ended up replicating the naming behaviour of xjc in my own code

Thank you






[JAXB-975] Example wrong on http://jaxb.java.net/tutorial/section_3_1-Unmarshalling-and-Using-the-Data.html#Unmarshalling Created: 20/Aug/13  Updated: 20/Aug/13

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

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

Online examples



 Description   

The example code on the following page are incorrect:

It should be something like:

public <T> T unmarshal( Class<T> docClass, InputStream inputStream )
throws JAXBException {
JAXBContext jc = JAXBContext.newInstance( docClass );
Unmarshaller u = jc.createUnmarshaller();
JAXBElement<T> doc = (JAXBElement<T>)u.unmarshal( inputStream );
return doc.getValue();
}

Another issue with this example is that it doesn't demonstrate caching the JAXBContext (which is thread safe). If the intent is not to show reusing the JAXBContext, then the example could be further simplified to be:

public <T> T unmarshal( Class<T> docClass, InputStream inputStream )
throws JAXBException

{ return JAXB.unmarshal(inputStream, docClass); }

 Comments   
Comment by blaise_doughan [ 20/Aug/13 ]

There also appears to be some confusion as to what gets returned from the Unmarshal call. The code makes it appear as though it is always JAXBElement, when in reality it is only JAXBElement when the root element is mapped with @XmlElementDecl. Perhaps the code should be:

public <T> T unmarshal( Class<T> docClass, InputStream inputStream )
throws JAXBException

{ JAXBContext jc = JAXBContext.newInstance( docClass ); Unmarshaller u = jc.createUnmarshaller(); JAXBElement<T> doc = u.unmarshal( new StreamSource(inputStream) docClass ); return doc.getValue(); }




[JAXB-974] Schema generation fails when result path contains space Created: 11/Aug/13  Updated: 11/Aug/13

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

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


 Description   

Given the 'filename' variable contains path with space character, the following code:

context = JAXBContext.newInstance(klasses);
context.generateSchema(new SchemaOutputResolver() {
@Override
public Result createOutput(String namespaceUri, String suggestedFileName)
throws IOException

{ return new StreamResult(filename); }

});

results in the following exception:

java.io.IOException: java.io.FileNotFoundException: /var/lib/jenkins/jobs/Moonshine%20REVIEW/workspace/atomikos/target/test-home/config/schema.xsd (No such file or directory)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.writeTo(XmlSchemaGenerator.java:729)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator$Namespace.access$800(XmlSchemaGenerator.java:505)
at com.sun.xml.bind.v2.schemagen.XmlSchemaGenerator.write(XmlSchemaGenerator.java:487)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.generateSchema(JAXBContextImpl.java:832)
at org.atteo.evo.config.Configuration.generateSchema(Configuration.java:222)
at org.atteo.moonshine.services.Services.generateTemplateConfigurationFile(Services.java:250)
at org.atteo.moonshine.services.Services.setup(Services.java:277)
at org.atteo.moonshine.MoonshineImplementation.start(MoonshineImplementation.java:206)
at org.atteo.moonshine.tests.MoonshineRule$1.evaluate(MoonshineRule.java:136)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
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:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)



 Comments   
Comment by sentinel_atteo [ 11/Aug/13 ]

As you can see the space character is somehow converted to %20.

Comment by sentinel_atteo [ 11/Aug/13 ]

I think the problem is somewhere in the convertURL method of the StreamSerializer class where some weird magic is going on while extracting path to file from URL.

See:
https://java.net/projects/jaxb/sources/version2/content/trunk/txw2/runtime/src/main/java/com/sun/xml/txw2/output/StreamSerializer.java?rev=4179





[JAXB-973] generated code should be compilable with '-Xdoclint:all' Created: 07/Aug/13  Updated: 26/Sep/14  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





[JAXB-972] XJC simple mode: pluralisation not suitable for other languages (than english) Created: 06/Aug/13  Updated: 06/Aug/13

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

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

Windows, Java6
(Eclipse, XJC ant task)


Tags: simple

 Description   

When using "xjc:simple" is used when generating Java classes from a XSD file, the field names of collections in the generated classes are pluralised.

This might be convenient if the element names in the given XSD are in the english language, but it produces quite strange names in other languages than english.

So it might be very helpful if the pluralisation could be turned off when using "xjc:simple".

Thanks.






[JAXB-971] Regression: annotation @XmlJavaTypeAdapters on package is ignored since JAXB v2.2.4-1 Created: 26/Jul/13  Updated: 29/Jul/13

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: 0
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.





[JAXB-970] JAXB marshal if identation exceeds nested level 8 Created: 25/Jul/13  Updated: 09/Jan/14

Status: Open
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.10, 2.2.4u2
Fix Version/s: None

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

JDK 1.6 and JDK 1.7



 Description   

When calling JAXB marshal with pretty print it outputs:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a>
<b>
<c>
<d>
<e>
<f>
<g>
<h>
<i>
<j/>
</i>
</h>
</g>
</f>
</e>
</d>
</c>
</b>
</a>

The problem is when reaching indentation level 8 it restarts indentation.

The problem is in the:
IndentingUTF8XmlOutput.java

buggy function:
private void printIndent() throws IOException

{ write('\n'); int i = depth%8; write( indent8.buf, 0, i*unitLen ); i>>=3; // really i /= 8; for( ; i>0; i-- ) indent8.write(this); }

You can see that variable i is using remainder of division with 8.
After that i>>3 is already the remainder.
i >>= 3 (i = i >> 3) should be instead ... i = depth >> 3;

Other implementations does not exhibit such behavior.



 Comments   
Comment by matejsp [ 24/Dec/13 ]

There is another issue in Encoding class.
indent8.write(this); does not work as it should.

code
Encoded e = new Encoded(indentStr);
indent8 = new Encoded();
indent8.ensureSize(e.len*8);
unitLen = e.len;
for( int i=0; i<8; i++ )
System.arraycopy(e.buf, 0, indent8.buf, unitLen*i, unitLen);
code

The problem is that Encoded.ensureSize does not change the field of encoded length.

Comment by Iaroslav Savytskyi [ 09/Jan/14 ]

I agree with you.. It's strange.
But I also see good thing and may be this code was written to do exactly this.

Imagine 100x elements depth. Is it good idea to scroll to see the middle element???

We will discuss this internally.

Thanks a lot for reporting.

Comment by laune [ 09/Jan/14 ]

Also, consider the potentially huge amount of white space.





JAXBContext.newInstance fails when one schema uses a reference to another with: The element name ... has more than one mapping. (JAXB-962)

[JAXB-969] JAXBContext.newInstance fails when one schema uses a reference to another with: The element name ... has more than one mapping. Created: 23/Jul/13  Updated: 23/Jul/13  Resolved: 23/Jul/13

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

Type: Sub-task Priority: Blocker
Reporter: Phoenix_the_II Assignee: Iaroslav Savytskyi
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK1.7u25 on Ubuntu 13.04



 Description   

Having the same problem, different version



 Comments   
Comment by Phoenix_the_II [ 23/Jul/13 ]

Due to the nature of this problem I cannot reuse XSD to extend and reuse already existing object. Preventing me from making a further implementation of our code.

Changing XSD is not an option since they are 3rd party and industry standards.

Comment by Iaroslav Savytskyi [ 23/Jul/13 ]

JDK 1.7u25 and JDK 1.7u21 contain the same JAXB version.





[JAXB-968] Schema validation fails breaks for infinispan 2.4 default schema Created: 20/Jul/13  Updated: 04/Aug/13

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

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

JDK 7, OSX


Attachments: File infinispan-test.tgz    

 Description   

In version 2.2.4 and below the validation worked, in 2.2.5 it stopped working.
I see that there was a change to how <any> is handled see JAXB-869, maybe this the reason it broke as it is the abstractCacheStoreConfig complex type which is failing validation.

javax.xml.bind.UnmarshalException: unexpected element (uri:"urn:infinispan:config:4.2", local:"properties"). Expected elements are <{urn:infinispan:config:4.2}typedProperties>,<{urn:infinispan:config:4.2}singletonStore>,<{urn:infinispan:config:4.2}async>
	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662)
	at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258)
	at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253)
	at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120)
	at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:105)
	at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:262)
	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498)
	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
	at com.sun.xml.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.startElement(ValidatingUnmarshaller.java:102)
	at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:150)
	at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:551)
	at org.infinispan.config.parsing.NamespaceFilter.startElement(NamespaceFilter.java:29)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:357)
	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:140)
	at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:123)

This config xml file is from the hibernate-infinispan v3.6.10.Final

infinispan-config-4.2.xml
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:infinispan:config:4.2">
   <global>
      <transport transportClass = "org.infinispan.remoting.transport.jgroups.JGroupsTransport" 
            clusterName="infinispan-hibernate-cluster" distributedSyncTimeout="50000">
         <!-- Note that the JGroups transport uses sensible defaults if no configuration property is defined. -->
         <properties>
            <!-- TODO: Change to udp.xml once streaming transfer requirement has been removed.  -->
            <property name="configurationFile" value="flush-udp.xml"/>
         </properties>
         <!-- See the JGroupsTransport javadocs for more flags -->
      </transport>
   </global>

   <default>
      <!-- Used to register JMX statistics in any available MBean server -->
      <jmxStatistics enabled="false"/>
   </default>

   <!-- Default configuration is appropriate for entity/collection caching. -->
   <namedCache name="entity">
      <clustering mode="invalidation">
         <stateRetrieval fetchInMemoryState="false" timeout="20000"/>
         <sync replTimeout="20000"/>
      </clustering>
      <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false" />
      <!-- Eviction configuration.  WakeupInterval defines how often the eviction thread runs, in milliseconds.  
           0 means the eviction thread will never run.  A separate executor is used for eviction in each cache. -->
      <eviction wakeUpInterval="5000" maxEntries="10000" strategy="LRU"/>
      <expiration maxIdle="100000"/>
      <lazyDeserialization enabled="true"/>
   </namedCache>
   
   <!-- Default configuration is appropriate for entity/collection caching. -->
   <namedCache name="entity-repeatable">
      <clustering mode="invalidation">
         <stateRetrieval fetchInMemoryState="false" timeout="20000"/>
         <sync replTimeout="20000"/>
      </clustering>
      <!-- Note: REPEATABLE_READ is only useful if the application evicts/clears entities 
        from the Hibernate Session and then expects to repeatably re-read them in 
        the same transaction. Otherwise, the Session's internal cache provides a 
        repeatable-read semantic. Before choosing this config, carefully read the docs
        and make sure you really need REPEATABLE_READ.
       -->
      <locking isolationLevel="REPEATABLE_READ" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false"/>
      <!-- Eviction configuration.  WakeupInterval defines how often the eviction thread runs, in milliseconds.  
           0 means the eviction thread will never run.  A separate executor is used for eviction in each cache. -->
      <eviction wakeUpInterval="5000" maxEntries="10000" strategy="LRU"/>
      <expiration maxIdle="100000"/>
      <lazyDeserialization enabled="true"/>
   </namedCache>
   
   <!-- An alternative configuration for entity/collection caching that uses replication instead of invalidation -->
   <namedCache name="replicated-entity">
      <clustering mode="replication">
         <stateRetrieval fetchInMemoryState="false" timeout="20000"/>
         <sync replTimeout="20000"/>
      </clustering>
      <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false"/>
      <!-- Eviction configuration.  WakeupInterval defines how often the eviction thread runs, in milliseconds.  
           0 means the eviction thread will never run.  A separate executor is used for eviction in each cache. -->
      <eviction wakeUpInterval="5000" maxEntries="10000" strategy="LRU"/>
      <expiration maxIdle="100000"/>
      <lazyDeserialization enabled="true"/>
   </namedCache>
   
   
   <!-- A config appropriate for query caching. Does not replicate queries. -->
   <namedCache name="local-query">
      <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false"/>
      <!--Eviction configuration.  WakeupInterval defines how often the eviction thread runs, in milliseconds.  0 means
         the eviction thread will never run.  A separate executor is used for eviction in each cache. -->
      <eviction wakeUpInterval="5000" maxEntries="10000" strategy="LRU"/>
      <expiration maxIdle="100000"/>
   </namedCache>

   <!-- A query cache that replicates queries. Replication is asynchronous. -->
   <namedCache name="replicated-query">
      <clustering mode="replication">
         <async/>
      </clustering>
      <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false"/>
      <!--Eviction configuration.  WakeupInterval defines how often the eviction thread runs, in milliseconds.  0 means
         the eviction thread will never run.  A separate executor is used for eviction in each cache. -->
      <eviction wakeUpInterval="5000" maxEntries="10000" strategy="LRU"/>
      <expiration maxIdle="100000"/>
      <!-- State transfer forces all replication calls to be synchronous,
           so for calls to remain async, use a cluster cache loader instead -->
      <loaders passivation="false" shared="false" preload="false">
         <loader class="org.infinispan.loaders.cluster.ClusterCacheLoader" fetchPersistentState="false"
                 ignoreModifications="false" purgeOnStartup="false">
            <properties>
               <property name="remoteCallTimeout" value="20000"/>
            </properties>
         </loader>
      </loaders>
   </namedCache>

   <!-- Optimized for timestamp caching. A clustered timestamp cache
        is required if query caching is used, even if the query cache
        itself is configured with CacheMode=LOCAL. -->
   <namedCache name="timestamps">
      <clustering mode="replication">
         <async/>
      </clustering>
      <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
               lockAcquisitionTimeout="15000" useLockStriping="false"/>
      <lazyDeserialization enabled="true"/>
      <!--  Don't ever evict modification timestamps -->
      <eviction wakeUpInterval="0" strategy="NONE"/>
      <!-- State transfer forces all replication calls to be synchronous,
           so for calls to remain async, use a cluster cache loader instead -->
      <loaders passivation="false" shared="false" preload="false">
         <loader class="org.infinispan.loaders.cluster.ClusterCacheLoader" fetchPersistentState="false"
                 ignoreModifications="false" purgeOnStartup="false">
            <properties>
               <property name="remoteCallTimeout" value="20000"/>
            </properties>
         </loader>
      </loaders>
   </namedCache>

</infinispan>

The schema to validate against

infinispan-schema-4.2.xsd
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" targetNamespace="urn:infinispan:config:4.2" xmlns:tns="urn:infinispan:config:4.2" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="infinispan" type="tns:infinispanConfiguration"/>

  <xs:complexType name="infinispanConfiguration">
    <xs:sequence>
      <xs:element name="global" type="tns:globalConfiguration" minOccurs="0"/>
      <xs:element name="default" type="tns:configuration" minOccurs="0"/>
      <xs:element name="namedCache" type="tns:configuration" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="globalConfiguration">
    <xs:complexContent>
      <xs:extension base="tns:abstractConfigurationBean">
        <xs:all>
          <xs:element name="asyncListenerExecutor" type="tns:executorFactoryType" minOccurs="0"/>
          <xs:element name="asyncTransportExecutor" type="tns:executorFactoryType" minOccurs="0"/>
          <xs:element name="evictionScheduledExecutor" type="tns:scheduledExecutorFactoryType" minOccurs="0"/>
          <xs:element name="replicationQueueScheduledExecutor" type="tns:scheduledExecutorFactoryType" minOccurs="0"/>
          <xs:element name="globalJmxStatistics" type="tns:globalJmxStatisticsType" minOccurs="0"/>
          <xs:element name="transport" type="tns:transportType" minOccurs="0"/>
          <xs:element name="serialization" type="tns:serializationType" minOccurs="0"/>
          <xs:element name="shutdown" type="tns:shutdownType"