[JAXB-965] compiler was unable to honor this schemaBinding customization (in episodic compilation) Created: 24/Jun/13  Updated: 24/Jun/13

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

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

JDK 1.7.0_21 Ubuntu 12.04.2 JAXB 2.2.7


Tags: jaxb, jaxb-xjc

 Description   

When generating Java source files from a bunch of schemas importing one another (and therefore using episodic compilation to avoid having the same classes generated twice), and using some rather complex XSD files (which however I cannot edit since they are industry standard), I get "compiler was unable to honor this schemaBinding customization" failures in random locations. I've created a github repo that captures the case. You can view the "bug" by doing:

git clone https://github.com/mperdikeas/unable_to_honor.git && cd unable_to_honor && ant

Not only will you see the "compiler was unable to honor this schemaBinding" messages, but moreover on successive invocations of "ant clean && ant" you will see the exact line complained about being different (but always the last line in the binding file which to me suggest some parsing bug). I posted on SO on that one as well here:

http://stackoverflow.com/questions/17265960/jaxb-xjc-episodic-compilation-failing-in-random-way-compiler-was-unable-to-ho






[JAXB-963] JAXB xjc crashes while parsing trivial 8-line XSD file when -binding is used together with -catalog Created: 12/Jun/13  Updated: 03/Oct/14

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

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

Ubuntu 12.04.2, JDK 1.7.0_21


Tags: binding, catalog, jaxb, jaxb-xjc, xjc

 Description   

Below is the absolute trivial, minimal example that demonstrates the problem.

Three schema files: A.xsd, B.xsd, C.xsd in the following import configuration:

  • C.xsd imports A.xsd and B.xsd
  • B.xsd imports A.xsd

So A.xsd is imported directly by C.xsd and again indirectly through B.xsd. The problem occurs when trying to run xjc (ver. 2.2.4) on C.xsd when both a catalog and a binding file is used (even an empty one).

---------- FILE A.xsd
<schema targetNamespace="foo://a"
xmlns="http://www.w3.org/2001/XMLSchema">
<simpleType name="year">
<restriction base="dateTime">
<pattern value="\d

{4}

"/>
</restriction>
</simpleType>
</schema>

---------- FILE B.xsd
<schema targetNamespace="foo://b"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="foo://a" schemaLocation="boo://a.xsd"/>
</schema>

---------- FILE C.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="foo://c">
<import namespace="foo://a" schemaLocation="A.xsd"/>
<import namespace="foo://b" schemaLocation="B.xsd"/>
</schema>

---------- FILE catalog.xml
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="boo://a.xsd" uri="A.xsd"/>
</catalog>

---------- FILE binding.xjb
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1"/>

Given the above files, all placed in the same directory the below invocation succeeds:

xjc -d src -extension -catalog catalog.xml C.xsd

whereas the following invocation:

xjc -d src -extension -catalog catalog.xml C.xsd -b bindings.xjb

... fails with the bug-like message (pointing to some internal mess-up?):

parsing a schema...
[ERROR] 'year' is already defined
line 8 of file:/home/brutus/A.xsd

[ERROR] (related to above error) the first definition appears here
line 3 of file:/home/brutus/A.xsd

Failed to parse a schema.

All components of the above minimal reproduction are necessary to trigger the bug. If no binding file is used xjc parses correctly and generates code. If no catalog file is used xjc parses correctly and generates code. If both binding file an catalog are used xjc fails to parse. This is a blocking issue at least in my particular case as the XSD files are given and cannot be modified and I have to use both a catalog and a binding file (to get around other issues).



 Comments   
Comment by markzimmngc [ 20/Dec/13 ]

I am seeing this same issue with java version 1.7.0_45 and xjc 2.2.4-2 on RedHat.

Comment by lexi [ 03/Oct/14 ]

Related to or duplicate of https://java.net/jira/browse/JAXB-1045





[JAXB-971] Regression: annotation @XmlJavaTypeAdapters on package is ignored since JAXB v2.2.4-1 Created: 26/Jul/13  Updated: 13/Jun/16

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

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

Windows 7 x64; JDK 1.6 and JDK 1.7



 Description   

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

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

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

and

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

The attached project has these modifications:

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

and

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

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

and

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

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

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

BUILD SUCCESSFUL

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

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

BUILD SUCCESSFUL

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

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

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



 Comments   
Comment by donatasc [ 26/Jul/13 ]

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

Comment by Iaroslav Savytskyi [ 29/Jul/13 ]

Hi,

Thanks a lot for reporting.

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

Comment by matejsp [ 13/Jun/16 ]

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

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





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

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

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

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



 Description   

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

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



 Comments   
Comment by Dr4gon [ 04/Oct/16 ]

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

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





[JAXB-789] Allow specifying Navigator via JAXBRIContext properties Created: 12/Sep/10  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 789

 Description   

Currently I can provide my own implementation of annotation reader via JAXB
context properties:

final AnnotationReader<Type, Class, Field, Method> annotationReader = new
AnnoxAnnotationReader();

final Map<String, Object> properties = new HashMap<String, Object>();

properties.put(JAXBRIContext.ANNOTATION_READER, annotationReader);

final JAXBContext context = JAXBContext.newInstance(
"org.jvnet.annox.samples.po",
Thread.currentThread().getContextClassLoader(),
properties);

I need an opportunity to specify my own implementation of Navigator
(com.sun.xml.bind.v2.model.nav.Navigator) as well.

ModelBuilder accepts reader, navigator, subclassReplacements and
defaultNamespaceRemap as constructor parameters:

public ModelBuilder(
AnnotationReader<T, C, F, M> reader,
Navigator<T, C, F, M> navigator,
Map<C, C> subclassReplacements,
String defaultNamespaceRemap
)

From these parameters reader, subclassReplacements and defaultNamespaceRemap
can be specified via JAXBRIContext properties:

public static final String ANNOTATION_READER =
RuntimeAnnotationReader.class.getName();
public static final String SUBCLASS_REPLACEMENTS =
"com.sun.xml.bind.subclassReplacements";
public static final String DEFAULT_NAMESPACE_REMAP =
"com.sun.xml.bind.defaultNamespaceRemap";

But not navigator.






[JAXB-770] Problems with jaxb:version Created: 02/Jul/10  Updated: 15/Apr/11

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

Type: Task Priority: Critical
Reporter: lrflesch Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: HP


Attachments: Text File 20100702_Bug770.diff    
Issuezilla Id: 770

 Description   

If I set jaxb:version="2.2" or jaxb:version="2.2.1" and run xjc, I get the
following error message:

[ERROR] JAXB version attribute must be "1.0"

xjc will accept jaxb:version="2.1". I recommend that xjc be updated to accept
"2.2" and "2.2.1". I also recommend that the error message be changed to:

[ERROR] Unrecognized JAXB version in jaxb:version attribute.



 Comments   
Comment by gmazza [ 02/Jul/10 ]

According to the binding schema's definition of the version attribute, the
jaxb:version is not the version of JAXB (xjc) you're using, but rather the
schema version of the binding file--here, for example, is 2.0's schema:

http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd

Replacing the 2 with a 1 above will get you the 1.0 schema.

Allowing values of 2.1, 2.2, 2.2.1, etc. will confuse things as it implies that
you're specifying the desired version of xjc to use when in reality you're just
stating the binding schema your binding file is following.

