users@jaxb.java.net

Re: Xjc generates "type=String.class" for Integer type

From: Wolfgang Laun <wolfgang.laun_at_gmail.com>
Date: Mon, 28 Mar 2011 15:35:12 +0200

You don't say why you want to have java.lang.Integer instead of the plain
int you would get from xsd:int without any customization.

But you can use
  <xs:element name="number" minOccurs="0" default="0" type="xs:int"/>
to produce a field
  @XmlElement(defaultValue = "0")
  protected Integer number;

-W


On 28 March 2011 14:59, <eirik.lygre_at_gmail.com> wrote:

> We're trying to map "xsd:int" to "java.lang.Integer", but xjc then
> generates reference to String.class.
>
> 1) A sample type looks like this
>
> <xsd:element name="testEchoMessage">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="text" type="xsd:string" maxOccurs="1"/>
> <xsd:element name="number" type="xsd:int" maxOccurs="1"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
> 2) Our mapping spec looks like this:
>
> <jaxb:globalBindings>
> <jaxb:javaType name="java.lang.Integer" xmlType="xsd:int"
>
> parseMethod="com.iknowbase.xml.bind.DatatypeConverter.parseInteger"
>
> printMethod="com.iknowbase.xml.bind.DatatypeConverter.printInteger"
> />
>
> 3) With the above mapping, we get this java code fragment:
>
> @XmlElement(namespace = "http://www.iknowbase.com/ws/iknowbase-2",
> required = true, type = String.class)
> @XmlJavaTypeAdapter(Adapter3 .class)
> @XmlSchemaType(name = "int")
> protected Integer number;
>
> public Integer getNumber() {
> return number;
> }
>
> public void setNumber(Integer value) {
> this.number = value;
> }
>
> The question then has to do with the "@XmlElement(...
> type=String.class)" annotation. This looks wrong, and causes problems
> when using jackson to render the bean based on jaxb annotations.
> (Jackson fails with the IllegalArgumentException: "Illegal
> concrete-type annotation for method 'number': class java.lang.String
> not a super-type of (declared) class java.lang.Integer"
>
> -> Does this sound like a problem with jaxb?
> -> Is there a way around this, to either avoid having
> "type=String.class" generated, or to have "type=Integer.class" (which
> sounds more correct).
>
> Eirik
>