<< Back to previous view

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

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04.2, JDK 1.7.0_21


Tags: jaxb-xjc xjc jaxb catalog binding
Participants: Iaroslav Savytskyi, m_perdikeas and markzimmngc

 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 05:39 PM ]

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





[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
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
Participants: Iaroslav Savytskyi and m_perdikeas

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

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

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

Windows 7 x64; JDK 1.6 and JDK 1.7


Tags:
Participants: donatasc and Iaroslav Savytskyi

 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 08:19 AM ]

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

Comment by Iaroslav Savytskyi [ 29/Jul/13 12:58 PM ]

Hi,

Thanks a lot for reporting.

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





[JAXB-995] Regression: Maven Plugin does not work with JDK 8 Created: 17/Dec/13  Updated: 17/Dec/13

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

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

v2.2.8-b130911.1802
Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b62
Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b120
System: Windows 7 version 6.1 running on amd64; Cp1252; de_CH (nb)


Tags:
Participants: Iaroslav Savytskyi and puce

 Description   

Running with JDK 8 EA b120, the maven plugin stops without any error message at:
"Parsing input schema(s)..."

No files get generated -> Blocker



 Comments   
Comment by puce [ 17/Dec/13 11:55 PM ]

Wrong component and I can't edit it.

I created a new issue: https://java.net/jira/browse/MAVEN_JAXB2_PLUGIN-83





[JAXB-172] More Schema Annotations/Documentation to Javadoc Created: 06/Jun/06  Updated: 20/Oct/13

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: 34
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


File Attachments: XML File test.xsd    
Issue Links:
Duplicate
is duplicated by JAXB-839 More Schema Annotations/Documentation... Resolved
Issuezilla Id: 172
Tags:
Participants: Aleksander Adamowski, dkulp, kohsuke, kpsdevi, marcelstoer, Martin Grebac, os111, skells and vorburger

 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 04:55 PM ]

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

Comment by vorburger [ 21/Jul/06 04:11 AM ]

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

Comment by kohsuke [ 24/Sep/07 10:26 AM ]

Also in this category is javadoc for enumeration values.

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

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 04:39 AM ]

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

Comment by dkulp [ 22/Oct/09 06:13 AM ]

This is also the blocker for a CXF issue:

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

Comment by skells [ 26/Oct/09 06:06 AM ]

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 08:29 AM ]

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 10:04 AM ]

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 02:01 PM ]

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 09:54 AM ]

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 01:40 PM ]

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 01:47 AM ]

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

Comment by Martin Grebac [ 01/Jun/11 02:37 AM ]

Understood, thanks for the clarifications here.

Comment by marcelstoer [ 20/Oct/13 10:13 PM ]

Just found here thanks to a really helpful SO answer.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 379
Tags:
Participants: Martin Grebac, Pavel Bucek and rico_kim

 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 12:56 AM ]
      • Issue 185 has been marked as a duplicate of this issue. ***
Comment by Pavel Bucek [ 05/Nov/09 12:56 AM ]
      • Issue 559 has been marked as a duplicate of this issue. ***
Comment by Pavel Bucek [ 05/Nov/09 12:57 AM ]
      • Issue 710 has been marked as a duplicate of this issue. ***
Comment by Martin Grebac [ 15/Apr/11 06:26 AM ]

increasing priority to better evaluate the needs here





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


File Attachments: Zip Archive test_case.zip    
Issuezilla Id: 404
Tags:
Participants: afedoro, kohsuke and Martin Grebac

 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 02:45 PM ]

Created an attachment (id=194)
Test Case

Comment by kohsuke [ 22/Aug/07 09:02 AM ]

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 10:55 AM ]

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 12:55 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 509
Tags:
Participants: jkjome and Martin Grebac

 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 06:20 AM ]

raising priority so that I look at it





[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
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
Participants: Martin Grebac and najmi

 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 07:07 AM ]

Fixed typo

Comment by Martin Grebac [ 28/Jul/08 04:52 AM ]

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

Comment by Martin Grebac [ 06/Oct/10 02:06 AM ]

reassigning





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

Status: In Progress
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: 20
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Zip Archive jaxb_episode.zip     Text File jaxb_episode.zip     Text File jaxb_episode.zip    
Issuezilla Id: 514
Tags:
Participants: cedric.vidal, euxx, fribeiro, Iaroslav Savytskyi, jahutton, marcelcasado, Martin Grebac, Michael Osipov, Pavel Bucek, ramapulavarthi, rcardillo and RyanCarpenter

 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 07:15 PM ]

Created an attachment (id=254)
testcase

Comment by ramapulavarthi [ 11/Jun/08 07:25 PM ]

Created an attachment (id=255)
Updated testcase

Comment by ramapulavarthi [ 08/Jan/09 12:06 PM ]

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 05:32 AM ]

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 05:05 AM ]

marking as incomplete

Comment by Pavel Bucek [ 19/Mar/09 07:09 AM ]

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

Comment by ramapulavarthi [ 20/Mar/09 05:31 PM ]

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 05:32 PM ]

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

Comment by Pavel Bucek [ 24/Mar/09 04:44 AM ]

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 09:09 AM ]

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 05:31 PM ]

Any update yet?

Comment by Pavel Bucek [ 16/Apr/09 01:13 AM ]

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 09:07 AM ]

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 07:45 PM ]

Any update yet?

Comment by Martin Grebac [ 11/Sep/09 01:50 AM ]

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

Comment by Martin Grebac [ 17/Sep/09 09:01 AM ]

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 08:25 AM ]

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 07:54 PM ]

Thanks for the update.

Comment by fribeiro [ 25/Jan/10 05:41 AM ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 12:59 PM ]

Any update yet?

Comment by marcelcasado [ 24/Nov/11 02:09 AM ]

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

Comment by cedric.vidal [ 08/Jun/12 09:34 AM ]

I'm also interested for an update on this.

Comment by RyanCarpenter [ 06/Mar/13 08:55 PM ]

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 01:13 PM ]

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 02:35 PM ]

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 09:34 PM ]

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

Comment by jahutton [ 14/Mar/14 02:36 PM ]

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

Comment by Michael Osipov [ 14/Mar/14 11:00 PM ]

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!





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 569
Tags:
Participants: Martin Grebac

 Description   

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



 Comments   