I think the switch should be then to allow just 1.0 or 2.0 as values (not 2.1,
as there's no binding schema with that version number), and instead of
"Unrecognized JAXB version..." as the error message (which could imply it can't
read the binding file, and also might confuse users who are expecting to place
the xjc version there) to say "JAXB binding schema version attribute must be
"1.0" or "2.0".

Comment by gmazza [ 02/Jul/10 ]

More info on this is in the JAXB 2.2 specification (Dec. 2009), Section 7.1.4:

7.1.4 Version Attribute
The normative binding schema specifies a global version attribute. It is used
to identify the version of the binding declarations. For example, a future
version of this specification may use the version attribute to specify backward
compatibility. To indicate this version of the specification, the version
should be "2.0". It is also valid for @version to be “1.0�. If any other
version is specified, it must result in an invalid customization as specified in
Section 7.1.5, “Invalid Customizations.�

Comment by gmazza [ 02/Jul/10 ]

Created an attachment (id=359)
Patch to require 1.0 or 2.0 for binding schema version numbers

Comment by gmazza [ 02/Jul/10 ]

Attached patch requires 1.0 or 2.0 for the binding schema value as required in
Section 7.1.4 of the JAXB 2.2 spec. Acceptance of 2.1 has been removed.

However, unfortunately all episode files created by xjc--which are really
binding files--have been using 2.1 as the binding schema version. The attached
patch also fixes that problem and makes it use 2.0.

Unfortunately that will mean that those who use future versions of JAXB with
their old episode files will need to lower the version number manually from 2.1
to 2.0. Expect some future hate mail as a result of this change, but per the
spec, I don't see how JAXB/xjc can/should allow 2.1 as a value. Thankfully,
changing the version number in an episode file is a pretty minor change to make.

Comment by gmazza [ 04/Aug/10 ]

Marking as patch attached.

Comment by Martin Grebac [ 15/Apr/11 ]

marking higher so that I look at this one





[JAXB-625] own PrologCodeWriter or set own prolog string Created: 26/Mar/09  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Attachments: Text File options_java_patch.txt    
Issuezilla Id: 625

 Description   

Hi again! (:

per default jaxb writes into each file this message:
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) [...
snip ...]
// Generated on: 2009.03.26 at 05:55:52 PM CET
//

Is it possible to set a user defined file prologue (perhaps in a jaxb plugin)?
This would be useful, to replace the currently generated message e.g. with the
BSD license text.

My first attempt was to extend my own class from PrologCodeWriter:
public class MyOwnWriter extends PrologCodeWriter {
public MyOwnWriter(CodeWriter core)

{ super(core, "BSD-License"); }

}

But I did not found a suitable place to set the new writer.

I found in the Options.class the two methods:
createCodeWriter()
createCodeWriter(CodeWriter)

but only getPrologComment() has no possibilities to set the prologue comment.
createCodeWriter(CodeWriter) returns a new instance of PrologCodeWriter just
hard coded with getPrologComment() (see: return new PrologCodeWriter(
core,getPrologComment() )

so is there a possibility to set an own code writer or set an own prologue comment?

regards Flori



 Comments   
Comment by florianbachmann [ 02/Apr/09 ]

Created an attachment (id=304)
this could be a possible patch

Comment by florianbachmann [ 16/Nov/09 ]

any possible solution in sight?

Comment by florianbachmann [ 16/Nov/09 ]

any possible solution in sight?





[JAXB-597] Jaxb RI sources differ each time we build jaxb workspace Created: 05/Feb/09  Updated: 15/Apr/11

Status: Open
Project: jaxb
Component/s: docs
Affects Version/s: 2.1.9
Fix Version/s: not determined

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 597

 Description   

I am filing this under docs though it for the jaxb source zip obtained by
building jaxb RI.
When we build jaxb RI, some classes for runtime are generated at build time.
Each time we build the order of the getters/setters and case logic differs.

When I talked to Kohsuke, he mentioned this can be fixed and this has to be done
somwhere in relaxng code. This is a problem who depends on sources to see that
sources differ each time RI is built.

For ex:
— a/src/com/sun/tools/jxc/gen/config/Classes.java Mon Feb 02 11:53:20 2009 -0800
+++ b/src/com/sun/tools/jxc/gen/config/Classes.java Tue Feb 03 11:07:48 2009 -0800
@@ -51,6 +51,18 @@ public class Classes extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
+ case 2:
+ {
+ if(($_uri == "" && $_local == "excludes"))

{ + $runtime.onEnterElementConsumed($__uri, $__local, $__qname, $attrs); + $_ngcc_current_state = 6; + }
+ else { + $_ngcc_current_state = 1; + $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); + }
+ }
+ break;
case 0:
{ revertToParentFromEnterElement(this, super._cookie, $__uri, $__local, $__qname, $attrs); @@ -84,18 +96,6 @@ public class Classes extends NGCCHandler }
}
break;
- case 2:
- {
- if(($_uri == "" && $_local == "excludes")) { - $runtime.onEnterElementConsumed($__uri, $__local, $__qname, $attrs); - $_ngcc_current_state = 6; - }
- else { - $_ngcc_current_state = 1; - $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); - }
- }
- break;
default:
{
unexpectedEnterElement($__qname);
@@ -109,6 +109,12 @@ public class Classes extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
+ case 2:
+ { + $_ngcc_current_state = 1; + $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); + }
+ break;
case 0:
{
revertToParentFromLeaveElement(this, super.cookie, $_uri,
$_local, $_qname);
@@ -118,6 +124,17 @@ public class Classes extends NGCCHandler
{ $_ngcc_current_state = 3; $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); + }
+ break;
+ case 1:
+ {
+ if(($_uri == "" && $_local == "classes")) { + $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); + $_ngcc_current_state = 0; + }
+ else { + unexpectedLeaveElement($__qname); + }
}
break;
case 3:
@@ -131,28 +148,11 @@ public class Classes extends NGCCHandler
}
}
break;
- case 2:
- { - $_ngcc_current_state = 1; - $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); - }
- break;
case 8:
{
if(($_uri == "" && $_local == "includes")) { $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); $_ngcc_current_state = 2; - }
- else { - unexpectedLeaveElement($__qname); - }
- }
- break;
- case 1:
- {
- if(($_uri == "" && $_local == "classes")) { - $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); - $_ngcc_current_state = 0; }
else {
unexpectedLeaveElement($__qname);
@@ -172,6 +172,12 @@ public class Classes extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
+ case 2:
+ { + $_ngcc_current_state = 1; + $runtime.sendEnterAttribute(super._cookie, $__uri, $__local, $__qname); + }
+ break;
case 0:
{
revertToParentFromEnterAttribute(this, super.cookie, $_uri,
$_local, $_qname);
@@ -180,12 +186,6 @@ public class Classes extends NGCCHandler
case 4:
{ $_ngcc_current_state = 3; - $runtime.sendEnterAttribute(super._cookie, $__uri, $__local, $__qname); - }
- break;
- case 2:
- { - $_ngcc_current_state = 1; $runtime.sendEnterAttribute(super._cookie, $__uri, $__local, $__qname); }
break;
@@ -202,6 +202,12 @@ public class Classes extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
+ case 2:
+ { + $_ngcc_current_state = 1; + $runtime.sendLeaveAttribute(super._cookie, $__uri, $__local, $__qname); + }
+ break;
case 0:
{
revertToParentFromLeaveAttribute(this, super.cookie, $_uri,
$_local, $_qname);
@@ -210,12 +216,6 @@ public class Classes extends NGCCHandler
case 4:
{ $_ngcc_current_state = 3; - $runtime.sendLeaveAttribute(super._cookie, $__uri, $__local, $__qname); - }
- break;
- case 2:
- { - $_ngcc_current_state = 1; $runtime.sendLeaveAttribute(super._cookie, $__uri, $__local, $__qname); }
break;
@@ -229,16 +229,22 @@ public class Classes extends NGCCHandler

public void text(String $value) throws SAXException {
switch($_ngcc_current_state) {
- case 0:
- { - revertToParentFromText(this, super._cookie, $value); - }
- break;
case 9:
{ include_content = $value; $_ngcc_current_state = 8; action2(); + }
+ break;
+ case 2:
+ { + $_ngcc_current_state = 1; + $runtime.sendText(super._cookie, $value); + }
+ break;
+ case 0:
+ { + revertToParentFromText(this, super._cookie, $value); }
break;
case 4:
@@ -248,6 +254,20 @@ public class Classes extends NGCCHandler
action0();
}
break;
+ case 10:
+ { + __text = $value; + $_ngcc_current_state = 9; + action3(); + }
+ break;
+ case 6:
+ { + __text = $value; + $_ngcc_current_state = 4; + action1(); + }
+ break;
case 3:
{ exclude_content = $value; @@ -255,31 +275,11 @@ public class Classes extends NGCCHandler action0(); }
break;
- case 2:
- { - $_ngcc_current_state = 1; - $runtime.sendText(super._cookie, $value); - }
- break;
- case 10:
- { - __text = $value; - $_ngcc_current_state = 9; - action3(); - }
- break;
case 8:
{ include_content = $value; $_ngcc_current_state = 8; action2(); - }
- break;
- case 6:
- { - __text = $value; - $_ngcc_current_state = 4; - action1(); }
break;
}

— a/src/com/sun/tools/jxc/gen/config/Config.java Mon Feb 02 11:53:20 2009 -0800
+++ b/src/com/sun/tools/jxc/gen/config/Config.java Tue Feb 03 11:07:48 2009 -0800
@@ -49,7 +49,46 @@ public class Config extends NGCCHandler
case 4:
{
if(($_uri == "" && $_local == "classes")) { - NGCCHandler h = new Classes(this, super._source, $runtime, 34); + NGCCHandler h = new Classes(this, super._source, $runtime, 22); + spawnChildFromEnterElement(h, $__uri, $__local, $__qname, $attrs); + }
+ else { + unexpectedEnterElement($__qname); + }
+ }
+ break;
+ case 7:
+ {
+ if(($ai = $runtime.getAttributeIndex("","baseDir"))>=0) { + $runtime.consumeAttribute($ai); + $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); + }
+ else {+ unexpectedEnterElement($__qname);+ }
+ }
+ break;
+ case 2:
+ {
+ if(($_uri == "" && $_local == "schema")) { + NGCCHandler h = new Schema(this, super._source, $runtime, 20, baseDir); + spawnChildFromEnterElement(h, $__uri, $__local, $__qname, $attrs); + }
+ else {+ $_ngcc_current_state = 1;+ $runtime.sendEnterElement(super._cookie, $__uri, $__local,$__qname, $attrs);+ }
+ }
+ break;
+ case 0:
+ { + revertToParentFromEnterElement(this, super._cookie, $__uri, $__local, $__qname, $attrs); + }
+ break;
+ case 1:
+ {
+ if(($_uri == "" && $_local == "schema")) { + NGCCHandler h = new Schema(this, super._source, $runtime, 19, baseDir); spawnChildFromEnterElement(h, $__uri, $__local, $__qname, $attrs); }
else {
@@ -62,45 +101,6 @@ public class Config extends NGCCHandler
if(($_uri == "" && $_local == "config")) { $runtime.onEnterElementConsumed($__uri, $__local, $__qname, $attrs); $_ngcc_current_state = 7; - }
- else { - unexpectedEnterElement($__qname); - }
- }
- break;
- case 1:
- {
- if(($_uri == "" && $_local == "schema")) { - NGCCHandler h = new Schema(this, super._source, $runtime, 31, baseDir); - spawnChildFromEnterElement(h, $__uri, $__local, $__qname, $attrs); - }
- else {- unexpectedEnterElement($__qname);- }
- }
- break;
- case 0:
- { - revertToParentFromEnterElement(this, super._cookie, $__uri, $__local, $__qname, $attrs); - }
- break;
- case 2:
- {
- if(($_uri == "" && $_local == "schema")) { - NGCCHandler h = new Schema(this, super._source, $runtime, 32, baseDir); - spawnChildFromEnterElement(h, $__uri, $__local, $__qname, $attrs); - }
- else { - $_ngcc_current_state = 1; - $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); - }
- }
- break;
- case 7:
- {
- if(($ai = $runtime.getAttributeIndex("","baseDir"))>=0) { - $runtime.consumeAttribute($ai); - $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); }
else {
unexpectedEnterElement($__qname);
@@ -121,20 +121,15 @@ public class Config extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
- case 1:
+ case 7:
{
- if(($_uri == "" && $_local == "config")) {
- $runtime.onLeaveElementConsumed($_uri, $local, $_qname);
- $_ngcc_current_state = 0;
+ if(($ai = $runtime.getAttributeIndex("","baseDir"))>=0) { + $runtime.consumeAttribute($ai); + $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); }
else { unexpectedLeaveElement($__qname); }
- }
- break;
- case 0:
- { - revertToParentFromLeaveElement(this, super._cookie, $__uri, $__local, $__qname); }
break;
case 2:
@@ -143,11 +138,16 @@ public class Config extends NGCCHandler
$runtime.sendLeaveElement(super.cookie, $uri, $_local,
$__qname);
}
break;
- case 7:
+ case 0:
{
- if(($ai = $runtime.getAttributeIndex("","baseDir"))>=0) { - $runtime.consumeAttribute($ai); - $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); + revertToParentFromLeaveElement(this, super._cookie, $__uri, $__local, $__qname); + }
+ break;
+ case 1:
+ {
+ if(($_uri == "" && $_local == "config")) { + $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); + $_ngcc_current_state = 0; }
else {
unexpectedLeaveElement($__qname);
@@ -167,9 +167,14 @@ public class Config extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
- case 0:
+ case 7:
{
- revertToParentFromEnterAttribute(this, super.cookie, $_uri,
$_local, $_qname);
+ if(($_uri == "" && $_local == "baseDir")) { + $_ngcc_current_state = 6; + }
+ else { + unexpectedEnterAttribute($__qname); + }
}
break;
case 2:
@@ -178,14 +183,9 @@ public class Config extends NGCCHandler
$runtime.sendEnterAttribute(super.cookie, $uri, $_local,
$__qname);
}
break;
- case 7:
+ case 0:
{
- if(($_uri == "" && $_local == "baseDir")) { - $_ngcc_current_state = 6; - }
- else { - unexpectedEnterAttribute($__qname); - }
+ revertToParentFromEnterAttribute(this, super.cookie, $_uri,
$_local, $_qname);
}
break;
default:
@@ -201,9 +201,14 @@ public class Config extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
- case 0:
+ case 5:
{
- revertToParentFromLeaveAttribute(this, super.cookie, $_uri,
$_local, $_qname);
+ if(($_uri == "" && $_local == "baseDir")) { + $_ngcc_current_state = 4; + }
+ else { + unexpectedLeaveAttribute($__qname); + }
}
break;
case 2:
@@ -212,14 +217,9 @@ public class Config extends NGCCHandler
$runtime.sendLeaveAttribute(super.cookie, $uri, $_local,
$__qname);
}
break;
- case 5:
+ case 0:
{
- if(($_uri == "" && $_local == "baseDir")) { - $_ngcc_current_state = 4; - }
- else { - unexpectedLeaveAttribute($__qname); - }
+ revertToParentFromLeaveAttribute(this, super.cookie, $_uri,
$_local, $_qname);
}
break;
default:
@@ -233,17 +233,6 @@ public class Config extends NGCCHandler
public void text(String $value) throws SAXException {
int $ai;
switch($_ngcc_current_state) {
- case 0:
- { - revertToParentFromText(this, super._cookie, $value); - }
- break;
- case 2:
- { - $_ngcc_current_state = 1; - $runtime.sendText(super._cookie, $value); - }
- break;
case 7:
{
if(($ai = $runtime.getAttributeIndex("","baseDir"))>=0) { @@ -259,25 +248,36 @@ public class Config extends NGCCHandler action1(); }
break;
+ case 2:
+ { + $_ngcc_current_state = 1; + $runtime.sendText(super._cookie, $value); + }
+ break;
+ case 0:
+ { + revertToParentFromText(this, super._cookie, $value); + }
+ break;
}
}

public void onChildCompleted(Object $_result, int $cookie_, boolean
$_needAttCheck_)throws SAXException {
switch($_cookie_) {
- case 34:
+ case 22:
{ classes = ((Classes)$__result__); $_ngcc_current_state = 2; }
break;
- case 31:
+ case 20:
{ _schema = ((Schema)$__result__); action0(); $_ngcc_current_state = 1; }
break;
- case 32:
+ case 19:
{
schema = ((Schema)$result_);
action0();

— a/src/com/sun/tools/jxc/gen/config/Schema.java Mon Feb 02 11:53:20 2009 -0800
+++ b/src/com/sun/tools/jxc/gen/config/Schema.java Tue Feb 03 11:07:48 2009 -0800
@@ -41,6 +41,17 @@ public class Schema extends NGCCHandler
$localName = $__local;
$qname = $__qname;
switch($_ngcc_current_state) {
+ case 10:
+ {
+ if(($_uri == "" && $_local == "schema")) {+ $runtime.onEnterElementConsumed($__uri, $__local, $__qname,$attrs);+ $_ngcc_current_state = 6;+ }

+ else

{ + unexpectedEnterElement($__qname); + }

+ }
+ break;
case 0:
{
revertToParentFromEnterElement(this, super.cookie, $_uri,
$_local, $_qname, $attrs);
@@ -67,17 +78,6 @@ public class Schema extends NGCCHandler
else

{ $_ngcc_current_state = 2; $runtime.sendEnterElement(super._cookie, $__uri, $__local, $__qname, $attrs); - }
  • }
  • break;
  • case 10:
  • {
  • if(($_uri == "" && $_local == "schema")) { - $runtime.onEnterElementConsumed($__uri, $__local, $__qname, $attrs); - $_ngcc_current_state = 6; - }
  • else { - unexpectedEnterElement($__qname); }

    }
    break;
    @@ -112,17 +112,6 @@ public class Schema extends NGCCHandler
    }
    }
    break;

  • case 1:
  • {
  • if(($_uri == "" && $_local == "schema")) { - $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); - $_ngcc_current_state = 0; - }
  • else { - unexpectedLeaveElement($__qname); - }
  • }
  • break;
    case 6:
    {
    if(($ai = $runtime.getAttributeIndex("","namespace"))>=0)
    Unknown macro: {@@ -132,6 +121,17 @@ public class Schema extends NGCCHandler else { $_ngcc_current_state = 2; $runtime.sendLeaveElement(super._cookie, $__uri, $__local, $__qname); + }+ }

    + break;
    + case 1:
    +

    Unknown macro: {+ if(($__uri == "" && $__local == "schema")) { + $runtime.onLeaveElementConsumed($__uri, $__local, $__qname); + $_ngcc_current_state = 0; + }+ else { + unexpectedLeaveElement($__qname); } }

    break;
    @@ -193,20 +193,20 @@ public class Schema extends NGCCHandler
    revertToParentFromLeaveAttribute(this, super.cookie, $_uri,
    $_local, $_qname);
    }
    break;
    + case 3:
    +

    Unknown macro: {+ if(($__uri == "" && $__local == "location")) { + $_ngcc_current_state = 1; + }+ else { + unexpectedLeaveAttribute($__qname); + }+ }

    + break;
    case 2:

    { $_ngcc_current_state = 1; $runtime.sendLeaveAttribute(super._cookie, $__uri, $__local, $__qname); - }
  • break;
  • case 7:
  • {
  • if(($_uri == "" && $_local == "namespace")) { - $_ngcc_current_state = 2; - }
  • else { - unexpectedLeaveAttribute($__qname); - }

    }
    break;
    case 6:
    @@ -215,10 +215,10 @@ public class Schema extends NGCCHandler
    $runtime.sendLeaveAttribute(super.cookie, $uri, $_local,
    $__qname);
    }
    break;

  • case 3:
    + case 7:
    {
  • if(($_uri == "" && $_local == "location")) {
  • $_ngcc_current_state = 1;
    + if(($_uri == "" && $_local == "namespace")) { + $_ngcc_current_state = 2; }

    else

    { unexpectedLeaveAttribute($__qname); @@ -241,6 +241,13 @@ public class Schema extends NGCCHandler revertToParentFromText(this, super._cookie, $value); }

    break;
    + case 4:
    +

    { + loc = $value; + $_ngcc_current_state = 3; + action0(); + }

    + break;
    case 2:

    Unknown macro: { if(($ai = $runtime.getAttributeIndex("","location"))>=0) { @@ -253,19 +260,6 @@ public class Schema extends NGCCHandler } }

    break;

  • case 8:
  • { - namespace = $value; - $_ngcc_current_state = 7; - }
  • break;
  • case 4:
  • { - loc = $value; - $_ngcc_current_state = 3; - action0(); - }
  • break;
    case 6:
    Unknown macro: { if(($ai = $runtime.getAttributeIndex("","namespace"))>=0) { @@ -276,6 +270,12 @@ public class Schema extends NGCCHandler $_ngcc_current_state = 2; $runtime.sendText(super._cookie, $value); }+ }

    + break;
    + case 8:
    +

    { + namespace = $value; + $_ngcc_current_state = 7; }

    break;
    }

— a/src/com/sun/xml/bind/v2/schemagen/xmlschema/Occurs.java Mon Feb 02
11:53:20 2009 -0800
+++ b/src/com/sun/xml/bind/v2/schemagen/xmlschema/Occurs.java Tue Feb 03
11:07:48 2009 -0800
@@ -13,9 +13,9 @@ public interface Occurs
public Occurs minOccurs(int value);

@XmlAttribute
+ public Occurs maxOccurs(String value);
+
+ @XmlAttribute
public Occurs maxOccurs(int value);

  • @XmlAttribute
  • public Occurs maxOccurs(String value);
    -
    }

— a/src/com/sun/xml/bind/v2/schemagen/xmlschema/SimpleType.java Mon Feb 02
11:53:20 2009 -0800
+++ b/src/com/sun/xml/bind/v2/schemagen/xmlschema/SimpleType.java Tue Feb 03
11:07:48 2009 -0800
@@ -12,10 +12,10 @@ public interface SimpleType

@XmlAttribute("final")

  • public SimpleType _final(String[] value);
    + public SimpleType _final(String value);

@XmlAttribute("final")

  • public SimpleType _final(String value);
    + public SimpleType _final(String[] value);

@XmlAttribute
public SimpleType name(String value);



 Comments   
Comment by Martin Grebac [ 09/Feb/09 ]

Just changing to enhancement.





[JAXB-572] Check sources modifications to regenerate files or not Created: 28/Nov/08  Updated: 15/Apr/11

Status: Open
Project: jaxb
Component/s: maven-plugin
Affects Version/s: 2.0 EA1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Text File jaxb-schemagen-patch.txt    
Issuezilla Id: 572

 Description   

The maven plugin "maven-jaxb-schemagen-plugin" generates files for each build
even if source files (xsd files) didn't change.

So the idea is to optimize build through a "StaleSourceScanner" of source files.



 Comments   
Comment by myannou [ 28/Nov/08 ]

Created an attachment (id=277)
jaxb-schemagen-patch.txt

Comment by myannou [ 28/Nov/08 ]

The attached patch (jaxb-schemagen-patch.txt) add this new feature.

Comment by myannou [ 29/Nov/08 ]

I forgot to assign this issue

Comment by kohsuke [ 08/Dec/08 ]

I'd like to apply this patch, but for that we need you to sign SCA.
Can you please look at
https://glassfish.dev.java.net/public/GovernancePolicy.html and fax the signed
form, then update the post?

Comment by kohsuke [ 08/Dec/08 ]

Also cross-linking a similar issue:
https://jax-ws-commons.dev.java.net/issues/show_bug.cgi?id=27

Comment by myannou [ 14/Dec/08 ]

Ok I signed the form and sent it back by mail.

Comment by Martin Grebac [ 15/Apr/11 ]

increase priority so that I look at it





[JAXB-569] Provide schema for episode files. Created: 18/Nov/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 569

 Description   

Provide schema for episode files. See:
http://forums.java.net/jive/thread.jspa?messageID=314368



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

So that I don't forget.





[JAXB-513] External binding customization file not being read from jar using episode feature Created: 09/Jun/08  Updated: 12/Oct/12

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

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

Operating System: All
Platform: All
URL: http://www.nabble.com/episode-issue-td17433892.html


Issuezilla Id: 513
Tags: incomplete

 Description   

Please see details at:
<http://www.nabble.com/episode-issue-td17433892.html>

Note that I have provided a repeatble test case to Kohsuke which should be kept
confidential to jaxb dev team.

I am giving this a P2 priority since it is a blocker for my project and also
because I have heard from others facing the same issues. Thanks.



 Comments   
Comment by najmi [ 09/Jun/08 ]

Fixed typo

Comment by Martin Grebac [ 28/Jul/08 ]

I got the instructions from Kohsuke, but the access doesn't work for me.

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning





[JAXB-509] JAXB should warn about common mistakes in schemas Created: 01/Jun/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 509

 Description   

I've experienced at least two cases where the schema was written in a way that
caused JAXB to either fail to unmarshal data or to present the data in an
unusable fashion. I believe JAXB should detect these cases and elicit a warning
to alert users to possible mistakes in their schema's. Had this been
implemented for me, it would have saved me a couple weeks of consternation not
understanding why JAXB wasn't working as advertised. In the end, it was pointed
out to me by a JAXB developer that my schema was probably in error. So, without
further adieu, here are two cases that I ran into...

1. xsd:element names with empty spaces.

For instance, <xsd:element name="MyElement " .../>. While XML element names are
allowed by the spec to contain leading and trailing spaces, an element
definition such as this is generally a mistake by the schema author. And,
ultimately, JAXB will silently fail to unmarshal XML that appears to match the
schema.

One symptom of this is seeing methods generated that are appended with "_0020".
For instance, getMyElement_0020(). So, if users know to look for this, they
can correct their schema. However, because this is not widely known by users,
it would make sense for JAXB's schema parser/code generator to generate a
warning to make this more apparent.

2. xsd:element and neglecting to define "type" attribute

I had an element that contained a list of Strings, except the element was
defined as...

<xsd:complexType name="SomeListType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="1" name="SomeString"/>
</xsd:sequence>
</xsd:complexType>

Note the lack of type="xsd:string". So, when I print out the values of the
list, I get (for a list of 3 elements)...

SomeStrings: [[out:SomeString: null], [out:SomeString: null], [out:SomeString:
null]]

This is completely useless to me. But when I change the "SomeString" definition
to the following, I get a working list of Strings as expected...

<xsd:element maxOccurs="unbounded" minOccurs="1" name="SomeString"
type="xsd:string"/>

I think JAXB should, minimally, warn users about situations where it will
unmarshal nothing but meaningless garbage. But I also think it could go further
here and actually default to type xsd:string if not otherwise supplied with the
type. I leave you to consider that, as I'm not clear on the side-effects of
such a default?

Note that I experienced these issues when using JAX-WS's wsimport tool. I don't
know if that makes a difference in how JAXB would elicit warnings, but I thought
I'd mention it.

Jake



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

raising priority so that I look at it





[JAXB-404] XJC fails to generate getContent() method with mixed="true" Created: 16/Aug/07  Updated: 12/Apr/11

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

Type: Bug Priority: Critical
Reporter: afedoro Assignee: Martin Grebac
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Zip Archive test_case.zip    
Issuezilla Id: 404

 Description   

It seems like XJC fails to generate a getContent() accessor when a type is
defined with the mixed="true" attribute and it is an extension of a type that is
defined with a mixed="false" extension. Although the base type should not have a
getContent() method, the derived one should, since it has its mixed attribute
set to true.

Please see the attached test case (schema and generated classes).



 Comments   
Comment by afedoro [ 16/Aug/07 ]

Created an attachment (id=194)
Test Case

Comment by kohsuke [ 22/Aug/07 ]

This is in a way known issue. The problem is that the Java type system can't
represent this notion that the derived type can make the content model mixed,
meaning strings can suddenly show up between elements in the base class.

Comment by afedoro [ 22/Aug/07 ]

Well, if any type in the inheritance hierarchy has the "mixed" attribute set to
true, I'm assuming that the first derived class having mixed=true in that
hierarchy should have a getContent() accessor, or else some of the XML document
is just impossible to access through JAXB.

Comment by Martin Grebac [ 27/Apr/10 ]

To preserve the inheritance, in RI we introduced generateMixedExtensions switch.
This is a proprietary RI feature for now, spec-wise the solution might be
different in future.

http://blogs.sun.com/mgrebac/entry/handling_extended_mixed_content_in





[JAXB-379] Generated namespace prefixes different to NamespacePrefixMapper for identical prefixes with different URIs Created: 02/Jul/07  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 379

 Description   

I need to produce the following XML document which I believe is valid XML
(according to http://www.w3.org/TR/REC-xml-names/#defaulting):

-------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<BroadsoftDocument protocol="OCI" xmlns="C">
<sessionId xmlns="">12345</sessionId>
<command xsi:type="AuthenticationRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="">
<userId>userId</userId>
</command>
</BroadsoftDocument>
-------------------------------------------------------------------------------------------------------------

When I try to create this document using JAXB 2 or jdk1.6, I get the following:

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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:BroadsoftDocument protocol="OCI" xmlns:ns2="C">
<sessionId>12345</sessionId>
<command xsi:type="AuthenticationRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<userId>userId</userId>
</command>
</ns2:BroadsoftDocument>

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

I understand that the above XML is also valid, however, the server I am working
with does not allow for "ns2" because it looks for "<BroadsoftDocument>" in
order to detect an XML document (and I cannot change server-side implementation)

In JAXB 1, the generated XML was correctly giving me the first message. But
after upgrading to JAXB 2 (to solve other bugs), this problem has come up.
I've looked in the source code, and it seems the JAXB implementation doesn't
like having same prefixes for different namespace URIs as specified by the
NamespacePrefixMapper.

Specifically, I feel that if the NamespacePrefixMapper returns 2 identical
prefixes for different URIs, the implementation should try its best to honor
this mapping, particularly for inner namespace scoping. It should only create
its own prefixes (ns2, etc) if something incorrect is happening...



 Comments   
Comment by Pavel Bucek [ 05/Nov/09 ]
      • Issue 185 has been marked as a duplicate of this issue. ***
Comment by Pavel Bucek [ 05/Nov/09 ]
      • Issue 559 has been marked as a duplicate of this issue. ***
Comment by Pavel Bucek [ 05/Nov/09 ]
      • Issue 710 has been marked as a duplicate of this issue. ***
Comment by Martin Grebac [ 15/Apr/11 ]

increasing priority to better evaluate the needs here





[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-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-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-966] unable to honor this schemaBinding customization (MINIMAL and DIFFERENT behavior of command-line xjc from Ant task xjc) Created: 24/Jun/13  Updated: 24/Jun/13

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

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

JDK 1.7.0_21 * JAXB 2.2.7 * Ubuntu 12.04.2


Tags: jaxb, jaxb-xjc

 Description   

Note: this is related to https://java.net/jira/browse/JAXB-965 but IS not identical. See below.

It is different in two respects: (1) it showcases the same kind of bug but in an absolutely minimal setting (with only three, extra-short, xsd files) (2) it demonstrates that in this particular setting, the Ant xjc task fails but the command-line invocation of xjc succeeds which is unsettling but may provide a hint as to the location of this bug.

Here we have three minimal xsd files where invoking the Ant xjc tasks with episodic compilation fails with "unable to honor this schemaBinding" whereas invoking the xjc tool from the command line succeeds. You can view the failure with:

git clone https://github.com/mperdikeas/unable_to_honor-narrowdown.git && cd unable_to_honor-narrowdown && ant

whereas the invocation of the invoke-xjc-2.2.7 succeeds.

Relevant SO post link: http://stackoverflow.com/questions/17274109/jaxb-compiler-was-unable-to-honor-this-schemabinding-customization






[JAXB-1009] JAXB spec should be updated to support new JDK8 Date/Time apis Created: 01/Apr/14  Updated: 28/Sep/15

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

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


 Comments   
Comment by puce [ 28/Sep/15 ]

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

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

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





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

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

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

Operating System: All
Platform: All


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

 Description   

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



 Comments   
Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=254)
testcase

Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=255)
Updated testcase

Comment by ramapulavarthi [ 08/Jan/09 ]

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

Comment by Pavel Bucek [ 16/Jan/09 ]

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

My code:

SchemaCompiler sc = XJC.createSchemaCompiler();

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

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

S2JJAXBModel model = sc.bind();

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

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

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

Comment by Pavel Bucek [ 04/Mar/09 ]

marking as incomplete

Comment by Pavel Bucek [ 19/Mar/09 ]

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

Comment by ramapulavarthi [ 20/Mar/09 ]

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

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

Comment by ramapulavarthi [ 20/Mar/09 ]

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

Comment by Pavel Bucek [ 24/Mar/09 ]

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

– removing incomplete keyword

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

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

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

Comment by ramapulavarthi [ 24/Mar/09 ]

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

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

Comment by fribeiro [ 14/Apr/09 ]

Any update yet?

Comment by Pavel Bucek [ 16/Apr/09 ]

We have a workaround.

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

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

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

Comment by euxx [ 12/May/09 ]

Is there an update on this?

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

Comment by fribeiro [ 08/Sep/09 ]

Any update yet?

Comment by Martin Grebac [ 11/Sep/09 ]

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

Comment by Martin Grebac [ 17/Sep/09 ]

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

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

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

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

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

Comment by Martin Grebac [ 27/Oct/09 ]

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

Comment by fribeiro [ 02/Nov/09 ]

Thanks for the update.

Comment by fribeiro [ 25/Jan/10 ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 ]

Any update yet?

Comment by marcelcasado [ 24/Nov/11 ]

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

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

I'm also interested for an update on this.

Comment by RyanCarpenter [ 06/Mar/13 ]

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

Comment by Iaroslav Savytskyi [ 07/Mar/13 ]

Hi,

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

Iaroslav

Comment by rcardillo [ 19/Jul/13 ]

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

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

Comment by Michael Osipov [ 25/Feb/14 ]

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

Comment by jahutton [ 14/Mar/14 ]

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

Comment by Michael Osipov [ 14/Mar/14 ]

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

Comment by bdrx [ 10/Nov/14 ]

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

Comment by Michael Osipov [ 10/Nov/14 ]

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





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

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

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

JAXB2.0



 Description   

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

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

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






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

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

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

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


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

 Description   

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

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

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

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



 Comments   
Comment by kohsuke [ 16/Jun/06 ]

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

Comment by vorburger [ 21/Jul/06 ]

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

Comment by kohsuke [ 24/Sep/07 ]

Also in this category is javadoc for enumeration values.

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

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

Comment by Aleksander Adamowski [ 22/Oct/09 ]

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

Comment by dkulp [ 22/Oct/09 ]

This is also the blocker for a CXF issue:

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

Comment by skells [ 26/Oct/09 ]

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

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

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

Comment by dkulp [ 26/Oct/09 ]

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

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

Comment by dkulp [ 11/Feb/10 ]

skells,

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

Comment by kpsdevi [ 11/May/11 ]

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

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

<jaxb:globalBindings typesafeEnumMemberName="generateName">

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

public enum XYZCodeSimpleType {

/**

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

/**

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

/**

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

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

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

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

public enum XYZCodeSimpleType {

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

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

if( mem!=null )

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

So the above code should be modified as given below

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

{ //Fix mdoc = mem.javadoc; }

}

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

Comment by Martin Grebac [ 30/May/11 ]

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

Comment by os111 [ 31/May/11 ]

Not sure why this was closed?

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

For example the following from schema snippet

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

Generates the following javadoc:

/**

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

The javadoc should also include the schema's documentation.

Comment by vorburger [ 01/Jun/11 ]

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

Comment by Martin Grebac [ 01/Jun/11 ]

Understood, thanks for the clarifications here.

Comment by marcelstoer [ 20/Oct/13 ]

Just found here thanks to a really helpful SO answer.

Comment by kwakeroni [ 12/Mar/15 ]

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

Comment by duncant [ 16/Nov/15 ]

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





[JAXB-362] using JAXB (schemagen) with javax.vecmath.Point3d Created: 18/May/07  Updated: 18/May/07

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.0 FCS
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: abedhammoud Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 362

 Description   

hello,

Basically, my object has a Point3d from the Java3d library. When compiling the
code below with schemagen I get an error that the class has two properties of
each of the (x, y, z) elements of the Point3d class.

Related threads:

http://forums.java.net/jive/thread.jspa?threadID=25820&tstart=15

http://forums.java.net/jive/thread.jspa?threadID=20202&tstart=45

------------------CODE-----------------

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

/**

  • Point3d test
    *
    *
    */

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

{"comment","point"}

)
class Point3dTest

{ @XmlElement(name="comment") private String comment; @XmlElement(name="point") private javax.vecmath.Point3d point; }




[JAXB-357] Inconsistency in code generation for IDREFS caused by collectionType option in globalBindings Created: 04/May/07  Updated: 18/May/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 357

 Description   

Inconsistency in code generation for IDREFS caused by collectionType option in
globalBindings:

If collectionType option is included in xjb

<jxb:globalBindings collectionType="java.util.LinkedList"

then generated code will look like:

//snip...
@XmlAttribute(namespace = "http://niem.gov/niem/structures/1.0")
@XmlIDREF
@XmlSchemaType(name = "IDREFS")
protected List<Object> linkMetadata = new LinkedList<Object>();
//snip...
public List<Object> getMetadata() {
if (metadata == null)

{ metadata = new LinkedList<Object>(); }

return this.metadata;
}

If collectionType is not specified then code will default to ArrayList and will
look like this:

//snip...
@XmlAttribute(namespace = "http://niem.gov/niem/structures/1.0")
@XmlIDREF
@XmlSchemaType(name = "IDREFS")
protected List<Object> linkMetadata;
//snip...
public List<Object> getLinkMetadata() {
if (linkMetadata == null)

{ linkMetadata = new ArrayList<Object>(); }

return this.linkMetadata;
}
//snip...

The problem is in the following code:
protected List<Object> linkMetadata = new LinkedList<Object>();
While this looks correct from the first glance in reality it causes the problem
for IDREFS:
if in the original xml element/attribute does not exist it is initialized
anyway and upon marshalling will result in empty value string - "" which is
invalid according to XML schema:

<!-- snip -->
<attribute name="linkMetadata" type="IDREFS"/>
<complexType name="ComplexObjectType">
<attribute ref="s:linkMetadata"/>
</complexType>
<element name="foo" type="s:ComplexObjectType"/>
<!-- snip -->

Original xml:
<foo />

Output xml:
<foo s:linkMetadata="" />

s:linkMetadata="" where s:linkMetadata is of IDREFS is invalid according to XML
schema.



 Comments   
Comment by kohsuke [ 16/May/07 ]

I guess this is a spec bug, in the sense that these two features interact in an
unexpected way.

I don't see how we can make this work, so most likely the resolution would be to
prevent collectionType from taking effect on IDREFS, or something along that line.

Comment by basdebakker14 [ 12/Apr/11 ]

The same issue exists with attributes of type NMTOKENS.

Comment by gb96 [ 18/May/12 ]

This problem actually has nothing to do with the collectionType option!

Invalid empty attribute string "" is generated regardless of collectionType.

You can fix the problem by detecting the empty collections and replacing them with nulls prior to or during marshalling, however you need to use either Reflection or a Collection-Setter-Injector XJC plugin to be able to set a collection field value to null.





[JAXB-336] allow xjc to find schemas in jars Created: 19/Mar/07  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JAXB-339 Add some way to specify where externa... Resolved
Issuezilla Id: 336

 Description   

When compiling schemas separately in different places, it would be nice to be
able to provide base schemas in a jar along with their associated episode files,
so that the individual schema files don't have to be dragged around everywhere
they are used.

Please see http://forums.java.net/jive/thread.jspa?threadID=24173&tstart=0 for
context.



 Comments   
Comment by dlaprade [ 26/Sep/08 ]

I would like to see this enhancement added. What I would like to see is the
ability to search the classpath for files when using the xml-catalog:

<rewriteURI rewritePrefix="classpath:some.xsd"
uriStartString="http://www.example.com/some.xsd"/>

Comment by dlaprade [ 10/Oct/08 ]

Having this issue fixed would help all tools and projects that use xjc for
generation.

Comment by fribeiro [ 08/Sep/09 ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 ]

Any update yet?





[JAXB-325] Different types for generated getters and setters Created: 16/Feb/07  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Attachments: Text File patch.txt    
Issuezilla Id: 325

 Description   

See forum posting at http://forums.java.net/jive/thread.jspa?messageID=204042
for a description of the problem.

Sample bindings file:

<jxb:bindings version="1.0"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jxb:bindings schemaLocation="test.xsd" node="/xs:schema">
<jxb:globalBindings optionalProperty="wrapper">
<jxb:javaType name="java.lang.Float" xmlType="xs:float"/>
</jxb:globalBindings>
</jxb:bindings>
</jxb:bindings>

Sample XML schema:

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

<xsd:complexType name="MyTestType">
<xsd:attribute name="floatAttribute" type="xsd:float" default="1.0"/>
</xsd:complexType>

</xsd:schema>

Generated method on MyTestType class is:

public float getFloatAttribute() {
if (floatAttribute == null)

{ return new Adapter1().unmarshal("1.0"); }

else

{ return floatAttribute; }

}

When the attribute has a default value, neither the global type mapping
xsd:float<->java.lang.Float nor the optionalProperty="wrapper" setting will
result in the method return type being set to java.lang.Float.

The use case is to introspect the generated classes as Java beans. The different
types on the getter and setter make this impossible.



 Comments   
Comment by kohsuke [ 21/Feb/07 ]

See
http://www.nabble.com/JAXB%2C-Introspector%2C-BeanInfo-and-method-sigantures-tf1632437.html

Changing to RFE as this behavior is not in violation of the spec.

Comment by dean_jones [ 03/Mar/07 ]

Created an attachment (id=168)
Patch for bug

Comment by dean_jones [ 03/Mar/07 ]

In the interests of getting this bug fixed, I've attached a patch.

Incidentally, I was surprised to see this bug re-classified from defect to RFE.
I might be missing something, but the observed behaviour seems to violate the
spec, specifically sec 7.9.1.1: "The javaType, if specified, is the Java
datatype to which xmlType is to be bound." [on reading the spec, the
'optionalProperty' setting seems to be a red herring as this is only for use
with optional elements/attributes, and I don't suppose an attribute with a
default value counts as optional.]

