jax-ws / jax-b / glassfish 3.1.1 web services fail to send data from beans based on variable name. · Issue #867 · javaee/jaxb-v2 (original) (raw)

Beans annotated with @XmlRootElement break xsd generation if variable has same name as class (with a lower case first letter). Produces a ref instead of a name in xsd and data is null when web service is called.

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

private InnerBlock innerBlock;

public InnerBlock getInnerBlock()

{ return innerBlock; }

public void setInnerBlock(InnerBlock innerBlock)

{ this.innerBlock = innerBlock; }

}

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

private String data;

public String getData()

{ return data; }

public void setData(String data)

{ this.data = data; }

}

@webmethod
public Block getBlock() {

return block;
}

Schema definition is generated with a ref= instead of a name= and Caller will not get a book that is set or send a book using the library class. Basically all classes are broken if they are annotated with @XmlRootElement!

if Block's variable name for the contained data is changed so that it doesn't match the class name (with the first name lower cased), e.g.

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

private OtherInnerBlock myInnerBlock;

public OtherInnerBlock getMyInnerBlock()

{ return myInnerBlock; }

public void setMyInnerBlock(OtherInnerBlock myInnerBlock)

{ this.myInnerBlock = myInnerBlock; }

}

Everything is generated and works as it should.

If you put both of those versions in block it is generated as:

<xs:complexType name="block">
xs:sequence
<xs:element ref="tns:innerBlock" minOccurs="0"/>
<xs:element name="myInnerBlock" type="tns:otherInnerBlock" minOccurs="0"/>

Again this is based on the variable name. If you have a library of beans that can be marshalled (i.e. have the @XmlRootElement on them), then all of your web services that use the standard naming convention are broken.

I have created a sample project to show this behavior.

To me, this is a critical blocking feature that needs to be fixed, prior to 3.2. I believe it has rendered 3.1.1 as unusable for us for instance.

Environment

glassfish 3.1.1, jdk 6/7 linux