Comment by Martin Grebac [ 15/Apr/11 05:59 AM ]

So that I don't forget.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File jaxb-schemagen-patch.txt    
Issuezilla Id: 572
Tags:
Participants: kohsuke, Martin Grebac and myannou

 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 02:04 PM ]

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

Comment by myannou [ 28/Nov/08 02:06 PM ]

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

Comment by myannou [ 29/Nov/08 05:27 AM ]

I forgot to assign this issue

Comment by kohsuke [ 08/Dec/08 11:05 AM ]

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 11:06 AM ]

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 05:30 AM ]

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

Comment by Martin Grebac [ 15/Apr/11 06:25 AM ]

increase priority so that I look at it





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 597
Tags:
Participants: Martin Grebac and ramapulavarthi

 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 02:04 AM ]

Just changing to enhancement.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File options_java_patch.txt    
Issuezilla Id: 625
Tags:
Participants: florianbachmann and Martin Grebac

 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 01:40 AM ]

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

Comment by florianbachmann [ 16/Nov/09 06:35 AM ]

any possible solution in sight?

Comment by florianbachmann [ 16/Nov/09 06:36 AM ]

any possible solution in sight?





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: HP


File Attachments: Text File 20100702_Bug770.diff    
Issuezilla Id: 770
Tags:
Participants: gmazza, lrflesch and Martin Grebac

 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 11:26 AM ]

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 11:32 AM ]

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 12:48 PM ]

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

Comment by gmazza [ 02/Jul/10 12:56 PM ]

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 01:48 AM ]

Marking as patch attached.

Comment by Martin Grebac [ 15/Apr/11 05:02 AM ]

marking higher so that I look at this one





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 789
Tags:
Participants: lexi and Martin Grebac

 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-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
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
Participants: Iaroslav Savytskyi and m_perdikeas

 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-1000] com.sun.xml.bind.v2.ClassFactory has memory leak Created: 28/Jan/14  Updated: 29/Jan/14

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

Type: Bug Priority: Critical
Reporter: herman.bovens Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7


Tags:
Participants: herman.bovens and Iaroslav Savytskyi

 Description   

This error is seen in tomcat 7 logs:

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

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



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

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

Comment by Iaroslav Savytskyi [ 29/Jan/14 05:33 PM ]

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

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

Thanks.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Tags:
Participants: Iaroslav Savytskyi and MRalwasser

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

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

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

Tags:
Participants: Iaroslav Savytskyi and Martin Grebac




[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Java Source File JAXBElement.java     Java Source File JAXBElementTest.java    
Issuezilla Id: 57
Tags:
Participants: Joe Fialli, kohsuke, lexi, Martin Grebac, ryan_shoemaker and skaffman

 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 07:20 AM ]

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 07:36 AM ]

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

Comment by lexi [ 10/Jun/05 07:36 AM ]

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

Comment by lexi [ 10/Jun/05 07:38 AM ]

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 08:39 AM ]

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

Comment by Joe Fialli [ 10/Jun/05 02:09 PM ]

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 02:22 PM ]

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 11:34 AM ]

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 11:10 AM ]

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 07:22 AM ]

> 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 07:01 AM ]

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 10:48 AM ]

Moving it to the spec...

Comment by kohsuke [ 30/May/06 06:19 PM ]

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 07:45 AM ]

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 08:07 AM ]

+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-103] multiple namespaces are serialized Created: 18/Oct/05  Updated: 17/Oct/12

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

Type: New Feature Priority: Major
Reporter: ramazanyich2 Assignee: Martin Grebac
Resolution: Unresolved Votes: 10
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File jaxb.index     Java Source File package-info.java     Java Source File package-info.java     XML File test.xml     Java Source File TestClass1.java     Java Source File testJaxb.java    
Issuezilla Id: 103
Tags:
Participants: aempinheiro, ajsmen, kohsuke, ktrapszo, Martin Grebac, mindchi, ramazanyich2, rustamabd and thst

 Description   

have two separate packages
com.company1.doc
and com.company2.doc

every package contains namespace definition (in package-info.java):
@javax.xml.bind.annotation.XmlSchema(namespace = "http://company1.com/doc")
package com.company1.doc;

and
@javax.xml.bind.annotation.XmlSchema(namespace = "http://company2.com/doc")
package com.company2.doc;

I initialize JAXBContext using JAXBContext.newInstance("com.company1:com.company2");

Then I construct java objects in both packages:

Problem is then I unmarshall documents of one package I see namespace of another
package:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns:ns2="http://company1.com/doc" xmlns:ns3="http://company2.com/doc">
...

Is it possible to avoid printing of unused namespace ?



 Comments   
Comment by kohsuke [ 28/Oct/05 12:19 PM ]

Hmm.

Would it be possible for you to try the latest nightly build? I remember fixing
an issue like this some time ago, and I couldn't reproduce the problem with the
current snapshot of the JAXB RI.

If it still doesn't work, please reopen the bug so that it gets our attention.

Comment by ramazanyich2 [ 08/Nov/05 09:42 AM ]

Created an attachment (id=57)
test class file which produces output

Comment by ramazanyich2 [ 08/Nov/05 09:43 AM ]

Created an attachment (id=58)
class file for first package

Comment by ramazanyich2 [ 08/Nov/05 09:43 AM ]

Created an attachment (id=59)
class file for second package

Comment by ramazanyich2 [ 08/Nov/05 09:44 AM ]

Created an attachment (id=60)
package info for second package

Comment by ramazanyich2 [ 08/Nov/05 09:44 AM ]

Created an attachment (id=61)
package info for first package

Comment by ramazanyich2 [ 08/Nov/05 09:45 AM ]

Created an attachment (id=62)
result of execution

Comment by ramazanyich2 [ 08/Nov/05 09:48 AM ]

I tried it with lates build ( dated by 8 november) but in result I still have
all namespaces.
I attached all files to the issue. Run testJaxb.java and you will have test.xml
as result.
It will have <ns2:test1 xmlns:ns2="http://company1.com"
xmlns:ns3="http://company2.com">
xmlns:ns3="http://company2.com" is unwanted as object TestClass2 was not created.

Comment by ktrapszo [ 19/Apr/06 12:34 PM ]