Now, sec 7.9.1.1 could, I suppose, be referring to the type of the generated
field, rather than the correponding getter, but that would be odd since the type
of the field is pretty much irrelevant - it's the type returned/accepted by the
corresponding getter/setter that clients of the generated classes use, and which
is therefore important.





[JAXB-295] no annotation for fixed or default attributes Created: 20/Dec/06  Updated: 11/Jan/11

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

Type: Improvement Priority: Major
Reporter: rieman4d Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 295

 Description   

The attribute element has an option for a fixed or default value, using
the "fixed" or "deafult" option, which works fine. However, the xjc compiler
does not add any annotation information regarding the fixed or default option.

I recommend an xjc enhancement to add the fixed or default option into the
annotation, so that an application can know which fields are fixed or default
by reading the annotations.






[JAXB-290] xjc makes all sub-elements JAXBElement to easily for unbounded choice Created: 14/Dec/06  Updated: 11/Jan/11

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

Type: Improvement Priority: Major
Reporter: cezimmerman Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 290

 Description   

The code generated for the unbounded choice appears to be less useful than it
could be in some circumstances. The following schema demonstrates an example of
this problem:

<xsd:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xs:element name="Root">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="Boolean1" type="xs:boolean"/>
<xs:element name="Boolean2" type="xs:boolean"/>
<xs:element name="Parameter">
<xs:complexType>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="value" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xsd:schema>

The code generated for this is in part:

public class Root {

@XmlElementRefs(

{ @XmlElementRef(name = "Boolean2", type = JAXBElement.class), @XmlElementRef(name = "Boolean1", type = JAXBElement.class), @XmlElementRef(name = "Parameter", type = JAXBElement.class) }

)
protected List<JAXBElement<?>> boolean1OrBoolean2OrParameter;

Instead I would have preferred:

public class Root {

@XmlElementRefs(

{ @XmlElementRef(name = "Boolean2", type = JAXBElement.class), @XmlElementRef(name = "Boolean1", type = JAXBElement.class), @XmlElementRef(name = "Parameter", type = Root.Parameter.class) }

)
protected List<Object> boolean1OrBoolean2OrParameter;

If there was only a single boolean then the generated code would have been:

public class Root {

@XmlElementRefs(

{ @XmlElementRef(name = "Boolean2", type = Boolean.class), @XmlElementRef(name = "Parameter", type = Root.Parameter.class) }

)
protected List<Object> boolean1OrParameter;

I understand that when it is not possible to tell the element by its type that
it is necessary to wrap the value in a JAXBElement. It just seems that you may
have gone too far in wrapping all of the elements in this kind of a choice case
if there is a problem differentiating between some of them. This is
particularly egregious for complex types because the ObjectFactory.create method
has to be called twice, once to produce the type class and then again to produce
the JAXBElement version of it.



 Comments   
Comment by cezimmerman [ 14/Dec/06 ]

should have been an Enhacement request





[JAXB-279] allow XmlJavaTypeAdapter on entire Collection Created: 14/Nov/06  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 279

