在JAXB / Resteasy中使用泛型类的扩展时的NPE

Question

I am using RestEasy 2.3.4. I am encountering NPE. I have a generic base class ValueContainer, which I plan to extend as StringValue, IntegerValue, BooleanValue, etc, by substituting the generic param with the appropriate type.

I am experimenting with using the extension classes as the data transfer objects as illustrated with the following. However, I am encountering NPE at JAXB processing. Which means, I am not treating extension classes in JAXB correct. Please advise. What is the right way to do it? Thank you.

Base class:

@XmlAccessorType(XmlAccessType.FIELD)
public class ValueContainer<T> {
  @XmlAttribute
  protected T value;

  public ValueContainer() {
  }

  public ValueContainer(T value) {
    this.value = value;
  }

  public T getValue() {
    return value;
  }

  public void setValue(T value) {
    this.value = value;
  }
}

Example extension class:

@XmlRootElement (name="integervalue")
public class IntegerValue extends ValueContainer<Integer> {

  public IntegerValue() {
  }

  public IntegerValue(Integer value) {
    super(value);
  }
}

The jax-rs API interface:

@GET
@Path("/status/{what}")
IntegerValue getStatus(@PathParam ("what")Integer what) ;

The API impl:

@Override
public
IntegerValue getStatus(Integer what) {
  return new IntegerValue(what);
}

Cause of NPE, where config returns null, when my browser calls http:.../status/1:

package org.jboss.resteasy.plugins.providers.jaxb;

.....
protected JAXBContext createContextObject(Annotation[] parameterAnnotations, Class... classes) throws JAXBException
{
  JAXBConfig config = FindAnnotation.findAnnotation(parameterAnnotations, JAXBConfig.class);
  return new JAXBContextWrapper(config, classes);
}

Answer 1

I think you should throw an exception in public ValueContainer() . This ctor is there only because JAXB requires us to have public no-arg constructors (see What JAXB needs a public no-arg constructor for? ). What happens is that your object is instantiated without any argument and value remains null (it's strange your Java compiler doesn't complain).