Using 4/19/2006 build, this is still an issue.

Comment by kohsuke [ 30/May/06 06:16 PM ]

This is actually the expected behavior.

In 1.0, we did what ramazanyich2 wanted us to do — namely, declare namespaces
lazily on-demand, only when it's necessary. Often this results in namespaces
declared multiple places in sub-trees, and many people weren't happy with this.

We can't make it any smarter, as in short of traversing the whole object tree,
The marshaller won't be able to discover all the namespaces in use. Such
traversal would be very costly.

So in 2.0 we decided to change the behavior to always declare all the statically
known namespaces upfront. This also made the namespace management inside the
marshaller simpler, contributed to the overall performance improvement.

Given those background, at this point we are not planning to change this behavior.

Comment by mindchi [ 01/Apr/10 08:38 AM ]

I'm requesting that this issue be reopened as having the extraneous namespaces
causes problems when using JAXB as the data binding framework for CXF. Firstly,
I think it is unacceptable to have a solution which changes your data. If I
take an XML file read it in and write it back out, I should end up with exactly
the same file. Not a file that has extra stuff in it. This reason alone should
be enough to warrant a fix.

I am writing some web service code using CFX and JAXB. I check my code all the
way to the point where I include it as an element of a larger document that
gets passed into CFX framework for handling web service processing. When it
comes out, it has extra tags in it. It is sent to publish and subscribe server.
When I try to read the data when I retrieve it from the server, CXF produces a
SAX parse exception due to one of the extraneous namespaces which it wasn't
expecting. Now, it may be possible for me to intercept the data and remove the
extranuous namespace definitions, but this is an enterprise system, and I
cannot expect every other application to do this. Up until this point, my
experience with JAXB has been good. I like the performance, however, this issue
basically renders JAXB useless to me on this project. I would like to continue
to use JAXB, however, I don't expect this to be fixed anytime soon, so I will
need to look into using some other data binding framework, perhaps XMLBeans
with CXF.

Please consider correcting this problem so I can continue using JAXB in
conjunction with CXF.

Comment by aempinheiro [ 29/Dec/10 02:52 AM ]

Referring to the comment before, altering the existing xml means that, if I open a signed xml jaxb will change it and its' signature won't be valid anymore.

This means that this issue represents quite a big problem.

Comment by rustamabd [ 12/Mar/11 12:51 PM ]

I disagree with the reasoning provided by 'kohsuke', performance can have different meaning, for some users network throughput has higher importance than CPU cycles. For example take small secured services, these have lots of OASIS headers and small payloads. Unnecessary namespace overhead in these is big, while the overhead of traversing a dozen nodes would be negligible.

I propose to have an optional feature (with a possibility to turn it on and off) to traverse the tree and eliminate unnecessary namespace declarations. This can be made even smarter; e.g. stop traversing after reaching 100th node.

Comment by thst [ 27/Apr/11 01:35 AM ]

I am wondering why it would not be possible to keep a list of used namespaces during production and add them in a second step to the final dom. This way there is no need to traverse the whole tree a second time, only a visit in the documentroot as a last step.

I understand that this would not work on a streaming output, but treewalking would have the same issue.

Comment by ajsmen [ 17/Oct/12 08:32 AM ]

@kohsuke:
> In 1.0, we did what ramazanyich2 wanted us to do — namely, declare namespaces
> lazily on-demand, only when it's necessary. Often this results in namespaces
> declared multiple places in sub-trees, and many people weren't happy with this.

What about lazily on-demand add namespaces to some sort of set during document creation and at the end append all of them to the root element?





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 132
Tags:
Participants: kohsuke and Martin Grebac

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


File Attachments: Zip Archive test.zip    
Issuezilla Id: 134
Tags: as911na
Participants: dtenev, kohsuke and Martin Grebac

 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 09:24 AM ]

Created an attachment (id=84)
Test case

Comment by kohsuke [ 31/May/06 04:27 PM ]

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 12:23 AM ]

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 07:01 AM ]

adding keyword





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Zip Archive broken.zip    
Issuezilla Id: 149
Tags:
Participants: kohsuke, maomaode and Martin Grebac

 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 08:24 PM ]

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

Comment by kohsuke [ 04/May/06 01:36 PM ]

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 03:13 PM ]

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





[JAXB-209] Schema-driven XmlAdapter using xjc:javaType Created: 31/Jul/06  Updated: 04/Mar/10

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

Type: Improvement Priority: Major
Reporter: rtiernay Assignee: jaxb-issues
Resolution: Unresolved Votes: 21
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 209
Tags:
Participants: dma_k, jaxb-issues, royalpeasantry, rtiernay and uprooter

 Description   

In situations where modifying schema-derived classes is not an option, it would
be very nice to be able to use xjc:javaType to map schema types to more natural
java types. For instance, being able to map a schema type to a HashMap might
be a likely requirement for those using model driven design/implementation.
AFAICS, this is not possible today. Therefore, one must manually edit the
generated code.



 Comments   
Comment by uprooter [ 14/Nov/09 11:29 AM ]

bump.

Comment by dma_k [ 28/Feb/10 12:13 PM ]

rtiernay, can you please provide a more verbose example? Do you need to map a
complete type, like shown here:
http://stackoverflow.com/questions/1881712/is-it-possible-to-use-jaxb-to-map-from-schema-to-a-java-util-map
?

Comment by royalpeasantry [ 04/Mar/10 11:10 AM ]

That is the functionality I am looking for.

Currently it is only possible to translate from a Simple XML type to any Java
Type. It should also be possible to use an XMLAdaptor to translate from a
Complex XML type to any JavaType using <xjc:javaType name="<JavaType>"
adaptor="<XMLAdaptor>">.

Unless I am mistaken everything works perfectly if you manually code up the
class using @XMLJavaTypeAdaptor, but it cannot be schema-generated because
JavaType cannot be bound to a Complex Type. If the schema would allow JavaType
to be bound to both complex and simple types I suspect it would work perfectly.

This defect is related as well.. Without it you cannot use generics in the
'name' attribute of 'JavaType'. (<xjc:javaType name="java.util.Map<String,
Integer>" adaptor=...> for example)
https://jaxb.dev.java.net/issues/show_bug.cgi?id=737





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 223
Tags:
Participants: breadfan_de, kohsuke and Martin Grebac

 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 10:52 AM ]