 Description   

Please consider allowing XmlJavaTypeAdapter / XmlAdapter to apply to an entire
Collection, not just to individual items inside a Collection. For example:

class Foo {

@XmlJavaTypeAdapter(value=MyListAdapter.class, type=List.class)
private List<Bar> bars;
}

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

Or in package-info.java:

@XmlJavaTypeAdapters(

{ @XmlJavaTypeAdapter(value=MyCollectionAdapter.class, type=Collection.class), @XmlJavaTypeAdapter(value=MySetAdapter.class, type=Set.class), @XmlJavaTypeAdapter(value=MyListAdapter.class, type=List.class)}

)
package com.mycompany.foo;

import java.util.Collection;
import java.util.List;
import java.util.Set;

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

class MyListAdapter extends XmlAdapter<List, List> {

@Override
public List marshal(List v) throws Exception

{ List result = new ArrayList(v); // manipulate the list; maybe filter some elements return result; }

@Override
public List unmarshal(List v) throws Exception

{ // do something with the list return v; }

}






[JAXB-276] Binder and dom customization Created: 08/Nov/06  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 276
Tags: incomplete

 Description   

Some of my Java interfaces return DOM objects as the result of anyType wildcard
mapping or DOM customization.

If I'm unmarshalling with Binder from a DOM document instance then it would be
very nice if the returned DOM objects belonged to the original DOM document
instance.

See also
https://jaxb.dev.java.net/servlets/ReadMsg?list=users&msgNo=6171



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

Would you have a testcase for this? Unfortunately the list links are broken after migration.





[JAXB-275] JABXContext bootstrap performance improvement Created: 07/Nov/06  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Attachments: File jaxb2-ri-20061109.nps     File jaxbperf-fastboot-20061109.nps     File jaxbperf.nps    
Issuezilla Id: 275

 Description   

In certain usage of JAXB, it's more desirable to create JAXBContext more
quickly, as opposed to making the unmarshalling/marshalling faster.

This task attempts to capture various activities around this effort.



 Comments   
Comment by kohsuke [ 08/Nov/06 ]

Created an attachment (id=144)
Initial profile result contributed by Eric Crampton. This is the base line.

Comment by ericcrampton [ 09/Nov/06 ]

Created an attachment (id=145)
fastBoot property used with 20061109 nightly build; NetBeans profiler output

Comment by skaffman [ 09/Nov/06 ]

Created an attachment (id=146)
Netbeans profiler snapshot on JAXBContext.newInstance() with 20061109 build





[JAXB-272] allow @XmlElementWrapper on any property Created: 30/Oct/06  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 272

 Description   

Currently, @XmlElementWrapper is only allowed on Collection properties. It
would be useful to allow this annotation on any property to supported nested XML
that doesn't necessarily make sense in the object model. For example:

@XmlElementWrapper(name="sessionTimeout")
@XmlElement(name="seconds")
private Seconds sessionTimeout;

To produce:

<sessionTimeout><seconds>60</seconds></sessionTimeout>



 Comments   
Comment by kohsuke [ 03/Nov/06 ]

Agreed this is useful. But it's a spec feature.





[JAXB-270] fixed attribute value not used when using restriction inheritance Created: 26/Oct/06  Updated: 13/Nov/06

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

Type: Improvement Priority: Major
Reporter: sebastiankirsch Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 270

 Description   

If a complex type with one attribute is inherited by restriction and in the
inheriting element we define a fixed value for that attribute, the JAXB bean
returns null for it except we set it explicitly.

In my eyes this is a bug, as the JAXB bean should always return the fixed value.

I've created some test files, but it seems like I can't upload them, so I just
paste my files in here:

----------------------------------------------------------
– XSD file ----------------------------------------------
----------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:core="http://paybox.net/xml/schema/core"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://paybox.net/xml/schema/core"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb" jxb:version="2.0">
<xs:annotation>
<xs:appinfo>
<jxb:schemaBindings>
<jxb:package name="net.paybox.mobiliser.jaxb" />
</jxb:schemaBindings>
</xs:appinfo>
</xs:annotation>

<xsd:simpleType name="IdentifierType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="id" />
<xsd:enumeration value="imei" />
<xsd:enumeration value="msisdn" />
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="Identifier">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="type" use="optional"
type="core:IdentifierType" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="IdIdentifier">
<xsd:simpleContent>
<xsd:restriction base="core:Identifier">
<xsd:pattern value="\d

{1,12}

" />
<xsd:attribute fixed="id" name="type"
type="core:IdentifierType" />
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="BaseCustomer">
<xsd:sequence>
<xsd:element name="Identification" type="core:Identifier" />
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="Merchant">
<xsd:complexContent>
<xsd:restriction base="core:BaseCustomer">
<xsd:sequence>
<xsd:element name="Identification"
type="core:IdIdentifier">
</xsd:element>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>

<xsd:element name="Root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Recipient" type="core:BaseCustomer" />
<xsd:element name="Seller" type="core:Merchant" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

</xsd:schema>

----------------------------------------------------------
– XML file ----------------------------------------------
----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<core:Root xmlns:core="http://paybox.net/xml/schema/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://paybox.net/xml/schema/core bugReport.xsd ">
<Recipient>
<Identification type="msisdn">+1781807531</Identification>
</Recipient>
<Seller>
<Identification>123456789012</Identification>
</Seller>
</core:Root>

----------------------------------------------------------
– JUnit -------------------------------------------------
----------------------------------------------------------
import java.io.File;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import javax.xml.validation.SchemaFactory;

import net.paybox.mobiliser.jaxb.Root;

import org.junit.Assert;
import org.junit.BeforeClass;
import org.junit.Test;
import org.xml.sax.SAXException;

public class TestJaxb {

private static Unmarshaller unMarshal;

@BeforeClass
public static void init() throws JAXBException, SAXException

{ unMarshal = JAXBContext.newInstance("net.paybox.mobiliser.jaxb") .createUnmarshaller(); unMarshal.setSchema(SchemaFactory.newInstance( "http://www.w3.org/2001/XMLSchema").newSchema( new File("bugReport.xsd"))); }

@Test
public void parse() throws JAXBException

{ Root root = (Root) unMarshal.unmarshal(new File("bugReport.xml")); Assert.assertNotNull(root.getRecipient().getIdentification().getType()); Assert.assertNotNull(root.getSeller().getIdentification().getType()); }

}



 Comments   
Comment by kohsuke [ 13/Nov/06 ]

I believe the current behavior is in accordance with the spec.

I agree with you that the behavior you are describing would make a lot of sense,
and such behavior is certainly worth considering for vendor extensions. It's
just that there are so many ways to restrict a content model, and have the
compiler recognize those correctly would be a non-trivial work.

Comment by kohsuke [ 13/Nov/06 ]

Since this is not a "bug" in the sense of spec violation, I'm changing it to
ENHANCEMENT.





[JAXB-273] Java annotations to generate xsd documentation/appinfo elms Created: 01/Nov/06  Updated: 06/Jan/15

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

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

Operating System: All
Platform: Macintosh


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

 Description   

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

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

@XsdAppInfo( value="blah" )

The xsd should have a complex type definition:

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

...

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



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

The opposite is in issue JAXB-460.

Comment by lisa_winkler [ 13/Jun/12 ]

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

Comment by lennartj [ 25/Dec/14 ]

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

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

Basically, I would expect

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

To have the following generated

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

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

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

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

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

Comment by lennartj [ 25/Dec/14 ]

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

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

I believe this implies two things:

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

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

Comment by Dennis Kieselhorst [ 29/Dec/14 ]

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

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

Comment by lennartj [ 06/Jan/15 ]

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

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





[JAXB-265] ClassResolver support for marshaller Created: 18/Oct/06  Updated: 11/Jan/11

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

Type: Improvement Priority: Major
Reporter: flickerlight Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 265

 Description   

The sample source code in JAXB 2.1 contains an example of how to use DI to
unmarshal an XML (class-resolver). An example is needed to show how XML would
be marshalled using DI.

Thanks



 Comments   
Comment by kohsuke [ 24/Oct/06 ]

Changing the title to describe the feature better.





[JAXB-251] Getter and Setter can't be in different class in the hierarchy Created: 25/Sep/06  Updated: 30/Jan/12

Status: Reopened
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1
Fix Version/s: 2.1.3

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

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=18616&tstart=0


Issuezilla Id: 251

 Description   

The problem Im having is that JAXB doesnt recognize a setter for a property if
the setter parameter is a not exactly of the same as the parameter of the getter
but rather a "parent-class".

for Example, when i have the following classes:

class A{
}

class B extends A{
A parent;
void setParent(A parent)

{...}
abstract A getParent();

}

class C extends B{
@XMLIDREF
B getParent(){...}

}

JAXB doesnt recognize the setter inside A as the right setter for "parent".

After going over the JAXB source code i found that the cause is that
ClassInfoImpl.collectGetterSetters() method has the following code:

=========================
for (M setter : propSetters) {
T setterType = nav().getMethodParameters(setter)[0];
if (setterType.equals(getterType)) {
setters.put(propName, setter);
break;
}
}
========================
Since setterType.equals(getterType)==false, JAXB wont find setParent() as a setter.



 Comments   
Comment by kohsuke [ 13/Nov/06 ]

I think this issue has been fixed some time ago.

Comment by mosh [ 14/Nov/06 ]

I dont think so. At leat not with the version from 18/10/2006.
Look at the the following code at ClassInfoImp.java:

// Match getter with setters by comparing getter return type to setter param
for (Map.Entry<String,M> entry : getters.entrySet()) {
String propName = entry.getKey();
M getter = entry.getValue();
List<M> propSetters = allSetters.remove(propName);
if (null == propSetters)

{ //no matching setter continue; }

allSetters is only from this class and not from its super-classes (unless the
super-class is @XmlTransient).

I've created a function that also seeks for setters in the super-class.
I can submit it as a patch. What is the procedure?

Thanks!
Mosh

////////////////////////////////////
// This is the method BTW:

List<M> findSetterInSuperClass(C c, String propName){
List<M> propSetters = null;

Collection<? extends M> methods = nav().getDeclaredMethods(c);
for( M method : methods ) {
if(nav().isBridgeMethod(method))
continue; // ignore

String name = nav().getMethodName(method);
int arity = nav().getMethodParameters(method).length;

// TODO - is needed????
if(nav().isStaticMethod(method))

{ ensureNoAnnotation(method); continue; }

// is this a set method?
String propNameFromSetter = getPropertyNameFromSetMethod(name);
if(propNameFromSetter!=null && arity==1) {
if(propNameFromSetter.equals(propName)){
if(propSetters == null)

{ propSetters = new ArrayList<M>(); }

propSetters.add(method);
}
}
}

if(propSetters != null)

{ return propSetters; }

else

{ // If we havent found the getter - going up to its super-class C sc = nav().getSuperClass(c); if((sc==null) || (sc==Object.class)) return null; else return findSetterInSuperClass(sc,propName); }

}

Comment by kohsuke [ 08/Dec/06 ]

Yes, if you can provide us a patch, that would be great!

See https://glassfish.dev.java.net/public/GovernancePolicy.html#SCA_Policy and
please send us the SCA so that we can accept a patch. Otherwise, just go create
a patch and post the diff to the issue please.

You'll only need to make sure that the patch will work for you. We'll run it
through the tests on our side as well.

Comment by rebeccas [ 02/Feb/07 ]

Implementation complete.

Comment by desruisseaux [ 21/Oct/11 ]

Is this improvement really done? I tried the following code snippet. It work well if the argument type of the setValue method is Double, but doesn't work anymore if I relax it to Number:

import java.io.*;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.annotation.*;

@XmlRootElement
public class SetterWithParentClass {
    private double value;

    @XmlElement
    public Double getValue() {
        return value;
    }

    // Argument type should be Double - testing with a relaxed type.
    public void setValue(Number n) {
        value = n.doubleValue();
    }

    public static void main(String[] args) throws Exception {
        JAXBContext c = JAXBContext.newInstance(SetterWithParentClass.class);
        SetterWithParentClass test = new SetterWithParentClass();
        test.value = 3;
        StringWriter out = new StringWriter();
        c.createMarshaller().marshal(test, out);
        String xml = out.toString();
        System.out.println(xml);

        // Unmarshall
        StringReader in = new StringReader(xml);
        test = (SetterWithParentClass) c.createUnmarshaller().unmarshal(in);
        System.out.println("value = " + test.value);
    }
}

Output is (adding indentation for clarity):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<setterWithParentClass>
  <value>3.0</value>
</setterWithParentClass>

value = 0.0

I would have hopped a value of 3.0, as we get when the setter method is setValue(Double).

Comment by Iaroslav Savytskyi [ 30/Jan/12 ]

I think this is not a valid issue.

If JAXB is working with JavaBeans-style classes its expected that properties should have getters and setters of the same type. Which is not true in this case.

Comment by desruisseaux [ 30/Jan/12 ]

This issue is not incompatible with JavaBeans-style classes. It is a relaxed interpretation - not everyone want the JavaBeans constraints. In my case, I have about 100 classes derived from the ISO 19115 international standard, and I would like to design the API for ease of use rather than JAXB constraints. In its current form, the API forces the users to perform themselves a lot of wrapping toward some specialized interfaces (InternationalString - which is specific to the project) while the setters could accept a more generic interface (CharSequence - which would allow the users to specify a plain String) and do the wrapping themselves.

If the JavaBeans restriction is still considered necessary, some annotation allowing us to specify that a method is the setter of a property would be appreciated. Maybe we could reuse the current @Element annotation, which would be allowed to be applied to setter methods.

An alternative is to declare setter methods twice: one JavaBeans-compliant method and one convenience method. But this approach bloat the API and binary file for few purpose. I currently don't do that since I think it would bloat too much a collection of classes of the size of ISO 19115.





[JAXB-253] DTD namespace is all-or-nothing Created: 27/Sep/06  Updated: 08/Nov/06

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: JWSDP1.6 (JAXB1.0.5)
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: rshan Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 253

 Description   

Given the following DTD:

<!ELEMENT TEST (SUB_TEST*, Signature?)>
<!ELEMENT SUB_TEST EMPTY>
<!ENTITY % signature.dtd SYSTEM "signature.dtd">
%signature.dtd;

And the included signature.dtd:

<!ENTITY % Object.ANY ''>
<!ENTITY % Method.ANY ''>
<!ENTITY % Transform.ANY ''>
<!ENTITY % SignatureProperty.ANY ''>
<!ENTITY % KeyInfo.ANY ''>
<!ENTITY % KeyValue.ANY ''>
<!ENTITY % PGPData.ANY ''>
<!ENTITY % X509Data.ANY ''>
<!ENTITY % SPKIData.ANY ''>

<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)>
<!ATTLIST Signature
xmlns CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"
Id ID #IMPLIED
>

<!ELEMENT SignatureValue (#PCDATA)>
<!ATTLIST SignatureValue
Id ID #IMPLIED
>
<!ELEMENT SignedInfo (CanonicalizationMethod, SignatureMethod, Reference+)>
<!ATTLIST SignedInfo
Id ID #IMPLIED
>
<!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY* >
<!ATTLIST CanonicalizationMethod
Algorithm CDATA #REQUIRED
>
<!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY* >
<!ATTLIST SignatureMethod
Algorithm CDATA #REQUIRED
>
<!ELEMENT Reference (Transforms?, DigestMethod, DigestValue)>
<!ATTLIST Reference
Id ID #IMPLIED
URI CDATA #IMPLIED
Type CDATA #IMPLIED
>
<!ELEMENT Transforms (Transform+)>
<!ELEMENT Transform (#PCDATA|XPath %Transform.ANY* >
<!ATTLIST Transform
Algorithm CDATA #REQUIRED
>
<!ELEMENT XPath (#PCDATA)>
<!ELEMENT DigestMethod (#PCDATA %Method.ANY* >
<!ATTLIST DigestMethod
Algorithm CDATA #REQUIRED
>
<!ELEMENT DigestValue (#PCDATA)>
<!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY* >
<!ATTLIST KeyInfo
Id ID #IMPLIED
>
<!-- Key Information -->
<!ELEMENT KeyName (#PCDATA)>
<!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY* >
<!ELEMENT MgmtData (#PCDATA)>
<!ELEMENT RetrievalMethod (Transforms?)>
<!ATTLIST RetrievalMethod
URI CDATA #REQUIRED
Type CDATA #IMPLIED
>
<!-- X.509 Data -->
<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
X509Certificate | X509CRL )+ %X509Data.ANY>
<!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber)>
<!ELEMENT X509IssuerName (#PCDATA)>
<!ELEMENT X509SubjectName (#PCDATA)>
<!ELEMENT X509SerialNumber (#PCDATA)>
<!ELEMENT X509SKI (#PCDATA)>
<!ELEMENT X509Certificate (#PCDATA)>
<!ELEMENT X509CRL (#PCDATA)>
<!-- PGPData -->
<!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY >
<!ELEMENT PGPKeyPacket (#PCDATA)>
<!ELEMENT PGPKeyID (#PCDATA)>
<!-- SPKI Data -->
<!ELEMENT SPKIData (SPKISexp %SPKIData.ANY >
<!ELEMENT SPKISexp (#PCDATA)>
<!-- Extensible Content -->
<!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY* >
<!ATTLIST Object
Id ID #IMPLIED
MimeType CDATA #IMPLIED
Encoding CDATA #IMPLIED
>
<!ELEMENT Manifest (Reference+)>
<!ATTLIST Manifest
Id ID #IMPLIED
>
<!ELEMENT SignatureProperties (SignatureProperty+)>
<!ATTLIST SignatureProperties
Id ID #IMPLIED
>

<!ELEMENT DateTimeStamp EMPTY>
<!ATTLIST DateTimeStamp DateTime CDATA #REQUIRED>

<!ELEMENT SignatureProperty (#PCDATA| DateTimeStamp %SignatureProperty.ANY* >
<!ATTLIST SignatureProperty
Target CDATA #REQUIRED
Id ID #IMPLIED
>

<!-- Algorithm Parameters -->
<!ELEMENT HMACOutputLength (#PCDATA)>
<!ELEMENT DSAKeyValue ((P, Q)?, G?, Y, J?, (Seed, PgenCounter)?)>
<!ELEMENT P (#PCDATA)>
<!ELEMENT Q (#PCDATA)>
<!ELEMENT G (#PCDATA)>
<!ELEMENT Y (#PCDATA)>
<!ELEMENT J (#PCDATA)>
<!ELEMENT Seed (#PCDATA)>
<!ELEMENT PgenCounter (#PCDATA)>
<!ELEMENT RSAKeyValue (Modulus, Exponent)>
<!ELEMENT Modulus (#PCDATA)>
<!ELEMENT Exponent (#PCDATA)>

And the sample XML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE TEST PUBLIC "" "test.dtd">
<TEST>
<SUB_TEST/>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" Id="_1">
<SignedInfo>
<CanonicalizationMethod Algorithm="" />
<SignatureMethod Algorithm="" />
<Reference>
<DigestMethod Algorithm="" />
<DigestValue />
</Reference>
</SignedInfo>
<SignatureValue />
</Signature>
</TEST>

xjc produces code that fails to unmarshall the above XML, reporting that it
expects to find a root TEST with namespace URI "http://www.w3.org/2000/09/xmldsig#"

Removing the xmlns attribute from the Signature element (in signature.dtd)
results in code that will marshall and unmarshall without error, but also has
the effect of stripping the xmlns attribute from the Signature element, which
breaks signature verification.



 Comments   
Comment by kohsuke [ 27/Sep/06 ]

DTD and namespaces really don't work well, so I think some kind of heuristic
like what XJC does today is needed.

Do you have some suggestions as to how to make this work?

One dumb approach is to let you specify what element is supposed to be in what
namespace, maybe in a property file or something.

Comment by rshan [ 28/Sep/06 ]

How about allowing disablement of dtd namespace support so that 'xmlns' is
simply treated as an attribute?

Comment by kohsuke [ 29/Sep/06 ]

That requires the runtime to be aware of such mode, as well as some annotations
to communicate to the runtime that these classes are supposed to be
namespace-unaware.

No, that's not going to work. It's just too expensive.

Comment by kohsuke [ 08/Nov/06 ]

Reclassifying as this is an enhancement request.





[JAXB-234] Infer generic components for XmlAdapter Created: 02/Sep/06  Updated: 02/Sep/06

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

Type: Improvement Priority: Major
Reporter: sbalmos Assignee: jaxb-issues
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 234

 Description   

As discussed in http://forums.java.net/jive/thread.jspa?threadID=17972 .

XmlAdapter should be extended to support inference of the component types of the
type it is annotated on. This would allow for creation of a single generic
XmlAdapter, instead of creating separate XmlAdapters for each different set of
component types. This most directly affects users of Map types to emulate Map
functionality over SOAP.

e.g. instead of creating separate XmlAdapters for each different key-value type
pair, one could create:

public class MapAdapter<K,V> extends XmlAdapter<MapEntity<K,V>[], Map<K,V>>

where MapEntity is a simple user class, consisting of a generic key and value field.

This sort of functionality could be further integrated to automatically make use
of the MapEntity class (which I would be happy to provide, even though it's
dead-simple) whenever a Map type is encountered. This would bring JAXB more in
line with the existing vendor-specific SOAP Map functionality extensions that
Axis2, PHP 5, and other utilize (they all, at last look, generally convert their
map types into similar arrays of key-value entities).






[JAXB-223] JAXB doesn't support collection classes as top level objects Created: 16/Aug/06  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 223

 Description   

JAXB 2.0 has no provision of handling any collection class as a top-level
object. It can only handle them as properties of beans. To use jax-ws without
the need for wrapper classes for collections, jaxb needs to support this.

Scenario:
If you try to build a webservice with JAX-WS 2.0 and use a collection class in a
service method directly, the generated schema is useless.

Example:

@WebService
@SOAPBinding(style = Style.RPC)
public class CollectionAsParamTestService
{
public void testCollections(ArrayList<String> stringList)
{

}
}

If I generate the wsdl and the corresponding schema with wsgen, the wsdl is
generated with the following message fragment:

<message name="testCollections">
<part name="arg0" type="tns:arrayList"/>
</message>

So far so good. Now the generated schema:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema version="1.0"
targetNamespace="http://impl.service.webservice.fss.portal.o2.com/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="arrayList">
<xs:complexContent>
<xs:extension base="ns1:abstractList"
xmlns:ns1="http://impl.service.webservice.fss.portal.o2.com/">
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="abstractList" abstract="true">
<xs:complexContent>
<xs:extension base="ns2:abstractCollection"
xmlns:ns2="http://impl.service.webservice.fss.portal.o2.com/">
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="abstractCollection" abstract="true"/>
</xs:schema>

So the xsd:string is missing inside the xs:sequence from the service call.

See also https://jax-ws.dev.java.net/issues/show_bug.cgi?id=28



 Comments   
Comment by kohsuke [ 16/Aug/06 ]

This is a spec issue.





[JAXB-149] xjc can't handle the restriction complext type Created: 17/Apr/06  Updated: 12/Apr/11

Status: Open
Project: jaxb
Component/s: spec
Affects Version/s: 2.0 EA1
Fix Version/s: 2.3

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

Operating System: All
Platform: All


Attachments: Zip Archive broken.zip    
Issuezilla Id: 149

 Description   

Hi,

We are Celtix team[1], and we are using JAXB 2.0 EA3.
But with the attached testcase, we have the following errors throwed from
JAXB RI.

[java] Parsing schema error:
[java] org.xml.sax.SAXParseException: Base complex type "RestrictedCard" is
derived by restriction, while this complex type "
ard" is derived by extension. This is not currently handled by XJC, but we are
seeking input on this issue. Please report this to
the JAXB team.
[java] Error : An rpc-literal binding in a DESCRIPTION MUST refer, in its
soapbind:body element(s), only to wsdl:part element
s) that have been defined using the type attribute.

[java] An rpc-literal binding in a DESCRIPTION MUST refer, in its
soapbind:body element(s), only to wsdl:part element(s) that
have been defined using the type attribute.

Any help will be appreciate.

[1] http://celtix.objectweb.org/

Thanks,
James.



 Comments   
Comment by maomaode [ 17/Apr/06 ]

Created an attachment (id=91)
test case which have problem

Comment by kohsuke [ 04/May/06 ]

The underlying problem is that this schema types in the following way:

typeX (a,b,c,d) -> typeY by-restriction (a,d) -> typeZ by-extension (a,d,c')

where c is

<xs:element name="PhysicalPort" type="SIDBusRe:PhysicalPort" ... />

and c' is

<xs:element name="PhysicalPort" type="vodTs:Port" ... />

So this can't be just bound like what the spec says, which will produce
things in a wrong order (a,c',d) with unnecessary @xsi:type

Hmm...

Comment by kohsuke [ 07/Dec/06 ]

This requires a spec level attention and thus can't be fixed in 2.1.





[JAXB-134] Schema generation dies on subclasses of java.util.Date Created: 17/Mar/06  Updated: 12/Apr/11

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

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

Operating System: All
Platform: PC


Attachments: Zip Archive test.zip    
Issuezilla Id: 134
Tags: as911na

 Description   

When a subclass of java.util.Date has to be mapped to XML, apt dies in round 2
with the following error:

[apt] Problem encountered during annotation processing;
[apt] see stacktrace below for more information.
[apt] java.lang.ClassCastException:
com.sun.xml.bind.v2.model.impl.BuiltinLeafInfoImpl
[apt] at
com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getBaseClass(ClassInfoImpl.java:170)
[apt] at
com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:142)
[apt] at
com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:189)
[apt] at
com.sun.xml.bind.v2.model.impl.TypeRefImpl.calcRef(TypeRefImpl.java:56)
[apt] at
com.sun.xml.bind.v2.model.impl.TypeRefImpl.getTarget(TypeRefImpl.java:33)
[apt] at
com.sun.xml.bind.v2.model.impl.ElementPropertyInfoImpl$1.get(ElementPropertyInfoImpl.java:38)
[apt] at
com.sun.xml.bind.v2.model.impl.ElementPropertyInfoImpl$1.get(ElementPropertyInfoImpl.java:41)
[apt] at java.util.AbstractList$Itr.next(Unknown Source)
[apt] at
com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:139)
[apt] at
com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:189)
[apt] at
com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:204)
[apt] at
com.sun.tools.xjc.api.impl.j2s.JavaCompilerImpl.bind(JavaCompilerImpl.java:54)
[apt] at
com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.completeModel(WebServiceAP.java:395)
[apt] at
com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.process(WebServiceAP.java:236)
[apt] at
com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:60)
[apt] at com.sun.tools.apt.comp.Apt.main(Apt.java:450)
[apt] at
com.sun.tools.apt.main.JavaCompiler.compile(JavaCompiler.java:458)
[apt] at com.sun.tools.apt.main.Main.compile(Main.java:1075)
[apt] at com.sun.tools.apt.main.Main.compile(Main.java:938)
[apt] at com.sun.tools.apt.Main.processing(Main.java:95)
[apt] at com.sun.tools.apt.Main.process(Main.java:43)
[apt] at com.sun.tools.apt.Main.main(Main.java:34)

The following class definitions should reproduce the error:

========== test/DateTime.java ==========
package test;

import java.util.Date;

public class DateTime extends Date {
public DateTime() {}
}

========== test/Svc.java ==========
package test;

import javax.jws.*;

@WebService public class Svc {
@WebMethod public DateTime getDateTime()

{ return null; }

}



 Comments   
Comment by dtenev [ 17/Mar/06 ]

Created an attachment (id=84)
Test case

Comment by kohsuke [ 31/May/06 ]

Besides the lack of gracefull error handling in XJC, this is fundamentally a
spec-level issue. It talks about how to handle an user bean that extends from
another user bean, but it doesn't have a notion of how to handle an user bean
extending from a built-in class.

To fix the spec, I'd like to better understand what the use case is. I never saw
anyone extending java.util.Date class. What do you do this for? What is the XML
representation that you expect?

Comment by dtenev [ 01/Jun/06 ]

The use-case is simple: a class is needed that is (locally)
assignment-compatible with java.util.Date, with a bit of extra functionality on
top of it. The extra functionality in question does not expose anything that
qualifies as a bean field or property, so ultimately the sub-class should be
visible as Date, with the only difference that values of the corresponding
schema type must be mapped to and from instances of the sub-class.

I am starting to see the trouble with handling extensions of special classes
like Date in the presence of visible properties in the subclasses, but I believe
that the case of purely functional extensions should be easy to handle. In the
case of structural extensions (i.e. such that add structure in the way of
visible bean properties or fields,) it would still make perfect sense to issue a
clear warning or error message to the effect that the mapping is undefined. Of
course, mapping such classes through custom adapters should still be possible.

Let me just point out that the notion of a "user bean extending from a built-in
class" sounds a bit vague. From a particular point of view, whatever your bean,
the extension chain will have to start somewhere, and chances are, the starting
point will be a built-in class, that is, every bean extends a built-in class.
It might be a good idea to reformulate this particular point.

Comment by Martin Grebac [ 01/Feb/08 ]

adding keyword





[JAXB-132] Support on-demand downloading of plugins Created: 16/Mar/06  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 132

 Description   

We can maintain a list of plugins somewhere in the JAXB project and then allow
XJC to download those plugins on-demand, much like Maven.

This would give more exposure to plugins, and makes it easier for people to use.






[JAXB-57] JAXBElement to implement equals and hashCode Created: 07/Jun/05  Updated: 12/Apr/11

Status: Reopened
Project: jaxb
Component/s: spec
Affects Version/s: 2.0 EA1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Java Source File JAXBElement.java     Java Source File JAXBElementTest.java    
Issuezilla Id: 57

 Description   

Hi.

javax.xml.bind.JAXBElement currently does not override equals(...) and
hashCode() methods. Since this class is used to wrap "real" values, it is
desirable to implement these methods so that they take hashCode() and
equals(...) of the wrapped value into an account.

Basically, hashCode() and equals(...) should operate with name, declaredType,
scope, nil AND value fields.

I can implement these methods, but I need to know, where to find the jaxb-api
project sources...

Bye.
/lexi



 Comments   
Comment by ryan_shoemaker [ 07/Jun/05 ]

The actual CVS repository for the API sources is private and owned by the
JSR-222 expert group, so you can't have access to it. However, there should be
an API src bundle included with the weekly builds under lib/jaxb-api-src.zip.

Feel free to crack open the source and submit a patch. I'll make sure that the
spec guys review it.

Comment by lexi [ 10/Jun/05 ]

Created an attachment (id=30)
My version of JAXBElement

Comment by lexi [ 10/Jun/05 ]

Created an attachment (id=31)
Unit test for JAXBElement

Comment by lexi [ 10/Jun/05 ]

I've attached the patched JAXBElement and a unit test.
Would you let me know about the progress?

Comment by ryan_shoemaker [ 10/Jun/05 ]

I'll have one of the spec guys review your proposal and get back to you

Comment by Joe Fialli [ 10/Jun/05 ]

Unsure what the goal is for defining hashCode() for JAXBElement.
From an xml infoset view, an XML element is identified uniquely via
JAXBElement properties declaringScope and name. If defining the
hashCode is to assist in quick hash lookup by element name, it seems the hashCode
would be unique enough by computing the hash based on name and declaringScope
properties.

Comment by lexi [ 10/Jun/05 ]

The goal for hashCode() is to make it consistent with equals(...).
At least, we have to take the value field into an account.

Comment by kohsuke [ 12/Jun/05 ]

I believe the reason behind this proposal is to implement the value-based
equality between JAXB object trees.

The equals and the hashCode methods can be generated for the beans, which only
leaves the equals/hashCode methods for the JAXBElement class.

Comment by Joe Fialli [ 13/Jun/05 ]

Currently, the JAXB 2.0 specification does not specify the generation
of hashCode() and equals() for schema-derived classes.
In order to make it meaningful for JAXBElement
to be calling hashCode() and equals() on schema-derived classes
set into JAXBElement value property, the specification should
define the generation of hashCode() and equals()
for value classes. I was trying to lessen the dependency by suggesting
that JAXBElement.hashCode() not be defined to call hashCode() on
its value so it would not be required to define hashCode() for
a value class.

The contract between hashCode() and equals() is if two instances
are equal(), they must have the same hashCode() value. This contract
can be kept if hashCode() only looked at the uniquely identifying
components of a JAXBElement, not all components of JAXBElement need
to be involved in computing its hashcode.

Comment by lexi [ 19/Jun/05 ]

> Currently, the JAXB 2.0 specification does not specify the
> generation of hashCode() and equals() for schema-derived classes.

Therefore we are free to implement whatever equality semantics we want.

> In order to make it meaningful for JAXBElement
> to be calling hashCode() and equals() on schema-derived
> classes set into JAXBElement value property, the specification
> should define the generation of hashCode() and equals()
> for value classes.

Not necessarily. By default equals() does identity comparison which seems
perfectly meaningful to me. Let me remind you, right now JAXBElements are
compared by identity in equals(). If this is meaningful, then calling equals()
on values is meaningful as well - no matter if schema-driven classes override
equals()/hashCode() or not.

> I was trying to lessen the dependency by suggesting
> that JAXBElement.hashCode() not be defined to call hashCode()
> on its value so it would not be required to define hashCode()
> for a value class.

What I need and what I think to be quite logical is that JAXBElement DOES value
comarison.
JAXBElement is essentially a value-wrapping class therefore I think it would be
quite logical to ask values if they are equal, when comparing two JAXBElement
instances.

Comment by Joe Fialli [ 20/Jun/05 ]

Status for this request:

Preference is for javax.xml.bind.JAXBElement and schema derived generated value
classes to follow the same methodology for equals.

Note that under certain circumstances, JAXB 2.0 RI is generating schema-derived
value classes annotated with @XmlRootElement. Independent of whether a JAXB
element is represented either as an instance of javax.xml.bind.JAXBElement or it
is generated as a value class annotated with @XmlRootElement, the current status
quo ensures both are using identity for equality comparisons.

I would be fine with both JAXBElement and @XmlRootElement class using values for
comparisons, but the feedback that I am receiving from RI team is they don't
want to see the specification specify value based equality for schema-derived
classes.

Minimally, if JAXBElement.equals was to implement value equality, JAXB 2.0 would
need to provide a customization to control whether schema-derived value classes
had equality by value or by identity. Otherwise, the JAXB 2.0 specification is
inconsistent by default and user has no ability to make it consistent:
JAXBElement.equal being by value, schema-derived classes being by identity and
only with a non-specified customization, does schema-derived value classes
generate a value-based equals that is equivalent to JAXBElement.equal.

Comment by kohsuke [ 27/Sep/05 ]

Moving it to the spec...

Comment by kohsuke [ 30/May/06 ]

Given that JAXB 2.0 is finalized without this, I think it's nearly impossible to
add this in future JAXB releases at this point, since such a change would be
likely to break compatibility.

I guess for the purpose of the equals() plugin, the bean that refers to
JAXBElement needs to take care of this.

Comment by skaffman [ 17/Sep/09 ]

This issue was rejected as WONTFIX 3 years ago, just as the 2.0 spec was being
finalized. Now that the 2.2 spec is in EA, I think it's time to revisit the
question, and have equals() and hashcode() get sensible definitions in JAXBElement.

Comment by lexi [ 17/Sep/09 ]

+1 from me.

I still think hashCode() and equals() must be defined for JAXBElement. However
this can be also worked around using the hashCode and equals plugins from the
JAXB2 Basics plugin package.

http://confluence.highsource.org/display/J2B/Equals+plugin
http://confluence.highsource.org/display/J2B/HashCode+plugin





[JAXB-792] JXC ignores mixed=true, fails to generate XmlMixed/getContents Created: 04/Nov/10  Updated: 27/Feb/12

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

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

Operating System: All
Platform: All


Attachments: Zip Archive so2.zip    
Issuezilla Id: 792
Tags: metro2_1-waived, metro2_2-waived

 Description   

I'm aware of issue #404 and believe this is a distinct issue.

I have a schema that I cannot change that uses inheritance and mixed="true" as a
way to accept character content. XJC (in 2.1 and 2.2) fails to generate an
accessor that makes the character data available. I expect to see an XmlMixed
annotation or a getContents() accessor, but neither are present.

Consider the following schema (a minimized test case):

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

<xs:complexType name="ST" mixed="true">
<xs:complexContent>
<xs:restriction base="ED">
<xs:sequence>
<xs:element name="reference" type="xs:string" minOccurs="0"
maxOccurs="0"/>
<xs:element name="thumbnail" type="xs:string" minOccurs="0"
maxOccurs="0"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="ED" mixed="true">
<xs:complexContent>
<xs:extension base="BIN">
<xs:sequence>
<xs:element name="reference" type="xs:string" minOccurs="0" maxOccurs="1"
/>
<xs:element name="thumbnail" minOccurs="0" maxOccurs="1" type="xs:string"
/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="BIN" abstract="true" mixed="true">
<xs:complexContent>
<xs:extension base="ANY"/>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="ANY" abstract="true">
<xs:attribute name="nullFlavor" type="xs:string" use="optional" />
</xs:complexType>

<xs:element name="title" type="ST" />
</xs:schema>

With the above schema it is impossible to access the character data "Title" in
the following XML:

<?xml version="1.0" encoding="UTF-8"?>
<title xmlns="urn:org:test">Title</title>

I will attach a zip file containing the schema, xml, and the generated classes.



 Comments   
Comment by kibab [ 04/Nov/10 ]

Created an attachment (id=373)
Zip containing schema, xml, and XJC generated files

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived





[JAXB-793] Multiple element definition not read correctly Created: 06/Nov/10  Updated: 28/Mar/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 793
Tags: metro2_1-waived, metro2_2-waived, metro2_3-waived

 Description   

Hi all,

I have the following schema complex type:

<complexType name="PolicyType">
<complexContent>
<restriction base="

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

anyType">
<sequence>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Description" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

PolicyDefaults" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

CombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Target"/>
<choice maxOccurs="unbounded">
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

CombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

RuleCombinerParameters" minOccurs="0"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

VariableDefinition"/>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Rule"/>
</choice>
<element ref="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

Obligations" minOccurs="0"/>
</sequence>
<attribute name="PolicyId" use="required" type="

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

anyURI" />
<attribute name="Version" type="

{urn:oasis:names:tc:xacml:2.0:policy:schema:os}

VersionType" default="1.0" />
<attribute name="RuleCombiningAlgId" use="required" type="

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

anyURI" />
</restriction>
</complexContent>
</complexType>

The corresponding JAXB class looks like:

@XmlType(name = "PolicyType", propOrder =

{ "description", "policyDefaults", "combinerParameters", "target", "additionalInformation", "obligations" }

)
public class PolicyType implements Evaluatable, Serializable {
private static final long serialVersionUID = 1L;
@XmlElement(name = "Description")
private String description;
@XmlElement(name = "PolicyDefaults")
private DefaultsType policyDefaults;
@XmlElement(name = "combinerParameters")
private CombinerParametersType combinerParameters;
@XmlElement(name = "Target", required = true)
private TargetType target;
@XmlElements(

{ @XmlElement(name = "Rule", type = RuleType.class), @XmlElement(name = "VariableDefinition", type = VariableDefinitionType.class), @XmlElement(name = "RuleCombinerParameters", type = RuleCombinerParametersType.class), @XmlElement(name = "CombinerParameters", type = CombinerParametersType.class) }

)
private List<Object> additionalInformation;
@XmlElement(name = "Obligations")
private ObligationsType obligations;
@XmlAttribute(name = "PolicyId", required = true)
@XmlSchemaType(name = "anyURI")
private String policyId;
@XmlAttribute(name = "Version")
private String version;
@XmlAttribute(name = "RuleCombiningAlgId", required = true)
@XmlJavaTypeAdapter(RuleCombiningAlgorithmJAXBTypeAdapter.class)
@XmlSchemaType(name = "anyURI")
private AbstractRuleCombiningAlgorithm ruleCombiningAlg;

...

The thing I want to talk about is the CombinerParameters element. This element is defined twice at different places.
Now when I unmarshal an XML that contains two CombinerParameters elements at the two places the unmarshalling is incorrect.
The second CombinerParameters element is saved into the CombinerParameters element and the first one disappears.
I think the unmarshalling saves both elements into this element and the second overrides the first.
I think the behavior should be that the first is saved into the CombinerParameters field and the second into the
additionalInformation (Choice).



 Comments   
Comment by Pavel Bucek [ 19/Nov/10 ]

thanks for reporting; too late for 2.2.2

metro2.1-waived

Comment by daveboden [ 18/Dec/12 ]

I'm seeing a very similar, if not identical, issue with the FPML 5.4 schema. Please note that I'm using the latest (at time of writing) version of jaxb-impl, 2.2.7-b41, both to compile the bindings and at runtime. Here's the relevant extract from fpml-doc-5.4.xsd :

<xsd:complexType name="TradeIdentifier">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
    A type defining a trade identifier issued
    by the indicated party.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:choice>
      <xsd:sequence>
        <xsd:element name="issuer" type="IssuerId"></xsd:element>
        <xsd:element name="tradeId" type="TradeId"></xsd:element>
      </xsd:sequence>
      <xsd:sequence>
        <xsd:group ref="PartyAndAccountReferences.model">
          <xsd:annotation>
            <xsd:documentation xml:lang="en">
            A pointer style reference to a party identifier and optionally
            an account identifier defined elsewhere in the document.
            The party referenced has allocated the trade identifier.
            </xsd:documentation>
          </xsd:annotation>
        </xsd:group>
        <xsd:choice maxOccurs="unbounded">
          <xsd:element name="tradeId" type="TradeId"></xsd:element>
          <xsd:element name="versionedTradeId" type="VersionedTradeId">
            <xsd:annotation>
              <xsd:documentation xml:lang="en">
              A trade identifier accompanied by a version number.
              In regulatory reporting views, this should be avoided
              except for internal mnessaging.
              </xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:sequence>
    </xsd:choice>
  </xsd:sequence>
  <xsd:attribute name="id" type="xsd:ID" />
</xsd:complexType>

There are essentially two totally separate definitions of elements that have the same name. <tradeId/>. However, when JAXB parses the corresponding XML it treats all <tradeId/> values as they're the first definition. This results in multiple <tradeId/> values that are part of the second definition (that allows multiple instances of the element) being overwritten as the attribute. The JAXB parse loses the values of all but the last element in the incoming XML.

In this example, <partyTradeIdentifier> is of type TradeIdentifier (well, actually it's a subclass called PartyTradeIdentifier but that is not relevant at this stage):

<tradeReferenceInformation>
    <partyTradeIdentifier>
        <partyReference href="MSERV_BANK123"/>
        <tradeId tradeIdScheme="TradeRefNbr">1212H88885</tradeId>
        <tradeId tradeIdScheme="MatchID">MSE21212.026</tradeId>
        <tradeId tradeIdScheme="ClearerID">667789</tradeId>
    </partyTradeIdentifier>
    <partyTradeIdentifier>
        <issuer issuerIdScheme="http://www.fpml.org/coding-scheme/external/cftc/issuer-identifier">178921368077</issuer>
        <tradeId tradeIdScheme="http://www.fpml.org/coding-scheme/external/unique-transaction-identifier">AAB152121</tradeId>
    </partyTradeIdentifier>
</tradeReferenceInformation>

The result of the JAXB parse is two TradeIdentifier beans. The second one has the tradeId correctly filled in as "AAB152121". Unfortunately the first one doesn't have all 3 values in a list, it just retains the "667789" 3rd and final value as the tradeId. The object that represents the choice maxOccurs="unbounded", which is List<Object> getTradeIdOrVersionedTradeId contains NULL.

I'll work on a simplified test case.

Comment by daveboden [ 07/Jan/13 ]

By the time the Unmarshaller is using a SAX parser to look at the <tradeId/> element, the handler has a map keyed on XML tag Name (namespace + element name) to use:

StructureLoader.childElement(UnmarshallingContext$State, TagName) line: 248
ChildLoader child = childUnmarshallers.get(arg.uri,arg.local);

This only contains a single entry for <tradeId/>

The map is built up when the JAXB context is created here:

SingleElementLeafProperty.buildChildElementUnmarshallers line: 191
handlers.put(tagName, new ChildLoader(l, null));

This overwrites one tag name with another without warning. This line of code should probably check for the existence of the key in the map before overwriting it and at least log something at WARN level.

I don't have any ideas at the moment on how to make an improvement to rectify this issue. Because it's a SAX parser (rather than a more complex grammar parser) and everything is keyed just tag Name, it's not going to be a small change. I'll post my test case and workaround.

Comment by Iaroslav Savytskyi [ 08/Jan/13 ]

Nice, thanks a lot.

Comment by kelvin-low [ 28/Mar/14 ]

I having this issue as well. Daveboden, are you able to provide a workaround?





[JAXB-787] @XmlJavaTypeAdapter cannot be used with @XmlElementWrapper Created: 09/Sep/10  Updated: 22/Nov/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 787
Tags: metro2_1-waived, metro2_2-waived

 Description   

Javadoc for @XmlElementWrapper annotation states that it can be used with
@XmlJavaTypeAdapter annotation but it is not true. The reason for this is
com.sun.xml.bind.v2.model.impl.PropertyInfoImpl line 124 where you set
isCollection to false if an adapter exists for a property. This causes
"@XmlElementWrapper is only allowed on a collection property but "..." is not a
collection property." error even if the type returned by adaptor is an collection.



 Comments   
Comment by pawkep [ 09/Sep/10 ]

Sample code:

public class A

{ @XmlJavaTypeAdaptor(DummyAdapter.class) @XmlElementWrapper("list") private List l; }

public class DummyAdapter extends XmlAdapter<Object[], List> {
public Object[] marshal(List v) throws Exception

{ return v == null ? null : v.toArray(); }

public List unmarshal(Object[] v) throws Exception

{ return v == null ? null : new ArrayList(Arrays.asList(v)); }

}

Comment by pawkep [ 09/Sep/10 ]

Replacing:

isCollection = false;
adapter = new Adapter<T,C>(xjta,reader(),nav());

with:

adapter = new Adapter<T,C>(xjta,reader(),nav());
this.isCollection = nav().isSubClassOf(adapter.defaultType,
nav().ref(Collection.class))

nav().isArrayButNotByteArray(adapter.defaultType);

should fix this problem.

Comment by pawkep [ 09/Sep/10 ]

Probably

public T getIndividualType()

{ if(adapter!=null) return adapter.defaultType; ... }

should be changed as well.

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning

Comment by Martin Grebac [ 07/Oct/10 ]

will try to address for 2.2.2

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived





[JAXB-781] Have stricter definition in JAXB NameConverter for "trailing file type" Created: 28/Jul/10  Updated: 04/Aug/10

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

Type: Task Priority: Major
Reporter: gmazza Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File diff.txt     Java Source File NameConverterTest.java    
Issuezilla Id: 781

 Description   

Hello, section D.5.1 Mapping from a Namespace URI, rule #2, mandates removal of
trailing file types, which they define as follows:

Remove the trailing file type, one of .?? or .??? or .html.

JAXB is presently removing everything after the last period, such as .house or
.pumpkin, even though those are valid parts of a urn. It should be really
limited to just the three matchers above, just like rule #1 is presently limited
to just the urn and http scheme (even though there are many others.) That, or
have the spec updated to declare removal of everything after the last dot in a urn.

See here for more info:
http://cxf.547215.n5.nabble.com/Missing-piece-of-urn-in-class-name-tp2112085p2255355.html

I've just patched this in CXF a few hours ago; in addition to JAXB the same
change should be done with Metro for the JAX-WS (non-JAXB) objects.

Attaching source code change, and test class. I needed to make a couple of
other changes to two other long-dormant test cases so they will at least compile
(they have JUnit test failures but that is out of scope for this particular
problem.)

To run the new NameConverterTest class, from the runtime folder run "ant clean
compile" and then run "ant test-runtime". You'll need JUnit 3.8+ or 4+ in your
system classpath.



 Comments   
Comment by gmazza [ 28/Jul/10 ]

Created an attachment (id=367)
Diff for source code changes.

Comment by gmazza [ 28/Jul/10 ]

Created an attachment (id=368)
New JUnit test class

Comment by gmazza [ 04/Aug/10 ]

Marked as having a patch.





[JAXB-780] Autogenerated adapters should throw Exception for marshal()/unmarshal() Created: 28/Jul/10  Updated: 04/Feb/12

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

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

Operating System: All
Platform: All


Attachments: Text File jaxb_780_fix.patch    
Issuezilla Id: 780

 Description   

By interface, XmlAdapter.unmarshal() and XmlAdapter.marshal are allowed to throw
an exception. However this opportunity is not used by autogenerated Adapters.
Expected: generated adapters declare Exception in the list of throwables.

Currently if I have the following utility class:

public class DatatypeConverter {

private static final SimpleDateFormat DATE_FORMAT = new
SimpleDateFormat("yyyyMMdd");

public static Date parseDate(String xmlDate) throws ParseException

{ return DATE_FORMAT.parse(xmlDate); }

public static String printDate(Date date)

{ return DATE_FORMAT.format(date); }

}

the generated adapter does not compile:

public class Adapter1
extends XmlAdapter<String, Date>
{

public Date unmarshal(String value)

{ // error here: should throw Exception return (mypackage.DatatypeConverter.parseDate(value)); }

public String marshal(Date value)

{ return (mypackage.printDate(value)); }

}



 Comments   
Comment by Martin Grebac [ 06/Oct/10 ]

reassigning

Comment by ofarrell [ 03/Nov/10 ]

Created an attachment (id=372)
Proposed Fix

Comment by schulte2005 [ 11/Mar/11 ]

When throwing a checked exception, generated code of simple types declaring a default value would no longer compile. For example:

<xsd:attribute name="type" type="tns:MimeType" use="optional" default="text/plain"/>

with

<jaxb:baseType>
<xjc:javaType name="javax.activation.MimeType" adapter="pkg.MimeTypeXmlAdapter"/>
</jaxb:baseType>

produces

public MimeType getType() {
if (type == null)

{ return new MimeTypeXmlAdapter().unmarshal("text/plain"); }

else

{ return type; }

}

If the unmarshal method would throw a checked exception, the generated getType method would no longer compile.

Comment by Dmitry Katsubo [ 04/Feb/12 ]

I think this is trivial to always add "throws Exception" to generated adapters? However the issue is not resolved for already 3 years...





[JAXB-773] Could not add vendor customization to xsd:any Created: 06/Jul/10  Updated: 06/Oct/10

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

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

Operating System: All
Platform: All
URL: https://jaxb2-commons-svn.dev.java.net/svn/jaxb2-commons-svn/trunk/basics/tests/issues/


Attachments: XML File schema.xsd    
Issuezilla Id: 773

 Description   

Hi,

my XJC plugins support vendor customizations, some of them can be apply on the
property level. Recently I have found out that you can't customize xs:any.

This works:

<xs:element name="any" type="xs:anyType">
<xs:annotation>
<xs:appinfo>
<basic:ignored />
</xs:appinfo>
</xs:annotation>
</xs:element>

This does not work:

<xs:any>
<xs:annotation>
<xs:appinfo>
<basic:ignored />
</xs:appinfo>
</xs:annotation>
</xs:any>

Stack trace:

[ERROR] Error while parsing schema(s).Location [
file:/C:/Projects/dev.java.net/jaxb2-commons-
svn/basics/tests/issues/src/main/resources/schema.xsd

{141,24}

].
com.sun.istack.SAXParseException2: compiler was unable to honor this ignored
customization. It is attached to a wrong place, or its inconsistent with other
bindings.
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at
com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:79)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustom
izationChecker.java:144)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustom
izationChecker.java:122)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.wildcard(UnusedCus
tomizationChecker.java:211)
at com.sun.xml.xsom.impl.WildcardImpl.visit(WildcardImpl.java:198)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.particle(UnusedCus
tomizationChecker.java:241)
at com.sun.xml.xsom.impl.ParticleImpl.visit(ParticleImpl.java:124)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.modelGroup(UnusedC
ustomizationChecker.java:222)
at com.sun.xml.xsom.impl.ModelGroupImpl.visit(ModelGroupImpl.java:125)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.particle(UnusedCus
tomizationChecker.java:241)
at com.sun.xml.xsom.impl.ParticleImpl.visit(ParticleImpl.java:124)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.complexType(Unused
CustomizationChecker.java:182)
at com.sun.xml.xsom.impl.ComplexTypeImpl.visit(ComplexTypeImpl.java:295)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomiz
ationChecker.java:108)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomiz
ationChecker.java:98)
at
com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:187)
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 org.jvnet.jaxb2.maven2.RawXJC2Mojo.loadModel(RawXJC2Mojo.java:639)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:259)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:135)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.ja
va:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycl
eExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(Def
aultLifecycleExecutor.java:540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycle
Executor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultL
ifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExec
utor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[ERROR] Error while parsing schema(s).Location [
file:/C:/Projects/dev.java.net/jaxb2-commons-
svn/basics/tests/issues/src/main/resources/schema.xsd

{138,12}

].
com.sun.istack.SAXParseException2: (the above customization is attached to the
following location in the schema)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:82)
at
com.sun.tools.xjc.reader.xmlschema.ErrorReporter.error(ErrorReporter.java:79)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustom
izationChecker.java:149)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.check(UnusedCustom
izationChecker.java:122)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.wildcard(UnusedCus
tomizationChecker.java:211)
at com.sun.xml.xsom.impl.WildcardImpl.visit(WildcardImpl.java:198)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.particle(UnusedCus
tomizationChecker.java:241)
at com.sun.xml.xsom.impl.ParticleImpl.visit(ParticleImpl.java:124)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.modelGroup(UnusedC
ustomizationChecker.java:222)
at com.sun.xml.xsom.impl.ModelGroupImpl.visit(ModelGroupImpl.java:125)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.particle(UnusedCus
tomizationChecker.java:241)
at com.sun.xml.xsom.impl.ParticleImpl.visit(ParticleImpl.java:124)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.complexType(Unused
CustomizationChecker.java:182)
at com.sun.xml.xsom.impl.ComplexTypeImpl.visit(ComplexTypeImpl.java:295)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomiz
ationChecker.java:108)
at
com.sun.tools.xjc.reader.xmlschema.UnusedCustomizationChecker.run(UnusedCustomiz
ationChecker.java:98)
at
com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:187)
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 org.jvnet.jaxb2.maven2.RawXJC2Mojo.loadModel(RawXJC2Mojo.java:639)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:259)
at org.jvnet.jaxb2.maven2.RawXJC2Mojo.execute(RawXJC2Mojo.java:135)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.ja
va:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycl
eExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(Def
aultLifecycleExecutor.java:540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycle
Executor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultL
ifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExec
utor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

I'll attach the schema to the issue. Test project can be found here:

https://jaxb2-commons-svn.dev.java.net/svn/jaxb2-commons-
svn/trunk/basics/tests/issues/



 Comments   
Comment by lexi [ 06/Jul/10 ]

Created an attachment (id=363)
Sample schema

Comment by gmazza [ 06/Jul/10 ]

Pardon my ignorance, I may easily be wrong here, but are you sure <xs:any/> can
be a top-level element in the manner you are giving (the example that doesn't
work)? The XML Schema Recommendation isn't immediately clear on the matter
(http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#Wildcards),
and I'm not sure I've seen that before.

Comment by lexi [ 07/Jul/10 ]

Hi,

these are just fragments, see the attached schema
(https://jaxb.dev.java.net/nonav/issues/showattachment.cgi/363/schema.xsd) for
the full example.

Here's a more complete code snippet, if you wish:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:basic="http://jaxb2-commons.dev.java.net/basic"
xmlns:copyable="http://jaxb2-commons.dev.java.net/basic/copyable"
xmlns:equals="http://jaxb2-commons.dev.java.net/basic/equals"
xmlns:hashCode="http://jaxb2-commons.dev.java.net/basic/hashCode"
xmlns:mergeable="http://jaxb2-commons.dev.java.net/basic/mergeable"
xmlns:toString="http://jaxb2-commons.dev.java.net/basic/toString"
xmlns:inheritance="http://jaxb2-commons.dev.java.net/basic/inheritance"
xmlns:wildcard="http://jaxb2-commons.dev.java.net/basic/wildcard"
jaxb:version="2.1"
jaxb:extensionBindingPrefixes="basic copyable equals hashCode mergeable
toString inheritance wildcard">

...

<xs:complexType name="issueHJIII59AType">
<xs:sequence>
<xs:any>
<xs:annotation>
<xs:appinfo>
<!-- Does not work -->
<basic:ignored />
</xs:appinfo>
</xs:annotation>
</xs:any>
</xs:sequence>
</xs:complexType>

<xs:complexType name="issueHJIII59BType">
<xs:sequence>
<xs:element name="any" type="xs:anyType">
<xs:annotation>
<xs:appinfo>
<!-- Works -->
<basic:ignored />
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>

Hope this clears your concerns.

Bye.
/lexi

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning





[JAXB-762] Impossible to unmarshal an element that have multiple same sub-element type in sequence, extension and group Created: 22/Jun/10  Updated: 14/Oct/10

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

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

Operating System: All
Platform: All


Attachments: Zip Archive JaxbBug.zip    
Issuezilla Id: 762

 Description   

I have generated with xjc the classes corresponding to an xsd.

The xsd has an element "eveNai" that has a complexContent with "identification"
elements that comes from an extension, a group and a sequence.

During the unmarhaling jaxb set always the same identification element instead
of setting the identification for corresponding extension, group and sequence.

It's a little bit hard to explain with words the problem:
Please open the attached maven project and then launch the class Main.

I cannot change the definition of the xsd because it is already used by a lot of
clients.

Thanks.

Christophe Rodriguez



 Comments   
Comment by rodriguezc [ 22/Jun/10 ]

Created an attachment (id=355)
Bug: Maven project

Comment by rodriguezc [ 25/Jun/10 ]

I have tried with xmlbeans.

XmlBeans create an array that contains all "identification" elements so it don't
lose values.

Comment by gmazza [ 04/Aug/10 ]

How do we launch the class Main? Do we need to run "mvn clean install"
beforehand? It would be good if you added the maven-exec-plugin to the Maven
pom file so we could just quickly run "mvn exec:exec" to activate that Main
class, without needing to worry about JARs and classpaths needed to activate the
Main class.

Also, do you think this is a bug in JAXB or a weakness in the JAXB
specification? Not everything supported in XMLBeans is supported in the JAXB
specification, and you may be requesting a spec change instead.

Comment by rodriguezc [ 09/Aug/10 ]

I have already copied the generated classes in the package "test".

So you must only run the Main.class from eclipse and don't use maven commands.

Procedure to launch the main class:
1. In Eclipse: File-> Import -> Maven Project.
Import the attached maven project.

2. Launch the Main class using eclipse launcher:
Right click on "Main.java" and then "Run as java application".

I think that the problem is related with collision names and the xsd don't
respect the "best practices" for property names.

I have resolved collisions names with a custom bindings.

You can see the custom bindings in the file src/main/resources/binding.xjb

I haven't found anything about a collision resolution limitation in the jaxb
specification.

But if Jaxb can lose data without generating any exception during the
compilation and at the runtime during the marshalling, it means that we must
test and validate all marshalling possibilities before using jaxb in production
environment,

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning

Comment by Marek Potociar [ 14/Oct/10 ]

Changed to enhancement





[JAXB-766] Ommiting @XmlMimeType breaks DataHandler unmarshalling Created: 01/Jul/10  Updated: 23/Nov/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 766
Tags: metro2_1-waived, metro2_2-waived

 Description   

I have a test client that sends WS attachment using DataHandler like this:

MTOMEndpoint mtomEndpoint = getEndpointPort();
DataHandler send = new DataHandler(new FileDataSource(PNG_FILE));
DHRequest request = new DHRequest(send);
DHResponse response = mtomEndpoint.echoData(request);
DataHandler recv = response.getDataHandler();

The server WS just sends back what it receives:
byte[] echoFile =
StreamUtils.readStream((InputStream)(request.getDataHandler().getContent()));
DataHandler o = new DataHandler(new ByteArrayInputStream(echoFile),
request.getDataHandler().getContentType());
return new DHResponse(o);

The issue is in DHRequest and DHResponse classes I use. They are simple classes:
@XmlType(name = "dataRequest", namespace = "http://mycompany/xop/doclit")
public class DHRequest {
private DataHandler dataHandler;
public DHRequest() { }
public DHRequest(DataHandler dataHandler)

{ this.dataHandler = dataHandler; }

// @XmlMimeType("image/png")
public DataHandler getDataHandler() { System.out.println(dataHandler.getContentType()); return dataHandler; }

public void setDataHandler(DataHandler dataHandler) { this.dataHandler = dataHandler; }

}

DHResponse is the same if you replace Reuest with Response.

Without setting the @XmlMimeType annotation everything works and the message on
the server side looks like this:
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header/>
<env:Body>
<ns2:echoDataResponse
xmlns:ns2="http://mycompany/xop/doclit"><return><dataHandler> ... Base64 encoded
data ... </dataHandler></return></ns2:echoDataResponse></env:Body></env:Envelope>

The DataHandler's content type on the client side (see the System.out.println)
is image/png in the request and application/octet-stream in the response.
On the server side it is application/octet-stream in both cases.

No matter what I set in @XmlMimteType, it always broke. I tried
application/octet-stream, text/plain and image/png. The thing is that whenever I
set a mime type explicitly, the message stop being Base64 encoded. Instead it is
a message with a binary attachment. The following is when DHResponse used
application/octet-stream:
------=_Part_2_74198202.1277739135119
Content-Type: application/xop+xml; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@mycompany>

<env:Envelope
xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'><env:Header></env:Header><env:Body><ns2:echoDataResponse
xmlns:ns2="http://mycompany/xop/doclit"><return><dataHandler><xop:Include
xmlns:xop="http://www.w3.org/2004/0
8/xop/include"
href="cid:dataHandler-75243ed1-23b7-4d2a-9ae6-aa2cb84c8e8f@mycompany"/></dataHandler></return></ns2:echoDataResponse></env:Body></env:Envelope>
------=_Part_2_74198202.1277739135119
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: <dataHandler-75243ed1-23b7-4d2a-9ae6-aa2cb84c8e8f@mycompany>

... binary scarp ...
-----=_Part_2_74198202.1277739135119-



 Comments   
Comment by opalka [ 01/Jul/10 ]

I spent some time to help you with this issue and here are my investigations:

Before starting please have a look to:

JAXB 2.2 javadoc for the following annotations:

  • @javax.xml.bind.annotation.XmlMimeType
  • @javax.xml.bind.annotation.XmlInlineBinaryData

JAX-WS 2.2 javadoc for the following annotations:

  • @javax.xml.ws.BindingType
  • @javax.xml.ws.soap.MTOM
  • @javax.xml.ws.soap.MTOMFeature

The following objects can be sent as MTOM/XOP attachments:

  • byte[]
  • java.awt.Image
  • javax.xml.transform.Source
  • javax.activation.DataHandler

Enabling MTOM on JAX-WS endpoint can be achieved:

  • either by declaring @MTOM
  • or by declaring @BindingType(value =
    "http://schemas.xmlsoap.org/wsdl/soap/http?mtom=true")

Enabling MTOM on JAX-WS client can be achieved:

  • either
    ((SOAPBinding)((BindingProvider)port).getBinding()).setMTOMEnabled(true) on
    already created proxy
  • or service.getPort(MTOMEndpoint.class, new MTOMFeature(true)) for proxies
    being created

If you don't specify @XmlMimeType on getter or
if you specify both @XmlMimeType and @XmlInlineBinaryData on getter
the attachment object will always be inlined on the wire.

If you specify only @javax.xml.bind.annotation.XmlMimeType on getter
the attachment object will always be sent as MIME attachment on the wire.

@XmlMimeType is used in JAXB schema generator
and adds xmlmime:expectedContentTypes to WSDL. Here's example:

<?xml version="1.0" encoding="UTF-8"?>
<definitions ...>
<types>
<xs:schema targetNamespace="SOME_NS" version="1.0" xmlns:tns="SOME_NS"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="echoDataHandler" nillable="true" type="tns:dataRequest"/>
<xs:complexType name="dataRequest">
<xs:sequence>
<xs:element minOccurs="0" name="dataHandler"
ns1:expectedContentTypes="text/plain" type="xs:base64Binary"
xmlns:ns1="http://www.w3.org/2005/05/xmlmime"/>
</xs:sequence>
</xs:complexType>
...
</types>
...
</definitions>

Conclusion:

JAXB un/marshalling violates MTOM/XOP specifications and generates invalid
MTOM/XOP messages.
JAXB should generate in XML schema and process xmlmime:contentType attribute on
XML elements wrapping binary data
(regardless of the fact they are sent as inlined base64Binary or MIME
attachments - see MTOM/XOP specifications).

Example of broken message being exchanged:

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header/>
<env:Body>
<ns1:echoDataHandler xmlns:ns1="http://org.jboss.ws/xop/doclit">
<dataHandler>RGF0YUhhbmRsZXJSb3VuZHRyaXA=</dataHandler> <!-- here content
type information is lost because of missing xmlmime:contentType attribute -->
</ns1:echoDataHandler>
</env:Body>
</env:Envelope>

When attachment that is un/marshalled by JAXB runtime is inlined
the content type information is always lost (see generated schema).

When attachment that is un/marshalled by JAXB runtime was sent as MIME multipart
the content type information is obtained from MIME header.

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning

Comment by Martin Grebac [ 07/Oct/10 ]

will try to address for 2.2.2

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived





[JAXB-758] Wrong behaviour with xsd:any and a payload with default namespace Created: 19/May/10  Updated: 18/Sep/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 758

 Description   

Hello,
I am working with Metro 2.1 nightly, JAXB 2.2 and WS-Transfer.
WS-Transfer elements like Put, Create, ... are providing an xsd:any content
where I need to add the original payload to be transferred.
Actually JAXB is erroneously modifying the namespace of a payload with default
namespace.

xsd:Any allows almost any content and expecially using skip processing such
content must be ignored.
There is no reason to add the outer namespace (e.g. the namespace of a
ws-transfer "Put" element) to the inner payload.

Payload's integrity is required to be preserved as it could represent an Invoice
with an incorporated digital signature.
This means the receiver must be able to validate the signature against the
payload content (and this is not possible if the payload is modified on-the-road).
The transport should not change the payload at all...

Actually I noted that JAXB has a strange behaviour with either "lax" and "skip"
processing of the xsd:any if the payload has a default namespace declared into
its root (xmlns="...").

Example using LAX or SKIP processing
----------------------------------------------------
Generated by JAXB:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="" xmlns:ns4="[WS-Transfer NS]" xmlns="[original default NS]" />
</ns4:Put>

This is how it should be with the original payload:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="[original default NS]"/>
</ns4:Put>

I believe that xsd:Any "skip" processing should completely ignore the xml
content and thus the way namespaces are declared in the payload should be
untouched...

The same is for "lax" processing if the payload is not using elements from
declared namespaces in the context (as it is usually for a business payload).

Example using <jaxb:dom/> xs:annotation
----------------------------------------------------
I made this exercise to avoid a dependancy between Put and its xs:any content.
I dreamed to see the payload untouched after this change but I was wrong.

<xs:element name="Put">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="1" maxOccurs="unbounded" namespace="##other"
processContents="skip">
<xs:annotation><xs:appinfo>
<jaxb:dom/>
</xs:appinfo></xs:annotation>
</xs:any>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
</xs:element>

Generated by JAXB:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice:Invoice xmlns:Invoice="[original default NS]" xmlns:ns4="[WS-Transfer
NS]" xmlns="[original default NS]" />
</ns4:Put>

NOTE: The behaviour is changed a few here, but the namespace "xmlns:Invoice" is
really undesired and not useful at all.

This is how the Put should be with the original payload:

<ns4:Put xmlns:ns4="[WS-Transfer NS]">
<Invoice xmlns="[original default NS]"/>
</ns4:Put>

Payloads with a default namespace are a common case, I really hope this is not a
real limit of JAXB.

Please can you suggest a workaround ?

Thank you in advance for any help

Best regards

Roberto Cisternino



 Comments   
Comment by cistox [ 19/May/10 ]

The following thread and issue are related:

Namespace error when marshalling DOM element with attributes using JAXB 2.1
http://forums.java.net/jive/thread.jspa?threadID=55699&tstart=0

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

Comment by Pavel Bucek [ 19/May/10 ]

adjusting priority (P1 is showstopper)

we know about this but its very hard to fix anything regarding namespaces (because of our thorough test
suites and regressions from dependent products). additionally, this is not "wrong", its valid xml.
Namespaces are there because of unpredictability of xsd:any content.

Comment by Martin Grebac [ 06/Oct/10 ]

updating

Comment by bshrom [ 17/May/12 ]

While this is a valid xml, this bug causes XML signature failure and eventually interoperability problem in Metro.
Metro/WSIT uses JAXB under the hood and when security tokens are included, located under xsd:any, they are modified before they go on the wire.
See related bug: http://java.net/jira/browse/METRO-16
The same problem is with OnBehalfOf when SAML Assertion token is used, which breaks WS-Trust interoperability between Metro and .NET.
MS .NET uses xmlns="[original default NS]" constructs all the time resulting in modified XML and signature failure.

This bug should've never been classified as Improvement.

Comment by cistox [ 31/May/12 ]

It is incredible the JAXB 758 bug is still there. The way xsd:Any is handled is wrong. There is no reason to add namespaces from the outer envelope (e.g. WS-Transfer scaffolding) on the xsd:Any content.

Primary European projects are suffering of these bugs, it is very bad that such fixes are not applied due to dependancies from other bugged projects...
I am curious to know one of these projects that is relying on such JAXB bugs for its functions. It's a crazy situation.

XML is a nice thing but it's happen is going to be used on real business scenarios... thus digital signatures and other most serious dependancies have to be supported...

Comment by cistox [ 17/May/13 ]

Dear all,
major European projects like PEPPOL are going to fail using the actual Metro stack due to such JAXB issues.
All the project is moving to AS2 due to the interop issues with .NET.

I am really curious why JAXB cannot be fixed about the xsd:Any behaviour... I do not think other software can take any benefit from such wrong behaviour.

Comment by cistox [ 29/May/13 ]

HOW TO SOLVE THIS ISSUE:

The actual way the xsd:Any is handled by JAXB is not conformant to W3C XML Schema.

My proposal is to introduce a switch to let the developer to use JAXB in a conformant way and another to play the actual version (let's give it a name to justify its existance...)

With this basic switch the actual dependancies will be safe, but those interested into a conformat behaviour of xsd:Any will be really happy.

At this stage WS-Transfer and SAML have been identified as suffering from this bug when implemented using JAXB, but I am pretty sure this bug is the cause of several other issues. For instance the digital signature applied to a payload could be compromised by the addition of unwanted namespaces.

Hope this helps.

Comment by fontana.damiano [ 18/Sep/13 ]

we are experimenting the same issue described above.
We hope that it will be fixed as soon as possible, in order to successufully use JAXB in enterprise B2B solutions to exchange document of any type in XML format





[JAXB-745] xjc derivation by extension/restriction Created: 19/Mar/10  Updated: 09/May/12

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

Type: Improvement Priority: Major
Reporter: dkodko Assignee: jaxb-issues
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Java Source File AbstractExtendedComplexTypeBuilder.java    
Issuezilla Id: 745

 Description   

Hi,

xjc produces this error when compiling the schema below. this issue does seem to
relate to issue 149, but in this case the content of the 3 involved types does
not appear to be conflicting in any way....

>>>Base complex type "Response" is derived by restriction, while this complex
type "MyResponse" is derived by extension. This is not currently handled by XJC,
but we are seeking input on this issue. Please report this to the JAXB team.<<<

<xs:complexType name="Body">
<xs:complexContent>
<xs:extension base="xs:anyType"/>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Response">
<xs:complexContent>
<xs:restriction base="Body">
<xs:sequence>
<xs:element name="resultCode" type="xs:string"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="MyResponse">
<xs:complexContent>
<xs:extension base="Response">
<xs:sequence>
<xs:element name="message" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

cheers,

dk



 Comments   
Comment by Martin Grebac [ 15/Apr/10 ]

Thanks for submission, will look into it.

Comment by kameleono [ 27/Apr/11 ]

I have been exposed to the same problem when trying to generate Java code for the JDF Schema (http://www.cip4.org/).

Since no single attribute nor element was being redefined by the extension of the restriction, I modified the code in the class com.sun.tools.xjc.reader.xmlschema.ct.AbstractExtendedComplexTypeBuilder for the checkIfExtensionSafe method.

It now compiles the example from the following book:
http://www.datypic.com/books/defxmlschema/chapter14.html

As far as the JDF Schema is concerned, there are some other limitations that became apparent.

Comment by mwarden [ 09/May/12 ]

We manage the Ed-Fi education data interchange standard [1] and have received reports from a state trying to use our standard with XJC, and this report seems to align with this Issue. I am commenting in order to explain the use case, as the error message reported in this situation implies the team would like to better understand why this use case occurs.

We have a standard core XSD that defines a large set of complex types for use in standard interchanges of data. For example, we define a a complex type named TeacherSchoolAssociation for use in an interchange that reports assignment and employment relationships for teachers to school buildings. Both the type and the interchange structure are part of our standard.

However, there may be optional elements in our standard core for TeacherSchoolAssociation that have no relevance for a given state, and they would like to remove these elements via a restriction. Similarly, individual states have additional things they will need to report that are specific to that state and do not make sense to add to the standard for all states, and they would like to add these elements via an extension.

Therefore we create a new XSD, e.g. OH-Core that includes the Ed-Fi-Core. We first restrict types to remove unnecessary optional children. We then extend types to add in state-specific children. This is valid per the specification and works fine in other processors.

Here is the exact error we get in this situation (modified slightly – the state that reported is not Ohio):

xjc -xmlschema .\schemas\OH-ServiceEnvelope-StudentProfileEnrollment.xsd -d code -p com.edfi.oh.xchange
parsing a schema...
[ERROR] Base complex type "OH-TeacherSchoolAssociationRestriction" is derived by restriction, while this complex type "OH-TeacherSchoolAssociationExtension" is derived by extension. This is not currently handled by XJC, but we are seeking input on this issue. Please report this to the JAXB team.
line 835 of file:/C:/Docum.../jaxb_schemas/schemas/OH-Ed-Fi-Core-Extension.xsd

I would be happy to provide any additional details about this use case. Additionally, I would be happy to discuss whether an alternative pattern to achieve the same flexibility might be more appropriate for XJC users.

[1] Ed-Fi, a K-12 education data interchange standard offered by the Michael and Susan Dell Foundation, http://www.ed-fi.org/





[JAXB-738] Schema generation omits anyAttribute when XmlValue is used Created: 25/Feb/10  Updated: 22/Nov/11

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.1.9
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Java Source File AnyAttributeTest.java    
Issuezilla Id: 738
Tags: metro2_1-waived, metro2_2-waived

 Description   

Schema generation for a bean with both XmlAnyAttribute and XmlValue should allow
for any attribute, currently the "anyAttribute" element is not present in the
generated XML Schema.



 Comments   
Comment by sjones4 [ 25/Feb/10 ]

Created an attachment (id=349)
Test application to reproduce the issue

Comment by Martin Grebac [ 06/Oct/10 ]

assigning

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived

Comment by Martin Grebac [ 22/Nov/11 ]

Reproduced, need to investigate why this is happening.





[JAXB-728] imports/includes don't work with "jar:" url system ID's Created: 04/Jan/10  Updated: 06/Oct/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 728

 Description   

Invoking xjc programatically, if I pass an input schema that has a systemId of a
"jar" url, such as:

jar:file:/home/dkulp/.m2/repository/net/tataryn/CXFSchemaRefProblemXSDJar/r1v0m0
/CXFSchemaRefProblemXSDJar-r1v0m0.jar!/telus/coreschemas/datatypes-base.xsd

or similar, and that xsd has an include like:
<xs:include schemaLocation="voc.xsd"/>

in it, the "voc.xsd" is not being resolved. The problem is in
AbstractReferenceFinderImpl with the line:

String ref = new URI(locator.getSystemId()).resolve(new
URI(relativeRef)).toString();

The URI class treats "jar" URL's as opaque (possibly a bug in URI class in the
JDK). Thus, it always returns the "child" URI, which would just be "voc.xsd"
in this case. A "workaround" for this can be something like:

URI base = new URI(locator.getSystemId());
String ref;
if ("jar".equals(base.getScheme()) {
ref = new URL(new URL(locator.getSystemId()), relativeRef).toString();
} else {
ref = base.resolve(new URI(relativeRef)).toString();
}

That would fix it for the "jar" case, but it's possible that other schemes might
want to do the same thing. Thus, another possible fix would be:

URI base = new URI(locator.getSystemId());
String ref;
if (base.isOpaque()) {
ref = new URL(new URL(locator.getSystemId()), relativeRef).toString();
} else {
ref = base.resolve(new URI(relativeRef)).toString();
}



 Comments   
Comment by dkulp [ 04/Jan/10 ]

Another (actually preferred) enhancement would be a way to configure in (via the
options or similar) a custom InternalizationLogic object where we can provide a
custom AbstractReferenceFinderImpl that could handle the schemaLocation mapping
itself. That would allow us to wire in support for our catalogs and "internal"
schemas and such instead of jumping out to the internet in some cases.

Comment by Martin Grebac [ 06/Oct/10 ]

updating status





[JAXB-724] Order of marshalling items in a collection in JAXB 2.1 Created: 04/Dec/09  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All
URL: http://old.nabble.com/Order-of-marshalling-items-in-a-collection-in-JAXB-2.1-td26630658.html


Issuezilla Id: 724

 Description   

Per request of Martin Grebac, I am filing the question from the jaxb-users list (at the URL, but also
reproduced here) as a specification question. Please advise if more or different information is needed.
Thank you.


from Wolfgang Laun <wolfgang.laun@gmail.com>
reply-to users@jaxb.dev.java.net
to users@jaxb.dev.java.net
date Fri, Dec 4, 2009 at 3:32 AM
subject Re: Order of marshalling items in a collection in JAXB 2.1

It seems that you have discovered an omission in the spec. Although,
from the Java point of view, not all iterable collections have a specific
order, in the sense that the same Java program will, or is bound to,
produce the same order on different JVMs.

A quote from the spec:
"If the ordering between the children elements is significant and must be
accessible to the Java application, then the ordering is naturally
preserved in Java representation via a collection."

I interpret this to hold for both directions, i.e., whenever the Java
collection type implies a portable order of its elements then this
will be the order of the marshalled XML elements.

-W

  • Hide quoted text -
    On Thu, Dec 3, 2009 at 7:21 PM, Nigel Kerr <nigel.kerr@gmail.com> wrote:
  • Hide quoted text -
    Hello,

There is a idea that JAXB does not provide ordering guarantees of
child elements. I've had colleagues assert this, and I see it in
discussions like
http://forums.sun.com/thread.jspa?forumID=34&threadID=622325 . I
haven't found an example that actually demonstrates that ordering at
either marshalling or unmarshalling is unreliable.

I would like to be able to refer to the JAXB 2 Spec on what, if
anything, is promised about the ordering of elements.

From reading exactly The JavaTM Architecture for XML Binding (JAXB)
2.1 Final Release December 11, 2006, I believe:

1. @XmlType's propOrder property can be used to specify the order of
properties: if my schema defines a sequence of three different
elements, I expect xjc to list three corresonding properties in the
same order in the corresponding @XmlType annotation.

2. Appendix B "Runtime Processing", section 3 "Unmarshalling",
sub-section 3.4 "Element Information Item", directs that an element
information item whose .property is a collection type, shall be added
to the end of the collection. This promises that, at least when the
XML instance is schema-valid, document order and the order of items in
the collection will be the same.

I am unable to identify statements similar to #2 for Marshalling. B.4
"Marshalling" does not speak about collection types, or at least not
that I understand. What I am looking for is a statement such as:

The order of objects in the collection is the order in which they
will be marshalled.

Does such a statement, or anything related to it, exist? Is this so
obvious I've missed it?

cheers,
Nigel Kerr

from Nigel Kerr <nigel.kerr@gmail.com>
to users@jaxb.dev.java.net
date Fri, Dec 4, 2009 at 7:01 AM
subject Re: Order of marshalling items in a collection in JAXB 2.1
mailed-by gmail.com

This may be as strong a reed as there is in the current spec, then. I
would advocate strengthening this aspect, possibly:

All collection types are list or array types expressly, not just bags
or sets, unless otherwise specified

or even just something on what exactly happens to the collections at
marshalling time, regardless of what the type is ("All arrays are
consulted from index zero sequentially, all Collection types are
iterated by their default iterators").

Thank much.






[JAXB-720] XJC (in simple mode) should avoid JAXBElement for substitutable elements Created: 20/Nov/09  Updated: 20/Nov/09

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

Type: New Feature Priority: Major
Reporter: ashiand Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: GIF File AbstractComponent.gif     XML File AbstractComponent.xsd     Text File DefaultClassBinder.diff    
Issuezilla Id: 720

 Description   

In OOP there's a very common pattern where a Container can have an abstract
Component with concrete subtypes (see AbstractComponent.gif). In XSD one way to
model this pattern is to use substitution groups. I'm attaching example schema
AbstractComponent.xsd. JAXB can deal with this with XmlElementRef w/o resorting to
JAXBElement (which clutters domain classes). I'm attaching quick and dirty patch
for XJC.



 Comments   
Comment by ashiand [ 20/Nov/09 ]

Created an attachment (id=343)
UML diagram of abstract component

Comment by ashiand [ 20/Nov/09 ]

Created an attachment (id=344)
Example XML schema for abstract componet

Comment by ashiand [ 20/Nov/09 ]

Created an attachment (id=345)
Patch against 2.1.12





[JAXB-716] customization baseType results in strange code & cast error Created: 12/Nov/09  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Attachments: XML File indra.xsd     Java Source File Main.java    
Issuezilla Id: 716

 Description   

Consider the following customization, which may not be correct. (The JAXB Spec
is rather difficult to understand in the pertaining section.)

<element name="primaryKey" nillable="false">
<annotation><appinfo>
<jaxb:property>
<jaxb:baseType name="java.lang.Object"/>
</jaxb:property>
</appinfo></annotation>
<complexType mixed="false">
<complexContent mixed="false">
<extension base="anyType"/>
</complexContent>
</complexType>
</element>

xjc compiles this, but the resulting Java code has field primaryKey with type
Object, while the JAXB annotation still has the anonymous complexType:
@XmlElement(required = true, type = DocType.PrimaryKey.class)
protected Object primaryKey;
and the static class DocType.PrimaryKey is fully included.
BUT-1: setPrimaryKey("foo") can be marshalled (but not validated).
BUT-2: Unmarshalling results in a type cast conflict since getPrimaryKey()
actually returns a DocType.PrimaryKey.

So: If it isn't possible to generate working Java code why doesn't JAXB produce
an error? Or, otherwise, why isn't the customization fully accepted, overriding
and discarding the DocType.PrimaryKey (even though created XML won't validate
agaisnt the XML Schema, perhaps)?



 Comments   
Comment by laune [ 12/Nov/09 ]

Created an attachment (id=340)
sample schema

Comment by laune [ 12/Nov/09 ]

Created an attachment (id=341)
Java main program

Comment by Pavel Bucek [ 20/Nov/09 ]

thanks for submission; setting target milestone

Comment by Pavel Bucek [ 07/Oct/10 ]

updating target milestone; wasn't able to get response from Kohsuke; looks like it might be a spec issue

Comment by Pavel Bucek [ 14/Oct/10 ]

changing subcomponent to spec





[JAXB-702] Rebundle/redist more libraries Created: 21/Oct/09  Updated: 15/Apr/11

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 702

 Description   

We are now including FastInfoset.jar in jaxb-osgi.jar but not in jaxb-impl.jar.
We should consider if that library should be moved to tools/lib/rebundle or
tools/lib/redist.

Other potential candidates for moving are sjsxp.jar and stax-ex.jar.






[JAXB-700] No point in generating @XmlType(propOder) when there is only one property Created: 15/Oct/09  Updated: 15/Oct/09

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

Type: Improvement Priority: Major
Reporter: jitu Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 700

 Description   

xjc generates the following bean. In this bean, there is no point in generating
propOder annotation element.

@XmlType(name = "getIdResponse", propOrder = {
"_return"
})
public class GetIdResponse {

@XmlElement(name = "return")
protected int _return;

public int getReturn()

{ return _return; }

public void setReturn(int value)

{ this._return = value; }

}






[JAXB-698] There should be a possibility to specify "post-construct" code. Created: 09/Oct/09  Updated: 12/Apr/11

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

Type: New Feature Priority: Major
Reporter: converginglight Assignee: Martin Grebac
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 698

 Description   

There should be a possibility to specify code, which JAXB would call after an
object was unmarshalled (after all fields were set, so that method could use
them). It is not possible to achieve this using the ctor.

This functionality could be made available either by a new annotation
(@XmlPostConstruct or something).

Please see this resource for a possible workaround:
http://stackoverflow.com/questions/1545478/is-there-something-like-postconstruct-for-jaxb-annnotated-classes/1545867#1545867



 Comments   
Comment by converginglight [ 09/Oct/09 ]

Sorry for the typo in description:

There should be a possibility to specify a "post-construct" method, which JAXB
would call after an object was unmarshalled
(after all fields were set, so that the "post-construct" method could use them).
It is not possible to achieve this using the ctor.

Comment by skaffman [ 09/Oct/09 ]

This is a great idea, and is exactly what the standard @PostConstruct annotation
is intended for.

Comment by Pavel Bucek [ 11/Oct/09 ]

isn't this exactly what does afterUnmarshal method? Try adding

public void afterUnmarshal(Unmarshaller u, Object parent)

{ // do something }

to your java class..

Comment by converginglight [ 11/Oct/09 ]

In my opinion, a special annotation would be much more handy:

1) Much less code to write

2) More straightforward, more obvious code

Comment by Pavel Bucek [ 11/Oct/09 ]

ad 1) much less code? annotation + method is less than method?

ad 2) maybe, but JAXB provides four "callbacks": beforeMarshal, afterMarshal,
beforeUnmarshal and afterUnmarshal. There are no annotations for others and I
think providing two ways to call only one callback could be misleading.

And additionally -
http://java.sun.com/javaee/5/docs/api/javax/annotation/PostConstruct.html says
that PostConstruct is meant for classes which use dependency injection and this
is not the case AFAIK (Unmarshalling is not considered as injection).

Comment by converginglight [ 11/Oct/09 ]

No, I mean: you don't have to write the listener class,
which is a lot of "saving":
(The 'real' implementation might be even bigger.)

public class CustomListener
extends Unmarshaller.Listener {

@Override
public void afterUnmarshal(Object object, Object arg1) {
System.out.println("unmarshalling finished on: " + object);

Class<?> type = object.getClass();
Method postConstructMethod = null;

for (Method m : ReflectionUtils.getAllMethods(type)) {
if (m.getAnnotation(PostConstruct.class) != null) {
if (postConstructMethod != null)

{ throw new IllegalStateException( "@PostConstruct used multiple times"); }

postConstructMethod = m;
}
}

if (postConstructMethod != null) {
System.out.println("invoking post construct: "
+ postConstructMethod.getName() + "()");

if (!Modifier.isFinal(postConstructMethod.getModifiers()))

{ throw new IllegalArgumentException("post construct method [" + postConstructMethod.getName() + "] must be final"); }

try

{ postConstructMethod.setAccessible(true); postConstructMethod.invoke(object); }

catch (IllegalAccessException ex)

{ throw new RuntimeException(ex); } catch (InvocationTargetException ex) { throw new RuntimeException(ex); }

}
}
}

Comment by Pavel Bucek [ 11/Oct/09 ]

You don't need to write Listener class when you use (JAXB) life cycle methods,
they are discovered automatically..

Comment by converginglight [ 12/Oct/09 ]

I couldn't find usable information about JAXB's "life cycle methods". Could you
tell more specific, what you mean?

Comment by Pavel Bucek [ 13/Oct/09 ]

It's defined in jsr222:

http://jcp.org/en/jsr/detail?id=222

Comment by converginglight [ 16/Oct/09 ]

I read the PDF of that JSR.
Could not find a word about life cycle methods.
(Perhaps some synonym is used?)

Please, explain what you mean.

Comment by flb_at_ll [ 24/Feb/10 ]

If I understand things correctly, afterUnmarshal will be called after the
document has been fully unmarshalled.

What I think is needed is the ability to operate on objects as they are created.
More important to me would be able to transform an object into a child wrapper
class before the bind/resolve call. Unfortunately, bind is called before the
object members have been fully populated, so all re-wrapping must occur after
unmarshal which means having to walk the entire document tree and update all
references to a re-wrapped object.





[JAXB-690] JAXBResult cannot be initialized with target type Created: 16/Sep/09  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 690

 Description   

If I want to unmarshal an XML document on to a class that doesn't have the
@XmlRootElement annotation, then I can use unmarshaller.unmarshal(source, Class)
to tell it which type to bind to, and it'll return me a JAXBElement for that type.

However, if I want to use JAXBResult to pipe a transform on to the same type, I
have no such option. JAXBResult gets a UnmarshallerHandler from the
Unmarshaller, but there's no mechanism for passing in the target type. And so,
JAXBResult can only target @XmlRootElement-annotated clases, which severely
limits its usefulness.

WOuld it be possible to have JAXBResult modified so that I can construct it with
a JAXBContext, plus a target type?

JAXBResult result = new JAXBResult(context, MyClass.class);
// perform transform on to result
JAXBElement<MyClass> output = result.getResult();



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

This requires api change, changing subcomponent.





[JAXB-683] Unmarshaller does not use results of validation Created: 31/Aug/09  Updated: 15/Apr/11

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

Type: Improvement Priority: Major
Reporter: Thomas De Smedt Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 683

 Description   

As a work-around for issue https://jaxb.dev.java.net/issues/show_bug.cgi?id=515,
I instructed the unmarshaller to use validation ( using setSchema() ), hoping
that the validation process enhances the xml content with the missing fixed (or
default) attribute values.
This does not work, because internally, the validation and unmarshalling pipes
are parallel instead of sequential (see
com.sun.xml.bind.v2.runtime.unmarshaller.ValidationUnmarshaller).

If i set up the sax-streams manually, connecting the output of validation to the
unmarshaller, the enhancement does work:
----------------
InputStream xmlStream = ...
Source xmlSource = new StreamSource(xmlStream);
JAXBContext ctx = ...
Schema schema = ...

UnmarshallerHandler uh = ctx.createUnmarshaller().getUnmarshallerHandler();
ValidatorHandler vh = schema.newValidatorHandler();
// send output of validation to the jaxb unmarshaller
vh.setContentHandler(uh);

TransformerFactory tf = TransformerFactory.newInstance();
// use an identity transformation to stream to the validating handler
tf.newTransformer().transform( xmlSource , new SAXResult(vh));

JAXBElement<?> result = (JAXBElement<?>) uh.getResult();
--------------------------

Could the com.sun.xml.bind.v2.runtime.unmarshaller.ValidationUnmarshaller be
modified to use the output of validation as input for the unmarshalling?



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

Interesting idea. Perhaps we could come up with a property for this?





[JAXB-682] FAQ answer on CDATA uses deprecated solution Created: 25/Aug/09  Updated: 12/Apr/11

Status: Open
Project: jaxb
Component/s: docs
Affects Version/s: 2.1.12
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 682

 Description   

https://jaxb.dev.java.net/faq/index.html#marshalling_cdata suggests using
Apache Xerces-J XMLSerializer, which is deprecated as of version 2.9.

Is there another method of achieving the same results that isn't deprecated?



 Comments   
Comment by tjstavenger [ 05/Nov/09 ]

Xerces-J offers the following replacements for the classes in the
org.apache.xml.serialize package:
http://xerces.apache.org/xerces2-j/faq-general.html#faq-6

However, from what I can tell, neither the LSSerializer nor the Transformer
classes fit well into the JAXB API. In particular, neither implement the
ContentHandler interface to change the text elements to CDATA while marshalling.

This leaves an implementation with two options:

1. Use the Sun internal implementation at com.sun.org.apache.xml.internal.serialize

2. Use the deprecated Xerces-J implementation

Neither of which are good solutions long-term.





[JAXB-679] generateIsSetMethod generates dangerous boolean code Created: 17/Aug/09  Updated: 12/Apr/11

Status: Reopened
Project: jaxb
Component/s: spec
Affects Version/s: 2.1.12
Fix Version/s: 2.3

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

Operating System: All
Platform: All


Issuezilla Id: 679

 Description   

xjc generates code that does not properly autobox when 'generateIsSetMethod' is
used. I reported this for integers as issue 667, but that could be worked around
with an isSet method. However, booleans do not get an isSet method!

Generated code:

@XmlAttribute(name = "includeChildren")
protected Boolean includeChildren;

With generateIsSetMethod:
public boolean isIncludeChildren()

{ return includeChildren; }

Without:
public Boolean isIncludeChildren() { return includeChildren; }

 Comments   
Comment by Martin Grebac [ 20/Aug/09 ]

Please see 131. We cannot fix this as we have to maintain backward compatibility.

      • This issue has been marked as a duplicate of 131 ***
Comment by lucasmo [ 20/Aug/09 ]

I do not believe this is a duplicate of issue 131. Issue 131 reports as a bug
that isIncludeChildren returs a Boolean. I am reporting the opposite: that it's
a bug for it to return boolean. This Boolean return is the default behavior,
which should be used.

The bug here is when the extension 'generateIsSetMethod' is used, it turns on
some rather undocumented side effects; for instance, the signature turns to
boolean, not Boolean. If this was a resolution for 131, it was undocumented.

The problem with this is - when generateIsSetMethod is used - is that there is
NO POSSIBLE WAY to look at your xml boolean values without using
introspection. Calling object.isIncludeChildren() should not throw a NPE under
any circumstances.

Comment by Martin Grebac [ 11/Sep/09 ]

Ah, I see what you mean. The trouble is the spec specifies the method signature
to be specifically "boolean", and we can't change the signature because there
might be code out there which relies on it.

Fixing this requires update to the spec itself. I'll mark 667 as a duplicate of
this one, as both should be fixed at once.

Comment by Martin Grebac [ 11/Sep/09 ]
      • Issue 667 has been marked as a duplicate of this issue. ***




[JAXB-677] @XmlRootElement should allow stylesheet declarations Created: 14/Aug/09  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 677

 Description   

I'd love to specify a stylesheet for an @XmlRootElement without having to mess around with the
marshaller. For instance, it would be great to have something like:

@XmlStylesheet(type="text/css" href="stylesheet.css")

That would generate:
<?xml-stylesheet type="text/css" href="resource.css"?>

This is interesting in the JAX-RS world as it would give developers a way to support HTML requests of XML
data with little effort.



 Comments   
Comment by Pavel Bucek [ 14/Aug/09 ]

marking as enhancement





[JAXB-670] JavaType/hasNsContext not supported Created: 23/Jul/09  Updated: 16/Sep/09

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

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

Operating System: All
Platform: All


Issuezilla Id: 670

 Description   

The Customization property JavaType/hasNsContext is not supported. I did not
check, whether this property is still in the specification, but it was in the
specification for JAXB 1, and its still documented, for example on

https://jaxb.dev.java.net/nonav/2.0/binding-customization/
(JAXB Customization Reference)

or

http://java.sun.com/javaee/5/docs/tutorial/doc/bnbbf.html#bnbbv
(Java EE 5 tutorial)

so I was hoping that this attribute would still be valid.

Setting this property to true or false, doesn't affect the generated sources at
all. The defect seems to be by design, because the implementation of JavaType
works by creating an implementation of XmlAdapter and this interface offers no
possibility to obtain an NsContext.

If there is no other possibility, it would help to have at least a workaround.
For example, I could imagine that the RI allows to obtain an NsContext from some
ThreadLocal variable, or something like that.



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

Interesting. It's certainly not in the spec itself. I'll check with Kohsuke on
this one. Thanks for bringing this up.

Comment by kohsuke [ 15/Sep/09 ]

Indeed this was removed from 2.0, for the reason you discovered by yourself.

Exposing NamespaceContext through the unmarshaller would be useful.

Comment by Martin Grebac [ 16/Sep/09 ]

Thanks for info, changing to enhancement.





[JAXB-655] Default ValidationEventHandler fails to terminate on Error Created: 18/Jun/09  Updated: 18/Jun/09

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

Type: Task Priority: Major
Reporter: darran_lofthouse Assignee: jaxb-issues
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File UnmarshallerImpl.patch    
Issuezilla Id: 655

 Description   

According to the following Javadoc when the default ValidationEventHandler is in
use unmarshalling should terminate on the first Error or fatal error.

http://java.sun.com/javaee/5/docs/api/javax/xml/bind/Unmarshaller.html#setEventHandler%28javax.xml.bind.ValidationEventHandler%29

The current default only terminates unmarshalling on a fatal error.



 Comments   
Comment by darran_lofthouse [ 18/Jun/09 ]

Created an attachment (id=312)
Proposed patch





[JAXB-658] XJC Ant Task doesn't support episode attribute Created: 22/Jun/09  Updated: 11/Jan/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 658

 Description   

The XJC command-line tool will generate an episode file if specified. The
corresponding ant task has no such facility. It should.



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

Thanks for catching this. Changing to enhancement, reassigning to myself.





[JAXB-629] Add support for episode file generation to maven schemagen plugin Created: 01/Apr/09  Updated: 01/Apr/09

Status: Open
Project: jaxb
Component/s: maven-plugin
Affects Version/s: 2.1.3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: clecompt Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 629

 Description   

Along with releasing this plugin for JAXB 2.1 (the 1.3 artifact version from
CVS) is needed support for an episode parameter for the plugin. I have a patch
that I could submit for this that simply adds the episode parameter to the
SchemaGenAdapter and SchemaGenMojo respectively.






[JAXB-624] control over min occurs of choice Created: 25/Mar/09  Updated: 25/Mar/09

Status: Open
Project: jaxb
Component/s: schemagen
Affects Version/s: 2.1.9
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: tuomas_kiviaho Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 624

 Description   

There seem to be no way to have control over min occurs of choice.

I propose an additional 'required' attribute for both XmlElements/XmlElementRefs
similar to what XmlElementRef was given in issue 389.

Schemagen seems to take care of the max occurs already also for parametric types
even above size 1 though the spec. prohibits it for some reason from XmlElements






[JAXB-609] propose plugin for adding "implements X" to generated class Created: 10/Mar/09  Updated: 23/Jan/11

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

Type: Improvement Priority: Major
Reporter: laune Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File IfAddPluginImpl.java    
Issuezilla Id: 609

 Description   

The plugin shall process a bindings extension
<addImplements check="<bool>">className...</addImplements>
which names interfaces, to be added after "extends" in the header of the
class the customization is attached to. If check is true, the plugin
diagnoses an error, if

  • the class is not in scope
  • it is not an interface
  • the class it pertains to does not implement the interface

For instance:
<jxb:bindings node="//xs:complexType[@name='PurchaseOrderType']">
<ai:addImplements check="1">
bar.Foo
foo.Bar
</ai:addImplements>
</jxb:bindings>

Rationale:

  • Attaching interfaces simplifies the processing of elements from different
    complexTypes with common sets of subelements.
  • Use methodless interfaces as "markers"


 Comments   
Comment by laune [ 10/Mar/09 ]

Created an attachment (id=290)
implementation of proposed plugin

Comment by lexi [ 23/Jan/11 ]

http://confluence.highsource.org/display/J2B/Inheritance+plugin





[JAXB-599] Removing JAXBElement from generated code (and I already using simplemode:on) Created: 09/Feb/09  Updated: 09/Feb/09

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

Type: Improvement Priority: Major
Reporter: peterschnitzel Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 599

 Description   

Hi JAXB-Team!

I've spent quite a bit of time looking around, but haven't found an answer to
this question.

I'm trying to create some usable classes out of the Google KML Schema found here:
http://schemas.opengis.net/kml/2.2.0/
You could find all relevant files here:
http://mirror.micromata.de/attachments/kmlsimpleon.zip

JAXB produces many many JAXBElements, for example like here in the DocumentType
Class:
[code]
public class DocumentType extends … {
@XmlElementRef(name = "AbstractFeatureGroup", namespace =
"http://www.opengis.net/kml/2.2", type = JAXBElement.class)
protected List<JAXBElement<? extends AbstractFeatureType>>
abstractFeatureGroups;
…

public List<JAXBElement<? extends AbstractFeatureType>>
getAbstractFeatureGroups()

{ ... }

}
[/code]

But what I would really like is for JAXB to map my XML list to a Java List that
is not a list of JAXBElements, like:
[code]
public class DocumentType extends … {
public List<ConfigurationObject> getConfigObject()

{…}

protected List<AbstractFeatureType> abstractFeatureGroups;
…

public List<JAbstractFeatureType> getAbstractFeatureGroups()

{ ... }

}
[/code]

This mapping would be much more useful for me and it wouldn't result in all of
my application code needing to import JAXB types.

Does anyone know if this is possible? I have played around with customizations
and tried to change the Java code that JAXB generates, but have not been successful.

With simple off I count via search all 267 JAXBElements in the ObjectFactory
and with simple on I count via search all only 256 JAXBElements in the
ObjectFactory (as rough estimate for the total JAXBElement occurence)

Could some make the simplemode:on more aggressive? To get rid off all
JAXBElements (It's just to hard, to remove all JAXBElement by hand, like wrote
here: http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html)

Thanks in advance,
Flori

PS: My Jaxb-version is from the nightly/trunk (Tuesday, January 27, 2009 at
9:53:57 AM)
PPS: My binding/customization file looks like this:
[code]
<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.1"
xmlns:xjc= "http://java.sun.com/xml/ns/jaxb/xjc"
jaxb:extensionBindingPrefixes="xjc">
<jaxb:globalBindings generateMixedExtensions="true" >
<xjc:simple/>
</jaxb:globalBindings>

<jaxb:bindings schemaLocation="ogckml22.xsd" node="/xs:schema">
<xjc:simple/>
<jaxb:schemaBindings>
<jaxb:package name="net.opengis.kml.v_2_2_0" />
</jaxb:schemaBindings>

<!-- bind the 'Snippet' attribute to Java 'ASnippet' -->
<jaxb:bindings node="//xs:element[@name='snippet']">
<jaxb:class name="ASnippet" />
<jaxb:property name="ASnippetProperty" />
</jaxb:bindings>

<!-- bind the 'Link' attribute to Java 'ALink' -->
<jaxb:bindings node="//xs:element[@name='Link']">
<jaxb:property name="ALink" />
</jaxb:bindings>

<!-- bind the 'Scale' attribute to Java 'AScale' -->
<jaxb:bindings node=".//xs:element[@name='scale']">
<jaxb:class name="AScale" />
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
[/code]






[JAXB-600] JAXBContext.newInstance(Class..., ClassLoader) missing? Created: 11/Feb/09  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 600

 Description   

Hi folks,
I need to define my own Classloader, and because in the JAXB-API is no method like:
public static JAXBContext newInstance(Class..., ClassLoader)

and only one like:
public static JAXBContext newInstance(String, ClassLoader)

is it possible to add a newInstance(Class..., ClassLoader)-method
or could somebody explain me, what I have to do,
the following example code will run:

JAXBContext ctx;
//works perfectly for me!
ctx = JAXBContext.newInstance(HelloWorld.class);

//says: "package org.mypackage" doesnt contain ObjectFactory.class or jaxb.index"
ctx = JAXBContext.newInstance("org.mypackage");

//says: "package org.mypackage" doesnt contain ObjectFactory.class or jaxb.index"
ctx = JAXBContext.newInstance(HelloWorld.class.getPackage().toString());

//something like this would be nice
ctx = JAXBContext.newInstance(HelloWorld.class, this.getClass().getClassLoader());

is it possible to resolve the "package org.mypackage" doesnt contain
ObjectFactory.class or jaxb.index" automatically or to provide an
newInstance(Class..., ClassLoader)-method, because this would fit the best and
make the create the JAXBContext.newInstance()-process more chubbier.

regards
Flori






[JAXB-593] classes in package com.sun.tools.xjc.generator.bean.field public Created: 20/Jan/09  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 593

 Description   

Could you make all the final classes in the
package com.sun.tools.xjc.generator.bean.field
public, too?
(I have done this already locally and produced the new jars).

This could be useful for Plugin development if you would like to check if a
field has a const modifier.
like:

for (FieldOutline fieldOutline : classOutline.getDeclaredFields()) {
if (fieldOutline instanceof ConstField)

{ System.out.println("field is const " + fieldOutline.getPropertyInfo().getName(false)); }

}

Or is there a better way, to get any detailed type and modifier informations
about a field or a collection?



 Comments   
Comment by florianbachmann [ 20/Jan/09 ]

and could AbstractListField and AbstractFieldWithVar be final too?

Then I could easily check, wheter the declaredFieldType is a primitive or an
Collection

Comment by florianbachmann [ 20/Jan/09 ]

ah.. sorry. I meant public!

and could AbstractListField and AbstractFieldWithVar be public too?

now it should be correct.

Comment by Pavel Bucek [ 20/Jan/09 ]

-> enhancement

We won't make all classes in that package public. I will try to find out better
solution.

Comment by florianbachmann [ 16/Nov/09 ]

any possible solution in sight?





[JAXB-577] Need a way to map a root complexType to extend a specified class Created: 10/Dec/08  Updated: 12/Apr/11

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

Type: New Feature Priority: Major
Reporter: najmi Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 577
Tags: incomplete

 Description   

This issue seems to be in the cracks bwteen JAXB and JAXWS.

See details in:

<http://www.nabble.com/How-to-specify-base-type-for-a-complexType-td20937985.html>

The root use case I am trying to address is how to design a WSDL to support
inheritance of SOAP Faults:

<http://www.nabble.com/SOAP-Fault-inhertiance-in-WSDL-td20928274.html>

I can provide a test case if needed.



 Comments   
Comment by najmi [ 10/Dec/08 ]

Changed title to be more generic.

Comment by Martin Grebac [ 12/Apr/11 ]

Would you please provide the testcase so that I understand better what do you request? Thanks.





[JAXB-579] Add the ability to exclude namespaces from code generation Created: 11/Dec/08  Updated: 15/Aug/13

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

Type: Improvement Priority: Major
Reporter: kitfox Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 579

 Description   

I'm writing a complex program that splits its work into multiple projects. Each
project produces a jar, some of which depend on classes supplied by other jars.
Let's call these projects A, B and C, where A and B use classes defined in C.

Now C defines a schema core.xsd. B defines a schema beta.xsd which imports
core.xsd. And A defines alpha.xsd which also imports core.xsd. Each of these
schemas have different namespaces.

I'd like to generate JAXB code for each of these projects, but am running into
the problem that all three projects generate their own copy of the classes
described by core.xsd. I can't generate all the JAXB in only one project, since
all projects need access to the produced code. I also can't create a special
project that contains only JAXB code since I may not have access to all projects
at compile time (I'm designing a plugin architecture, so A will not necessarily
even exist at the time the core classes are compiled and distributed).

Ideally I would be able to generate core.xsd classes and compile them into
C.jar. When JAXB classes are generated for B.jar and A.jar, they would realize
that these classes already exist in another project and not create duplicates.

This could be done by adding a binding that lets me suppress generation of
classes for specified namespaces. I could set this binding when running xjc on
my A and B projects.

You could also likely implement this by allowing the user to specify per
namespace which directory (not just package name) binding code is generated to.
Then the compiler could check to see if the generated code already exists.



 Comments   
Comment by tastle [ 15/Aug/13 ]

I believe this is the same problem faced in the OGC JAXB Schemas project also hosted here at java.net. After XJC runs, the unnecessary generated sources (normally matches the episode files fed into it) are being deleted by a Maven Ant Plugin. This is a undesirable work around.

Now I'm running into this same case with another project.





[JAXB-568] Implement setter method for collection properties Created: 17/Nov/08  Updated: 11/Jan/11

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: JWSDP1.6 (JAXB1.0.5)
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: samplez Assignee: jaxb-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 568

 Description   

When copying properties between beans (with dynamic-property-discovery tools
like Apache Bean Utils), the collection properties of JAXB generated beans are
not handled correctly. This is because the JAXB generated beans do not have a
setter method for collection properties.

Is it possible to implementd something like this?:

Bean {
...
public void setItems(List items)

{ getitems().addAll(items); }

}






[JAXB-552] Replace fastBoot system property with proper API Created: 23/Sep/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 552

 Description   

A feature was added to JAXB-RI 2.0.4 where a system property "fastBoot" could be
set, which would improve startup performance of JAXBContext.newInstance() at the
expense of runtime performance. This works nicely, but a system property is an
unpleasant way of doing it.

When Kohsuke put this in, he intended to replace the system property with a
proper API at some point, but this never materialised. Can it be added now?






[JAXB-550] Single JAXB context to unmarshall XML to multiple subclasses based on namespace Created: 16/Sep/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 550

 Description   

Let S be a superclass for classes C1 and C2 that are representing a concrete
instances of different XML elements E1 and E2. I would like to be able to
configure a single JAXBContext instance that would be able to create an
Unmarshaller capable of properly unmarshalling elements E1 and E2 into classes
C1 and C2 into a provided variable of type S.

Real life scenario:
EndpointReference epr = unmarshaller.unmarshall(...);

The code above should correctly unmarshall the XML element into either
W3CEndpointReference or MemberSubmissionEndpointReference instance based on the
actual namespace of the XML element.






[JAXB-543] Why @XmlID must be a String ? Created: 21/Aug/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JAXB-806 Allow @XmlID on non-String property i... Resolved
Issuezilla Id: 543

 Description   

Hi,

I need to serialize some EJB3 entities which have and numeric java.lang.Long id.
The identifier of an entity is annotated with @Id for JPA ant with @XmlId
but on runtime, the following exception occur :

Property "id" has an XmlID annotation but its type is not String.

Why this limitation ?
Why not call the "toString()" method of the id field ?

Thank you.
Stéphane






[JAXB-528] xjc:superClass in schema scope Created: 09/Jul/08  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 528
Tags: incomplete

 Description   

I think to allow xjc:superClass customization in schema scope, ie. on
<schemaBindings/> would be a useful enhancement when compiling multiple
schemata.
See http://forums.java.net/jive/thread.jspa?threadID=42963



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

Do you by any chance still have a testcase or better description of what you'd like to achieve? Unfortunately, we lost the forum links during migration.





[JAXB-524] I18N-JAXWS:MBCS of generated WSDL/XSD from JAX-WS webservice are converted to Numeric character reference Created: 07/Jul/08  Updated: 23/Aug/11

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

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

Operating System: All
Platform: All
URL: http://bugs.bea.com/WebClarify/CREdit?CR=CR370656


Attachments: PNG File HO13256_screenshotOfWSDL.PNG    
Issuezilla Id: 524

 Description   

If JAX-WS webservice includes MBCS (Multi-Byte Character Set) of its contents,
such like package name,
webservice name, method name and so on., generated WSDL/XSD files of MBCS are
converted to Numeric character reference for
example "http://テストpack/". User might be blocked to edit
the WSDL or XSD file from Source view.

BEA Webservices tool use JAXB RI 2.1.7, it needs an I18N enhancement on JAXB RI
2.1.7.

I debug into txw2 source code while generating a WSDL from java which target
namespace content includes MBCS. com.sun.xml.txw2.output.StreamSerialize
creates DataWriter using DumbEscapeHandler which escapes everything above the
US-ASCII code range. If writing xml docuemnt with UTF-8 encoding declaration it
should be considered to preserve MBCS. Alternatively, the I18N enhancement can
be disabled as default and a customizing I18N option (API or system property?)
is provided to enable it.

Please feel free to contact me at lali@bea.com if you have any question.



 Comments   
Comment by longlee [ 07/Jul/08 ]

Created an attachment (id=260)
the screenshot of numeric unicode reference





[JAXB-523] Binder.marhsal does not keep associations Created: 02/Jul/08  Updated: 22/Nov/11

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

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

Operating System: All
Platform: All


Attachments: Java Source File JaxbIssue523.java    
Issuezilla Id: 523
Tags: metro2_1-waived, metro2_2-waived

 Description   

The current implementation of Binder.marhshal (actually BinderImpl.marshal) does not keep the
associations it is required to by the API specification. A proper implementation is required when doing
multiple round trip updates (e.g. XML->JAXB->XML->JAXB)



 Comments   
Comment by Pavel Bucek [ 14/Jan/09 ]

Could you please provide a test case to this issue?

Comment by Pavel Bucek [ 29/Jan/09 ]

marking as incomplete

Comment by pkelchner [ 30/Mar/10 ]

Created an attachment (id=353)
Testcase to reproduce issue

Comment by pkelchner [ 31/Mar/10 ]

The issue arises because com.sun.xml.bind.v2.runtime.output.DOMOutput adds the
marshalled object as both the outer and the inner peer (I don't actually know
the meaning of outer and inner peer in this context).

com.sun.xml.bind.v2.runtime.AssociationMap in turn first adds the outer peer
normally, but completely removes the association from its internal maps when it
is added again as the inner peer, because old entries get removed from the
internal maps after new entries have been added, but in this case they have the
same keys.

Either it is wrong to associate the same object as both outer and inner peer or
AssociationMap falsely assumes an object will never be both outer and inner peer.

Comment by Martin Grebac [ 06/Oct/10 ]

reassigning

Comment by Martin Grebac [ 06/Oct/10 ]

reproduced, assigning TM

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived





[JAXB-522] Binder incorrectly handles ID/IDREF Created: 02/Jul/08  Updated: 04/Feb/09

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

Type: Improvement Priority: Major
Reporter: kdubb Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 522

 Description   

I am using Binder<Node> to do partial conversion of my document and
ID's and IDREF's are not working correctly; I believe the problem is a scope issue. I am unmarshaling a
portion of the document that contains an IDREF and its associated ID is located outside of the portion I
am converting. The Validator seems to believe that where binding started is effectively the root of the
document.

When working with large documents it is imperative that this works correctly so that only the small
portion of the document that is actually used needs to be bound at any one time.

I believe the document needs to be scanned (using the schema if possible) to find all of the ID fields
and cache them without binding the whole document.



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

marking as enhancement





[JAXB-515] Default and fixed fields not generated correctly when using restriction to create new types. Created: 16/Jun/08  Updated: 12/Sep/09

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

Type: Improvement Priority: Major
Reporter: rupertlssmith Assignee: jaxb-issues
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=42439&tstart=0


Attachments: Text File xsdrestrictiontest.tar.gz    
Issuezilla Id: 515

 Description   

If restriction is used to derive a new complex type from an existing type, and
attributes are restricted by having a default or fixed value specified, where
none was previously specified on the base type, then the xjc compiler fails to
create the default or fixed value. It does manage to do it for default or fixed
values on the base type itself.

I've cut this down to a simple example to illustrate. Here is my schema (test.xsd):

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:test="http://thebadgerset.co.uk/test-0.1"
targetNamespace="http://thebadgerset.co.uk/test-0.1"
elementFormDefault="qualified">

<xs:element name="test" type="test:B"/>

<xs:complexType name="A">
<xs:attribute name="fixedInRoot" type="xs:string" fixed="fixedValue"/>
<xs:attribute name="fixedByOverride" type="xs:string"/>
<xs:attribute name="defaultInRoot" type="xs:string" default="defaultValue"/>
<xs:attribute name="defaultOverride" type="xs:string"/>
<xs:attribute name="defaultOverrideByFixed" type="xs:string"
default="defaultValue"/>
</xs:complexType>

<xs:complexType name="B">
<xs:complexContent>
<xs:restriction base="test:A">
<xs:attribute name="fixedByOverride" type="xs:string" fixed="fixedValue"/>
<xs:attribute name="defaultOverride" type="xs:string" default="newDefaultValue"/>
<xs:attribute name="defaultOverrideByFixed" type="xs:string" fixed="fixedValue"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

</xs:schema>

Here is a sample data file to test this with (test.xml):

<test xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://thebadgerset.co.uk/test-0.1 test.xsd"
xmlns="http://thebadgerset.co.uk/test-0.1"/>

Here is my bindings file (test.xjb):

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

<bindings schemaLocation="test.xsd" node="/xsd:schema">

<globalBindings>
<xjc:serializable/>
</globalBindings>

<schemaBindings>
<package name="uk.co.thebadgerset.xsdrestrictiontest"/>
</schemaBindings>

</bindings>

</bindings>

Here is my main method:

public static void main(String[] args)
{
try
{
// Create an unmarshaller.
JAXBContext jc = JAXBContext.newInstance("uk.co.thebadgerset.xsdrestrictiontest");
Unmarshaller u = jc.createUnmarshaller();

// Set the schema on the unmarshaller.
SchemaFactory schemaFactory =
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema sedaSchema =
schemaFactory.newSchema(Main.class.getClassLoader().getResource("test.xsd"));
u.setSchema(sedaSchema);

// Unmarshall the test file.
Reader configReader = new
InputStreamReader(Main.class.getClassLoader().getResourceAsStream("test.xml"));
JAXBElement<? extends B> element = (JAXBElement<? extends B>)
u.unmarshal(configReader);
B b = element.getValue();

// Check what values have been set for fixed and default fields.
System.out.println("b.getFixedByOverride() = " + b.getFixedByOverride());
System.out.println("b.getFixedInRoot() = " + b.getFixedInRoot());
System.out.println("b.getDefaultInRoot() = " + b.getDefaultInRoot());
System.out.println("b.getDefaultOverride() = " + b.getDefaultOverride());
System.out.println("b.getDefaultOverrideByFixed() = " +
b.getDefaultOverrideByFixed());
}
catch (Exception e)
{
e.printStackTrace();
}
}

The schema is compiled into classes 'A' and 'B' by xjc, I'm using latest
released version 2.1.7.

Here is the output:

b.getFixedByOverride() = null
b.getFixedInRoot() = fixedValue
b.getDefaultInRoot() = defaultValue
b.getDefaultOverride() = null
b.getDefaultOverrideByFixed() = defaultValue

What you can see from this, is that the fixed and defaulted attributes in the
base type 'A' are correctly fixed and defaulted. When I override them by
restriction to create a new type 'B' the new fixed or defaulted values are not
provided by the class B.

Seems to me that the 'get*' methods in A that B alters, could override the
methods in 'A' to provide the fixed or defaulted values that I want.

I have attached an archive with an example for this bug to the forum topic:

http://forums.java.net/jive/thread.jspa?threadID=42439&tstart=0

You should be able to build and run it with:

> mvn clean assembly:assembly
> java -cp target/xsdrestrictiontest-0.1-SNAPSHOT-all-test-deps.jar
uk.co.thebadgerset.xsdrestrictiontest.Main



 Comments   
Comment by rupertlssmith [ 16/Jun/08 ]

Created an attachment (id=256)
The example described in the bug report.

Comment by Pavel Bucek [ 15/Dec/08 ]

not in current scope of work, changing to ENHANCEMENT

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

see https://jaxb.dev.java.net/issues/show_bug.cgi?id=683 for a workaround through
validation





[JAXB-512] "trying to create the same field twice" error doesn't report line number Created: 06/Jun/08  Updated: 30/Aug/11

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

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

Operating System: All
Platform: All
URL: http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#CDA_Schema


Issue Links:
Dependency
blocks JAXB-508 Better error reporting of conflicts Resolved
Issuezilla Id: 512

 Description   

Try downloading all of the XML Schema files from the web page linked above and
then run xjc on CDA.xsd to generate the equivalent Java code. It will fail with
this error.

Exception in thread "main" java.lang.IllegalArgumentException: trying to create
the same field twice: id
at com.sun.codemodel.JDefinedClass.field(JDefinedClass.java:419)
at com.sun.codemodel.JDefinedClass.field(JDefinedClass.java:390)
at com.sun.tools.xjc.generator.bean.field.AbstractFieldWithVar.createField
(AbstractFieldWithVar.java:71)
at com.sun.tools.xjc.generator.bean.field.SingleField.<init>
(SingleField.java:89)
at com.sun.tools.xjc.generator.bean.field.SingleField.<init>
(SingleField.java:76)
at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.tools.xjc.generator.bean.field.GenericFieldRenderer.generate
(GenericFieldRenderer.java:64)
at com.sun.tools.xjc.generator.bean.field.DefaultFieldRenderer.generate
(DefaultFieldRenderer.java:75)
at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl
(BeanGenerator.java:744)
at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody
(BeanGenerator.java:532)
at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:234)
at com.sun.tools.xjc.generator.bean.BeanGenerator.generate
(BeanGenerator.java:174)
at com.sun.tools.xjc.model.Model.generateCode(Model.java:286)
at com.sun.tools.xjc.Driver.run(Driver.java:343)
at com.sun.tools.xjc.Driver.run(Driver.java:191)
at com.sun.tools.xjc.Driver._main(Driver.java:116)
at com.sun.tools.xjc.Driver.access$000(Driver.java:74)
at com.sun.tools.xjc.Driver$1.run(Driver.java:96)

The error message is correct, but not helpful. In all other cases when there is
an error in an XML Schema file, xjc reports the exact line number where the
problem exists. It should also report the line number for a duplicate field
name. That would have made it much easier to identify the underlying problem.
(For a full description see this discussion thread:
http://forums.java.net/jive/message.jspa?messageID=278722 .)



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

exception shall be caught and rethrown with current location

Comment by scarcher2 [ 30/Aug/11 ]

I'm having the same problem. Trying to generate classes from the CDA Schema files.





[JAXB-495] Immutable classes Created: 11/Mar/08  Updated: 11/Mar/08

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

Type: Improvement Priority: Major
Reporter: cedricbr Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 495

 Description   

It is impossible in JAXB 2.1.5 to handle immutable classes, since they do not
have empty constructor and setters.
It is something that blocks me on my project, because I can't modify these
immutable classes to add them empty constructors.

It seems that the Serialization process uses a means to instanciate classes that
don't have constructors. Could this system be used as well for Jaxb ? Or
something else that allows me to annotate my immutable classes ?

Best regards,
Cédric Briançon.






[JAXB-488] compatibility issue with JAXB 2.0 Created: 01/Mar/08  Updated: 26/Feb/13

Status: Reopened
Project: jaxb
Component/s: runtime
Affects Version/s: 2.1.1
Fix Version/s: 2.2.5

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

Operating System: All
Platform: All


Attachments: Zip Archive jaxbtest.zip     GZip Archive listTrouble.tar.gz     GZip Archive workAround.tar.gz     GZip Archive workAround.tar.gz    
Issuezilla Id: 488
Tags: metro2_1-waived

 Description   

The attached test case works with JAXB 2.0, for example with JDK 6 update 1.
The test case is broken when running with JDK 6 update 4 (JAXB 2.1).

see also forum entry:
http://forums.java.net/jive/thread.jspa?threadID=36902&tstart=75



 Comments   
Comment by brands [ 01/Mar/08 ]

Created an attachment (id=245)
junit test case

Comment by dharland [ 26/Mar/08 ]

In our code i noticed that some of our list-based XML unit tests were still
passing. It looks like those that began failing w/ JDK 1.6.0 build 04 deal with
lists whose elements are polymorphic. I have created simplified examples of the
2 basic ways i've dealt w/ such lists and will attach them. If you run them
under JDK 1.6.0 build 02, they should work properly. Under build 04 the
setXxx(List<Xxx> xxx) methods are never called.

Comment by dharland [ 26/Mar/08 ]

Created an attachment (id=248)
Two simplified test cases

Comment by dharland [ 08/May/08 ]

Minor correction to my comments of Mar 26: where i said "build" the proper term
is "update", as in "update 04".

Comment by dharland [ 15/May/08 ]

WORK-AROUND AVAILABLE

My previous diagnosis of polymorphic vs monomorphic was incorrect. As noted in
the forum and in a previously attached example, the setXxx(List<Xxx> xxx) method
is never called in JAXB 2.1.x, whereas it had been called in 2.0.x, and this is
true regardless of the type of object held in the collection.

It looks like JAXB is calling the the getter even when unmarshalling XML into
objects and completely ignoring the setter. That means JAXB is making an
assumption that the getter returns the actual collection instance variable, and
this is a poor assumption to make. An extremely common, and defensive, pattern
for objects that hold collections is:

private List<Bar> bars;

@XmlElementWrapper
@XmlElement(name="bar")
public List<Bar> getBars()

{ return new ArrayList<Bar>(bars); }

We can work around this – w/out losing the ability to hide the real collection
from clients – by making a private method for JAXB's use that returns the real
collection, ala

@XmlElementWrapper(name="bars")
@XmlElement(name="bar")
private List<Foo> getXmlBars()

{ return bars; }

...and removing the xml annotations from the public getBars method.

Even though we can work around the problem, i think the change from 2.0.x to
2.1.x that resulted in not calling setters for collections was a bad one.

In case the above was not clear, i'll attach another example in a minute.

Comment by dharland [ 15/May/08 ]

Created an attachment (id=252)
Shows work-around; clarifies the problem

Comment by dharland [ 15/May/08 ]

Created an attachment (id=253)
USE IN PLACE OF PREVIOUS ATT. Shows work-around; clarifies the problem

Comment by Pavel Bucek [ 12/Feb/09 ]

fixed in trunk

Comment by alexkos [ 12/Feb/09 ]

Pavel,
would you please provide more details about the fix, e.g. does it address all
collections or just lists (I have had the same issue with sets), will JAXB
completely switch back to using collection setters or will there be some
hierarchy of choices (if the setter is not available). I am trying to figure out
if my workaround that relies on JAXB directly manipulating the collection
acquired via the collection getter will break as soon as I switch to the fixed
version of JAXB. Thanks. -Alex

Comment by Pavel Bucek [ 12/Feb/09 ]

Hi Alex,

your workaround won't break - I've only added set invocation after parsing whole
List/Set (any collection).

So whole process starts with invoking get and "clearing" result (as previously)
or creating new instance of collection (when getter returns null). After parsing
all collection items (and adding them to collection) set method is invoked (if
exists).

Pavel

Comment by Martin Grebac [ 29/Jul/10 ]

Note that this was a change against spec - thus we shall add a switch to unmarshaller to allow both
behaviours.

Comment by Martin Grebac [ 29/Jul/10 ]

assigning to pavel

Comment by Pavel Bucek [ 07/Oct/10 ]

updating target milestone

Comment by Pavel Bucek [ 19/Nov/10 ]

metro2.1-waived

Comment by Martin Grebac [ 22/Nov/11 ]

The fix is in 2.2 codebase, marking as such.

Comment by Martin Grebac [ 26/Feb/13 ]

Reopening to implement switch as I mentioned already as the default behaviour does not conform to spec.





[JAXB-464] @XmlAnyElement(lax=true) unmarshalling problem Created: 23/Dec/07  Updated: 23/Jan/08

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

Type: Improvement Priority: Major
Reporter: troydm Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 464

 Description   

This simple test case was working properly on JAXB 2.0 but after switching to
JAXB 2.1 this test case fails. i've tested this on 2.1.6 version of JAXB 2.1
running JDK 1.6.0_3 on Windows XP 32-bit.

Test case itself is simply to understand. the part that is failing is something
@XmlAnyElement public JavaBean property collection that contains data separated
by subclass type. if we refactor Tests class so that it will contain just one
Collection<Test> for storing both types of tests. and remove all type specific
getters and setters so that it's will look simply just like TestRoot. this test
will just pass without problem. in particular there is problem in unmarshalling
data itself @XmlAnyElement data. may be itself this test is not right and
violates JAXB 2.1 specification but it's working fine with JAXB 2.0 .

Here is test itself:

import java.io.Serializable;
import java.io.StringReader;
import java.io.StringWriter;
import java.util.ArrayList;
import java.util.Collection;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.annotation.XmlAnyElement;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlTransient;
import junit.framework.TestCase;

/**
*

  • @author Dima
    */
    public class JAXBUnmarshallingTest extends TestCase {

private TestRoot testRoot = null;

@XmlRootElement(name = "root")
public static class TestRoot {

private Collection<Tests> tests = new ArrayList<Tests>();

@XmlAnyElement(lax=true)
public Collection<Tests> getTests()

{ return tests; }

public void setTests(Collection<Tests> tests)

{ this.tests = tests; }

}

@XmlRootElement(name = "tests")
public static class Tests {

private Collection<TestOfType1> tests1 = new ArrayList<TestOfType1>();
private Collection<TestOfType2> tests2 = new ArrayList<TestOfType2>();

@XmlAnyElement(lax=true)
public Collection<Test> getTests()

{ Collection<Test> tests = new ArrayList<Test>(getTests1().size()+getTests2().size()); tests.addAll(getTests1()); tests.addAll(getTests2()); return tests; }

public void setTests(Collection<Test> tests) {
getTests1().clear();
getTests2().clear();
for(Test test : tests)

{ if(test instanceof TestOfType1) getTests1().add((TestOfType1)test); else if(test instanceof TestOfType2) getTests2().add((TestOfType2)test); }

}

@XmlTransient
public Collection<TestOfType1> getTests1()

{ return tests1; }

public void setTests1(Collection<TestOfType1> tests1)

{ this.tests1 = tests1; }

@XmlTransient
public Collection<TestOfType2> getTests2()

{ return tests2; }

public void setTests2(Collection<TestOfType2> tests2)

{ this.tests2 = tests2; }

}

@XmlRootElement(name="test")
public static class Test implements Serializable {

private String name = null;

@XmlAttribute(name = "name")
public String getName()

{ return name; }

public void setName(String name)

{ this.name = name; }

}

@XmlRootElement(name = "test1")
public static class TestOfType1 extends Test {

private String type = "type1";

@XmlElement(name = "type")
public String getType()

{ return type; }

public void setType(String type) { this.type = type; }
}

@XmlRootElement(name = "test2")
public static class TestOfType2 extends Test {

private String type = "type2";

@XmlElement(name = "type")
public String getType() { return type; }

public void setType(String type)

{ this.type = type; }

}

public JAXBUnmarshallingTest(String testName)

{ super(testName); }

@Override
protected void setUp() throws Exception

{ super.setUp(); testRoot = new TestRoot(); Collection<Tests> tests = new ArrayList<Tests>(); Tests testSet1 = new Tests(); TestOfType1 test1 = new TestOfType1(); test1.setName("test of type 1"); TestOfType2 test2 = new TestOfType2(); test2.setName("test of type 2"); testSet1.getTests1().add(test1); testSet1.getTests2().add(test2); Tests testSet2 = new Tests(); test1 = new TestOfType1(); test1.setName("test of type 1"); test2 = new TestOfType2(); test2.setName("test of type 2"); testSet2.getTests1().add(test1); testSet2.getTests2().add(test2); tests.add(testSet1); tests.add(testSet2); testRoot.setTests(tests); }

@Override
protected void tearDown() throws Exception

{ super.tearDown(); }

public void testUnmarshalling() {
try {
StringWriter sw = new StringWriter();

JAXBContext context = JAXBContext.newInstance(new
Class[]

{TestRoot.class, Tests.class, Test.class, TestOfType1.class, TestOfType2.class}

, null);
Marshaller marshaller = context.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, new
Boolean(true));
marshaller.marshal(testRoot, sw);
System.out.println("Before unmarshallig -----------");
for(Tests tests : testRoot.getTests()){
assertTrue(tests.getTests().size() != 0);
for(Test test : tests.getTests())

{ System.out.println("test name = "+test.getName()); }
}
System.out.println("-------------------------------");
System.out.println(sw.toString());
Unmarshaller unmarshaller = context.createUnmarshaller();
testRoot = (TestRoot)unmarshaller.unmarshal(new
StringReader(sw.toString()));
System.out.println("After unmarshallig -----------");
assertTrue(testRoot.getTests().size() != 0);
for(Tests tests : testRoot.getTests()){
assertTrue(tests.getTests().size() != 0);
for(Test test : tests.getTests()){ System.out.println("test name = "+test.getName()); }

}
System.out.println("-------------------------------");
} catch (JAXBException ex)

{ Logger.getLogger(JAXBUnmarshallingTest.class.getName()).log(Level.SEVERE, null, ex); }

}
}



 Comments   
Comment by kohsuke [ 23/Jan/08 ]

Thanks for the test case. I think I understand the issue now.

JAXB thinks that your "Collection<Test> getTests()" returns the live list, so
what it does during the unmarshalling is that it calls this method to obtain a
list, and then it adds a bunch of stuff to there, and it just leaves this object
to move on to next.

Your code, OTOH, assumes that JAXB will call the "void setTests(Collection<Test>
tests)" method later with a fully filled list, which never happens.

I don't think the spec never really talk about in which order a call should
happen, so this is in a grey zone. Looking at the code, this change was made to
fix a problem where the collection property only defines a getter for a live
list, which is also a common pattern among users.

A relatively easy work around is to use array in get/setTests methods. In this
way JAXB will know that it has to call the setTests method to deliver a filled
array to you, so you get a chance to see the complete Test objects, which you
then classify into two lists that you have.

Beyond that, I wonder what's the best approach to address this. It almost seems
like another call pattern is in order, where JAXB calls addTest(Test) for each
item it finds during unmarshalling, and use getTests() for unmarshalling.





[JAXB-460] Add ability to inject schema documentation annotation into javadoc Created: 20/Dec/07  Updated: 17/Apr/11

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

Type: Improvement Priority: Major
Reporter: davidhoffer2 Assignee: jaxb-issues
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 460

 Description   

JAXB should automatically, or at least optionally, inject my schema
documentation into the JAXB generated javadocs.

E.x.
<xs:annotation> <xs:documentation>Version info for the data in the
file</xs:documentation>
</xs:annotation>



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

Good Idea, relates to issue JAXB-273.





[JAXB-459] Binder.updateXML() fails if called twice Created: 10/Dec/07  Updated: 22/Nov/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 459
Tags: metro2_1-waived, metro2_2-waived

 Description   

(Using 2.1.5) I have a DOM view, and create JAXB representation using Binder.
If I modify a value in the JAXB representation I then call binder.updateXML(o)
to update the DOM representation, firstr time this works correctly but if I do
it again it fails at XmlNode updateXML(Object jaxbObject)

Element e = (Element)xmlNode;
Node ns = e.getNextSibling();
Node p = e.getParentNode();
p.removeChild(e); //Exception thrown on this line

First thought is why should xmlNode even have a sibling ?
Stack trace as follows:

java.lang.NullPointerException
at com.sun.xml.bind.v2.runtime.BinderImpl.updateXML(BinderImpl.java:194)
at com.sun.xml.bind.v2.runtime.BinderImpl.updateXML(BinderImpl.java:182)
at
com.jthink.jaikoz.settings.JaikozPreferences.updateXML(JaikozPreferences.java:71)
at
com.jthink.jaikoz.settings.TrackNoColumnSettings$AutoFormatTrackNoTab.saveChanges(TrackNoColumnSettings.java:130)
at
com.jthink.jaikoz.settings.ApplyButtonListener.actionPerformed(AbstractSettingsDialog.java:446)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:5517)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
at java.awt.Component.processEvent(Component.java:5282)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3984)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3819)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1791)
at java.awt.Component.dispatchEvent(Component.java:3819)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)



 Comments   
Comment by Martin Grebac [ 23/Jul/08 ]

Would you please provide a testcase so that I can make sure the fix addresses
the right thing?

Comment by Martin Grebac [ 23/Jul/08 ]

reassigning

Comment by pydera [ 25/Oct/08 ]

Here is a test case that does not work for me:
I created a very simple XSD and created a Java class out of it via
jaxb-compiler.

JAXBContext ctx = JAXBContext.newInstance(...my package...);
Marshaller m = ctx.createMarshaller();
MyObject obj = new MyObject();