This is a spec issue.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 234
Tags:
Participants: jaxb-issues and sbalmos

 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-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
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
Tags:
Participants: desruisseaux, Iaroslav Savytskyi, kohsuke, mosh and rebeccas

 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 12:10 PM ]

I think this issue has been fixed some time ago.

Comment by mosh [ 14/Nov/06 01:45 AM ]

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 01:24 PM ]

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 11:15 AM ]

Implementation complete.

Comment by desruisseaux [ 21/Oct/11 09:26 AM ]

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 05:54 PM ]

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 06:17 PM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 253
Tags:
Participants: jaxb-issues, kohsuke and rshan

 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 02:28 PM ]

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 05:56 AM ]

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

Comment by kohsuke [ 29/Sep/06 12:18 PM ]

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 09:13 AM ]

Reclassifying as this is an enhancement request.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 265
Tags:
Participants: flickerlight, jaxb-issues and kohsuke

 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 10:36 PM ]

Changing the title to describe the feature better.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 270
Tags:
Participants: jaxb-issues, kohsuke and sebastiankirsch

 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 02:40 PM ]

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 02:40 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 272
Tags:
Participants: kohsuke, lpurvis and Martin Grebac

 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 12:10 PM ]

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





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

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: 19
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
Tags:
Participants: Dennis Kieselhorst, lisa_winkler and wiebe_ruiter

 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 08:30 AM ]

The opposite is in issue JAXB-460.

Comment by lisa_winkler [ 13/Jun/12 11:09 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: File jaxb2-ri-20061109.nps     File jaxbperf-fastboot-20061109.nps     File jaxbperf.nps    
Issuezilla Id: 275
Tags:
Participants: ericcrampton, kohsuke, Martin Grebac and skaffman

 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 02:28 PM ]

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

Comment by ericcrampton [ 09/Nov/06 06:38 AM ]

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

Comment by skaffman [ 09/Nov/06 12:29 PM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 276
Tags: incomplete
Participants: jeps and Martin Grebac

 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 03:48 AM ]

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





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 279
Tags:
Participants: lpurvis and Martin Grebac

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 290
Tags:
Participants: cezimmerman and jaxb-issues

 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 09:35 AM ]

should have been an Enhacement request





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 295
Tags:
Participants: jaxb-issues and rieman4d

 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-318] Enum generation for anonymous types Created: 31/Jan/07  Updated: 31/Jan/07

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

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

Operating System: All
Platform: All
URL: http://www.nabble.com/Getting-a-Java-5-enum-from-XJC-tf3120010.html


Issuezilla Id: 318
Tags:
Participants: gk5885 and jaxb-issues

 Description   

As discussed in the referenced thread, xjc does not generate an enum for anonymous simple types that
are defined as an <xs:enumeration>. It would be desirable for anonymous simple types, as well as the
named ones, to be compiled to an enum.






[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File patch.txt    
Issuezilla Id: 325
Tags:
Participants: dean_jones, kohsuke and Martin Grebac

 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 03:27 PM ]

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 09:07 AM ]

Created an attachment (id=168)
Patch for bug

Comment by dean_jones [ 03/Mar/07 09:53 AM ]

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-335] wsimport usage of xjc episode files 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: 13
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 335
Tags:
Participants: Martin Grebac and mshaffer55

 Description   

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

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

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






[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
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
Tags:
Participants: dlaprade, fribeiro, Martin Grebac and mshaffer55

 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 11:04 AM ]

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 07:32 AM ]

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

Comment by fribeiro [ 08/Sep/09 08:00 PM ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 12:35 PM ]

Any update yet?





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 357
Tags:
Participants: basdebakker14, bshrom, gb96, kohsuke and Martin Grebac

 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 01:34 PM ]

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 02:23 AM ]

The same issue exists with attributes of type NMTOKENS.

Comment by gb96 [ 18/May/12 01:21 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 362
Tags:
Participants: abedhammoud and jaxb-issues

 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-370] Add plugin ability to schemagen as it is for xjc Created: 06/Jun/07  Updated: 15/Apr/11

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

Type: New Feature Priority: Major
Reporter: joe321 Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 370
Tags:
Participants: joe321 and Martin Grebac

 Description   

Currently xjc has a plugin model, schemagen is lacking this. Can we add it so
that people could hook their own code into here.






[JAXB-372] Please enable xsi:type dynamic class resolving using ClassResolver Created: 08/Jun/07  Updated: 08/Jun/07

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 372
Tags:
Participants: jaxb-issues and wiebe_ruiter

 Description   

see:

http://forums.java.net/jive/thread.jspa?threadID=25977&tstart=180

It would be very useful, if dynamic class resolving is extended to also resolve
classes dynamically when using the xsi:type attribute. Preferably using the same
ClassResolver implementation that is set for unmarshalling with:

unmarshaller.setProperty(ClassResolver.class.getName(), new SomeClassResolver());






[JAXB-380] XJCTask should allow n URLs like cmdline version Created: 03/Jul/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: vguna Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 380
Tags:
Participants: Martin Grebac and vguna

 Description   

The ant XJCTask doesn't allow the use of more than one URL to create objects
from a schema. So it isn't possible to compile n XSD Schemas (via URL) at once.
This works with the cmdline version though.

Would be great if one could specify either a delimiter separated list of urls to
the schema attribute of the xjc task or to enhance the nested schema tag for
allowing URLs.






[JAXB-384] Generated code produced by wsimport issues compilation warnings Created: 10/Jul/07  Updated: 10/Jul/07

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

Type: Improvement Priority: Major
Reporter: francklucas Assignee: jaxb-issues
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 384
Tags:
Participants: francklucas and jaxb-issues

 Description   

Hi,
I am using wsimport (version 2.1.1) an thus xjc to generate client side classes
and I get warnings in generated files.
I use a customization file that contains the following line:
<globalBindings generateValueClass="false">

Using this option, I get interfaces generated and implementations.
Here is a summary of warnings I get:

In class ObjectFactory
private final static Void _useJAXBProperties = null;
The field ObjectFactory._useJAXBProperties is never read locally

return new JAXBElement<GetList>(_GetList_QNAME, ((Class) GetListImpl.class),
null, ((GetListImpl) value));
Class is a raw type. References to generic type Class<T> should be parameterized
Type safety: The expression of type Class needs unchecked conversion to conform
to Class<GetList>

In class JAXBContextFactory:
return JAXBContext.newInstance(r,properties);
Type safety: The expression of type Map needs unchecked conversion to conform
to Map<String,?>

Class[] r = new Class[classes.length];
Class is a raw type. References to generic type Class<T> should be parameterized

I get a total of 22 warnings, having an important number of warnings in code
may confuse programmers and make them unaware of other important warnings.
Moreover we use static code analysis tools (developed by our test and code
quality department) that will depreciate code.

Please see details at http://forums.java.net/jive/thread.jspa?
threadID=28194&tstart=30






[JAXB-385] Generated Timestamp makes diff display all files Created: 13/Jul/07  Updated: 13/Jul/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 385
Tags:
Participants: jaxb-issues and sagadon

 Description   

When .java files are generated using xjc, a 'Generated Timestamp' is added in
the comments at the top of every file. This causes any kind of 'diff', to see
what has changed, to report that every single file has changed.

It would be nice if there was a checkbox to disable the generation of this line
of comment. Make it so that you can generate your files, and optionally leave
that out. The current behaviour could still be the default in the application.

Version number is v2.1-b02-fcs - I assumed this means 2.1.2






[JAXB-392] Extensible xsd schema generation Created: 29/Jul/07  Updated: 21/Jun/13

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

Type: New Feature Priority: Major
Reporter: slonopotamus Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 392
Tags:
Participants: Martin Grebac, slonopotamus and whummer

 Description   

Allow making extensions to xsd schema generation (same as
WSDLGeneratorExtension in jaxws-ri).

I have an extension to jaxws-ri that writes wsdl:documentation to generated
wsdl using custom annotations on webservice methods but cannot do the same for
jaxb generated xsd.



 Comments   
Comment by whummer [ 21/Jun/13 12:27 PM ]

You might be interested in the JAXB-Facets extension, which allows you to specify XSD annotations, documentations, and facets:
https://github.com/whummer/jaxb-facets

Also see JIRA page here:
https://java.net/jira/browse/JAXB-917





[JAXB-398] Ability to set NamespaceContext through the JAXBContext. Created: 06/Aug/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: Major
Reporter: sameer_v_rao Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 398
Tags:
Participants: Martin Grebac and sameer_v_rao

 Description   

Currently JAXB allows user to set/pass NamespaceContext through the Marshaller.

Customizing namespace prefix is a useful feature; however the Marshaller is not
Thread safe class and it is recommended to create a new instance while working
with it.

JAXBContext is however thread-safe and is recommended to keep a singleton for
improved performance.

With this in mind, I think a feature of being able to set/pass Namespace
context through the JAXBContext (initiation phase) would be preferrable.

Even otherwise, most of time, users would want to use same namespace mapping
irrespective of how many times the marshall contents to XML document. (E.g.
returning document through a webservice).



 Comments   
Comment by Martin Grebac [ 15/Apr/11 03:36 AM ]

makes sense





[JAXB-403] Relaxed processing of invalid XML isntance related to elementFormDefaul="unqualified" Created: 16/Aug/07  Updated: 16/Aug/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 403
Tags:
Participants: jaxb-issues and vivekp

 Description   

For XML schema with elementFormDefault="unqualified", some clients such as .NET
3.0 clients, sends XML instance where the child node falls into parent's
namespace and JAXB unmarshalls these in to null.

The use case was reported in
https://wsit.dev.java.net/issues/show_bug.cgi?id=653, where for schema such as
mentioned below[1], .NET client sends request:

<s:Body>
<Ping xmlns="http://tempuri.org/">
<Text>Microsoft-3</Text>
</Ping>
</s:Body>

fails. Perhaps JAXB can be little relaxed in dealing with such invalid XML
instances in such a way that JAX-WS RI can use it to allow handling of such XML
instances.

[1] XML schema
<?xml version="1.0" encoding="UTF-8"?><!-- Published by JAX-WS RI at
http://jax-ws.dev.java.net. RI's version is unknown. --><xs:schema
xmlns:tns="http://tempuri.org/" xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0" targetNamespace="http://tempuri.org/">

<xs:element name="Ping" type="tns:Ping"></xs:element>

<xs:complexType name="Ping">
<xs:sequence>
<xs:element name="Text" type="xs:string" minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>






[JAXB-408] Apply binding rule to multiple XML nodes Created: 23/Aug/07  Updated: 23/Aug/07

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

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

Operating System: All
Platform: All


Issuezilla Id: 408
Tags:
Participants: jaxb-issues and jschek

 Description   

This is the feature request as described in the forums (did not see a RFE
submitted for htis):

http://forums.java.net/jive/message.jspa?messageID=195842

I need to apply a binding rule to multiple attribute declarations in an XML
schema (particular with JAX-WS).

The purpose of this is to build a general-purpose binding to fix the problems
described in:
https://jaxb.dev.java.net/nonav/issues/showattachment.cgi/125/NoJAXBElementCusto
mization220.txt

What I would like to do is this:

<jaxws:bindings node="wsdl:definitions/wsdl:types/xs:schema
[@targetNamespace='http://www.esri.com/schemas/ArcGIS/9.2']">
<jaxws:bindings node="xs:complexType/xs:sequence/xs:element
[@type='xs:anyType' and @nillable='true' and @minOccurs='0' and (not
(@maxOccurs) or @maxOccurs=1)] ">
<jaxb:property generateElementProperty="false"/>
</jaxws:bindings>
</jaxws:bindings>

I have tried to apply the generateElementProperty to the entire document (both
via a property tag and the global tag), but then I get errors like:

NAServerSolverParams.class: warning: Cannot find annotation method 'value()' in
type 'javax.xml.bind.annotation.XmlSeeAlso'






[JAXB-422] Support XML 1.1 Created: 22/Sep/07  Updated: 15/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 422
Tags:
Participants: brettw, kohsuke and Martin Grebac

 Description   

This is a blocking issue for my company. We have a string that contains control
characters – as defined by Character.isISOControl(char). These values can
legally be encoded in XML 1.1 (but not in XML 1.0). The XML version should be
selectable in JAXB RI (possibly through a System property) and the values
property encoded. The class responsible for encoding is:

com.sun.xml.bind.v2.runtime.output.Encoded



 Comments   
Comment by kohsuke [ 24/Sep/07 10:29 AM ]

Would it be fair to characterize this as "XML 1.1 support" ?

Comment by brettw [ 24/Sep/07 03:55 PM ]

yes. and no. I think there are many XML 1.0 implementations that would deal
with XML 1.1 style escaping. In my opinion it would be preferable to attempt
the escape anyway, because if you don't the call blows up way down in the
unmarshall stack anyway.

Comment by kohsuke [ 04/Dec/07 10:32 AM ]

I don't think it's wise for us to produce non well-formed (in XML 1.0 sense) XML
documents by default. Today we already take a lot of heat for not doing more
rigorous well-formedness check on what we produce, as it violates the internet
principle of "be strict about what you produce, and be forgiving about what you
receive."

Having a mode to support XML 1.1 would be good, though (with proper XML 1.1
prolog and everything.)





[JAXB-430] JAXB Validation Without Schema Created: 15/Oct/07  Updated: 16/Jul/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 430
Tags:
Participants: areami, cruelfate, Iaroslav Savytskyi, lennartj, Martin Grebac, ovy9086, pastafarian, roos, shelleyb and tuukkamustonen

 Description   

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

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



 Comments   
Comment by tuukkamustonen [ 07/Feb/11 12:28 AM ]

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

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

Comment by pastafarian [ 27/Jun/11 05:17 PM ]

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

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

Comment by lennartj [ 04/Nov/11 07:57 AM ]

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

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

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

Comment by cruelfate [ 13/Jan/12 07:44 AM ]

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

Use Case

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

public class JaxbValidatorTest {

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

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

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

Implementation

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

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

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

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

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

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

Comment by roos [ 30/Oct/12 01:17 PM ]

Its 10/2012 now and still nothing.

Comment by ovy9086 [ 16/Jul/13 01:50 PM ]

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

Comment by areami [ 16/Jul/13 01:54 PM ]

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

Comment by Iaroslav Savytskyi [ 16/Jul/13 01:59 PM ]

May be MOXy JAXB implementation can help.

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

Comment by lennartj [ 16/Jul/13 10:56 PM ]

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

My workaround has been the implementation in

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

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





[JAXB-437] XmlSeeAlso enhancements Created: 25/Oct/07  Updated: 12/Apr/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 437
Tags:
Participants: lpurvis and Martin Grebac

 Description   

I have three enhancement suggestions for @XmlSeeAlso.

1. Allow @XmlSeeAlso to be applied to a package via package-info.java. This
will help greatly in decoupling base classes from their subclasses.

2. Check for @XmlSeeAlso on XmlAdapter implementation classes that have been
specified via @XmlJavaTypeAdapter. This will also help greatly in decoupling
base classes from their subclasses.

3. Allow for specifying an array of package name strings via @XmlSeeAlso. This
would work in a similar way as creating a JAXBContext with a list of package
names in that the package(s) would be scanned for classes. This one would be a
tremendous help in adding runtime flexibility to JAXB when used with JAXWS –
extension subclasses could be loaded at runtime that are not available at
compile time.

public @interface XmlSeeAlso {
Class[] value();
String[] packages();
}






[JAXB-447] Natural JAXB support for interfaces Created: 23/Nov/07  Updated: 23/Nov/07

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

Type: New Feature Priority: Major
Reporter: tigera Assignee: jaxb-issues
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 447
Tags:
Participants: jaxb-issues and tigera

 Description   

I would like JAXB to support interfaces natively without workarounds or
XmlAdapters. Though I am not familiar with the spec, it seems like JAXB should
follow the following procedure when unmarshalling a class:

1. Unmarshall using Class<X>.newInstance().
2. If #1 won't work, search for the factoryClass and factoryMethod attributes of
the XmlType annotation and use those to generate the object.
3. If #1 and #2 won't work, search for the ObjectFactory for this package and
find a method returning the desired type.
4. If all 3 steps fail, report an error.

This feature would make JAXB easier to learn and easier to use. If this is in
conflict with the spec, I would request that this be added as a vendor-specific
feature.






[JAXB-448] XmlIDREF to interface Created: 26/Nov/07  Updated: 15/Apr/11

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

Type: Improvement Priority: Major
Reporter: vk101 Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
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=33511&tstart=0


Issuezilla Id: 448
Tags:
Participants: Martin Grebac and vk101

 Description   

JAXB doesn't support a 'code-to-interfaces' approach when it comes to id
references (i.e. @XmlIDREF), because a property on a class annotated with
@XmlIDREF and @XmlAttribute can only refer to a class, but not an interface.
The following does not work:

@XmlIDREF
@XmlAttribute
public MyInterface getMyInterface() { //this is an interface return myInterface; }

What's needed is an equivalent to @XmlElementRef (e.g. @XmlAttributeRef) for
attributes, that lets you specify the allowable classes of the interface of the
property.

Perhaps some kind of autodetection could be possible, by looking up the single
element in the XML file with an ID specified by the above property, and seeing
if it's assignable to a type of 'MyInterface'.






[JAXB-454] Clarified message for SUBSTITUTED_BY_ANONYMOUS_TYPE Created: 03/Dec/07  Updated: 11/Jan/11

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

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

Operating System: All
Platform: All


File Attachments: Text File jaxbpatch.txt    
Issuezilla Id: 454
Tags:
Participants: gmazza and jaxb-issues

 Description   

Due to a apparent bug in our CXF code[1], we sometimes get the
SUBSTITUTED_BY_ANONYMOUS_TYPE error. The error message we're receiving from
JAXB is somewhat cryptic to the end-user, so this patch clarifies the error
message to make the problem more understandable. (In particular, I'm switching
the word "substituting" with "expecting", I believe that is correct.) I also
rearranged the numeric ordering of the error messages to make it easier to
follow with the JAXB code.

[1]
http://www.google.com/search?q=%22is+substituting%22+%22is+bound+to+an+anonymous+type%22



 Comments   
Comment by gmazza [ 03/Dec/07 12:08 PM ]

Created an attachment (id=224)
Patch to change error message text





[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
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
Participants: gmazza, Macs75, Martin Grebac, Martin Matula, matunos, paultaylor, Pavel Bucek and pydera

 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 08:56 AM ]

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 09:01 AM ]

reassigning

Comment by pydera [ 25/Oct/08 11:50 AM ]

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();
obj.setId(8);
obj.setName("Holla");

DOMResult result = new DOMResult();
m.marshal(obj, result);
Node node = result.getNode();

Binder<Node> binder = ctx.createBinder();
MyObject jaxObj = (MyObject) binder.unmarshal(node);

Node jaxNode = binder.getXMLNode(jaxObj);
binder.updateXML(jaxObj);
binder.updateXML(jaxObj); // crash goes here (NullPointerException

Interesting is furthermore if you remove the last two lines and do:
Node newNode = binder.updateXML(jaxObj, jaxNode);
then this holds:

  • newNode != jaxNode
  • jaxNode == binder.getXMLNode(jaxObj);

If you exchange the two updateXML-lines with:
Node newNode1 = binder.updateXML(jaxObj);
Node newNode2 = binder.updateXML(jaxObj, newNode1);
no crash occurs, but the Binder-internals do not get updated:
binder.getJAXBNode(jaxNode) == jaxObj
binder.getJAXBNode(newNode) == null

Maybe this info can be of help...

Greetz

Pydera

Comment by Pavel Bucek [ 13/Jan/09 05:19 PM ]

fixed in trunk

Comment by Pavel Bucek [ 20/Apr/10 03:38 AM ]

fix was reverted

Comment by gmazza [ 12/Jul/10 04:06 AM ]

Why was the fix reverted?

Comment by Martin Grebac [ 06/Oct/10 02:00 AM ]

reassigning

Comment by Martin Matula [ 06/Oct/10 08:01 AM ]

Why is this marked as 2.1-waived?

Comment by Pavel Bucek [ 19/Nov/10 12:49 AM ]

updating priority, reassigning, updating target milestone.

can't be fixed easily without breaking existing test suite.

Comment by matunos [ 14/Apr/11 08:31 PM ]

Hi. Has there been any progress on this? Is there a suggested workaround?

Looking briefly through the code, it seems like the problem is that updateXML() marshals the jaxb object, creating a new XmlNode, but the association map of objects to nodes is never updated, so the next time through, the jaxbobject is still associated with the original XmlNode, which now has no parent, and thus, you get a NPE.

This makes updateXML relatively useless... worse than useless, in fact, but dangerous.

Comment by Macs75 [ 10/May/11 05:06 AM ]

This is very annoying, any reason for this behaviour? If there is a testcase that does not work with this fix there must be a reason. I can't belive it is not fixed because this imply to rethink testcases.





[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: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 460
Tags:
Participants: davidhoffer2, Dennis Kieselhorst and jaxb-issues

 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 08:26 AM ]

Good Idea, relates to issue JAXB-273.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 464
Tags:
Participants: jaxb-issues, kohsuke and troydm

 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 10:45 AM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File 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
Participants: alexkos, brands, dharland, Martin Grebac and Pavel Bucek

 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 08:58 AM ]

Created an attachment (id=245)
junit test case

Comment by dharland [ 26/Mar/08 10:29 AM ]

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 10:31 AM ]

Created an attachment (id=248)
Two simplified test cases

Comment by dharland [ 08/May/08 10:16 AM ]

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 01:56 PM ]

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 01:58 PM ]

Created an attachment (id=252)
Shows work-around; clarifies the problem

Comment by dharland [ 15/May/08 02:25 PM ]

Created an attachment (id=253)
USE IN PLACE OF PREVIOUS ATT. Shows work-around; clarifies the problem

Comment by Pavel Bucek [ 12/Feb/09 01:29 AM ]

fixed in trunk

Comment by alexkos [ 12/Feb/09 07:27 AM ]

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 08:08 AM ]

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 02:15 AM ]

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 02:16 AM ]

assigning to pavel

Comment by Pavel Bucek [ 07/Oct/10 03:13 AM ]

updating target milestone

Comment by Pavel Bucek [ 19/Nov/10 09:24 AM ]

metro2.1-waived

Comment by Martin Grebac [ 22/Nov/11 09:59 AM ]

The fix is in 2.2 codebase, marking as such.

Comment by Martin Grebac [ 26/Feb/13 11:32 AM ]

Reopening to implement switch as I mentioned already as the default behaviour does not conform to spec.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 495
Tags:
Participants: cedricbr and jaxb-issues

 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-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
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
Tags:
Participants: Martin Grebac, nradov and scarcher2

 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 06:18 AM ]

exception shall be caught and rethrown with current location

Comment by scarcher2 [ 30/Aug/11 03:19 AM ]

I'm having the same problem. Trying to generate classes from the CDA Schema files.





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


File Attachments: Text File xsdrestrictiontest.tar.gz    
Issuezilla Id: 515
Tags:
Participants: jaxb-issues, Pavel Bucek, rupertlssmith and Thomas De Smedt

 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 02:15 AM ]

Created an attachment (id=256)
The example described in the bug report.

Comment by Pavel Bucek [ 15/Dec/08 02:17 AM ]

not in current scope of work, changing to ENHANCEMENT

Comment by Thomas De Smedt [ 12/Sep/09 07:47 PM ]

see https://jaxb.dev.java.net/issues/show_bug.cgi?id=683 for a workaround through
validation





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 522
Tags:
Participants: jaxb-issues, kdubb and Pavel Bucek

 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 06:56 AM ]

marking as enhancement





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Java Source File JaxbIssue523.java    
Issuezilla Id: 523
Tags: metro2_1-waived metro2_2-waived
Participants: kdubb, Martin Grebac, Pavel Bucek and pkelchner

 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 06:58 AM ]

Could you please provide a test case to this issue?

Comment by Pavel Bucek [ 29/Jan/09 02:56 AM ]

marking as incomplete

Comment by pkelchner [ 30/Mar/10 05:30 AM ]

Created an attachment (id=353)
Testcase to reproduce issue

Comment by pkelchner [ 31/Mar/10 12:51 AM ]

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 02:08 AM ]

reassigning

Comment by Martin Grebac [ 06/Oct/10 03:14 AM ]

reproduced, assigning TM

Comment by Pavel Bucek [ 19/Nov/10 09:45 AM ]

metro2.1-waived





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


File Attachments: PNG File HO13256_screenshotOfWSDL.PNG    
Issuezilla Id: 524
Tags:
Participants: longlee and Martin Grebac

 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 03:35 AM ]

Created an attachment (id=260)
the screenshot of numeric unicode reference





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 528
Tags: incomplete
Participants: clemenso and Martin Grebac

 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 06:24 AM ]

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-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
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
Tags:
Participants: Martin Grebac and stondini

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 550
Tags:
Participants: Marek Potociar and Martin Grebac

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 552
Tags:
Participants: Martin Grebac and skaffman

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 568
Tags:
Participants: jaxb-issues and samplez

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 577
Tags: incomplete
Participants: Martin Grebac and najmi

 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 11:32 AM ]

Changed title to be more generic.

Comment by Martin Grebac [ 12/Apr/11 02:47 AM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 579
Tags:
Participants: jaxb-issues, kitfox and tastle

 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 05:52 PM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 593
Tags:
Participants: florianbachmann, Martin Grebac and Pavel Bucek

 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 06:13 AM ]

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 06:25 AM ]

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 10:22 AM ]

-> 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 06:34 AM ]

any possible solution in sight?





[JAXB-598] Sorting of methods in generated ObjectFactory classes Created: 09/Feb/09  Updated: 18/Mar/14

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

Type: Improvement Priority: Major
Reporter: normann1974 Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 6
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 598
Tags:
Participants: ciscox83, fowlie, Iaroslav Savytskyi and normann1974

 Description   

When JAXB generated classes are under version control, it's more or less
impossible to see if a regeneration of the JAXB classes has introduced any
changes in the ObjectFactory class because the methods in this class are added
by XJC in random-like order and this leaves the file almost completely modified
according to the version control system. It would be nice if two invocations of
XJC would add the methods in the same order, e.g. by sorting them alphabetically.



 Comments   
Comment by fowlie [ 18/Mar/14 08:22 AM ]

This issue seems quite old, yet no fix for it. How about prioritizing it?

Me and my team would love to have this fixed! Our deployment tool detects changes with checksums, and to avoid having stub classes in source control, we generate them on the fly, thus everything gets deployed all the time, it's very annoying and time consuming.

Comment by ciscox83 [ 18/Mar/14 05:30 PM ]

Quoting fowlie.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 599
Tags:
Participants: jaxb-issues and peterschnitzel

 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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 600
Tags:
Participants: florianbachmann and Martin Grebac

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Java Source File IfAddPluginImpl.java    
Issuezilla Id: 609
Tags:
Participants: jaxb-issues, laune and lexi

 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 12:49 PM ]

Created an attachment (id=290)
implementation of proposed plugin

Comment by lexi [ 23/Jan/11 01:54 AM ]

http://confluence.highsource.org/display/J2B/Inheritance+plugin





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 624
Tags:
Participants: jaxb-issues and tuomas_kiviaho

 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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 629
Tags:
Participants: clecompt and jaxb-issues

 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-808] Class Binding Declaration with Simple Types Created: 24/May/09  Updated: 12/Oct/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 21
Tags:
Participants: fribeiro, fribeiro, lexi, Martin Grebac and sstarcher

 Description   

Unlike defined in the 7.7.3.2 section of the JAXB spec, the jaxb:class binding
declaration isn't working with simple types:

<jaxb:bindings node="//xs:simpleType[@name='Type']">
<jaxb:class ref="Type" />
</jaxb:bindings>



 Comments   
Comment by fribeiro [ 08/Sep/09 07:29 PM ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 12:34 PM ]

Any update yet?

Comment by lexi [ 16/Jan/11 12:47 PM ]

This might be a JAXB problem not maven-jaxb2-plugin.

Comment by fribeiro [ 16/Jan/11 01:07 PM ]

You might want to update the ticket (I can't) to say the issue was reported against 2.1.2.

Comment by Martin Grebac [ 17/Jan/11 01:57 AM ]

Would you please provide full testcase? Thanks.

Comment by sstarcher [ 16/Apr/12 04:34 PM ]

+1 for people who care





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File UnmarshallerImpl.patch    
Issuezilla Id: 655
Tags:
Participants: darran_lofthouse and jaxb-issues

 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 08:41 AM ]

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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 658
Tags:
Participants: Martin Grebac and Mike Calmus

 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 08:36 AM ]

Thanks for catching this. Changing to enhancement, reassigning to myself.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 670
Tags:
Participants: jwiedmann, kohsuke and Martin Grebac

 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 08:50 AM ]

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 11:58 AM ]

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 12:48 AM ]

Thanks for info, changing to enhancement.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 677
Tags:
Participants: Martin Grebac, mattbishop and Pavel Bucek

 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 11:27 PM ]

marking as enhancement





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 679
Tags:
Participants: lucasmo and Martin Grebac

 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 02:40 AM ]

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 09:27 AM ]

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 01:45 AM ]

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 01:46 AM ]
      • Issue 667 has been marked as a duplicate of this issue. ***




[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 682
Tags:
Participants: jpleed3, Martin Grebac and tjstavenger

 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 12:26 PM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 683
Tags:
Participants: Martin Grebac and Thomas De Smedt

 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 10:30 AM ]

Interesting idea. Perhaps we could come up with a property for this?





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 690
Tags:
Participants: Martin Grebac and skaffman

 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 04:46 AM ]

This requires api change, changing subcomponent.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 698
Tags:
Participants: converginglight, flb_at_ll, Martin Grebac, Pavel Bucek and skaffman

 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 01:47 PM ]

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 01:55 PM ]

This is a great idea, and is exactly what the standard @PostConstruct annotation
is intended for.

Comment by Pavel Bucek [ 11/Oct/09 10:58 AM ]

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 02:23 PM ]

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 03:11 PM ]

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 03:52 PM ]

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 04:20 PM ]

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 02:33 PM ]

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 02:28 AM ]

It's defined in jsr222:

http://jcp.org/en/jsr/detail?id=222

Comment by converginglight [ 16/Oct/09 12:30 PM ]

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 12:53 PM ]

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-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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 700
Tags:
Participants: jaxb-issues and jitu

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