Marshalling Objects extending JAXBElement linked by @XmlElementRef · Issue #882 · javaee/jaxb-v2 (original) (raw)

As described here, there is a difference, how JAXB will generate classes:

http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html

We have the following schema files:

Schema "references.xsd" with reusable elements:

Schema "object.xsd" with some real constructs like:

JAXB will generate a class for the element object and may name it "Object" with an @XmlRootElement annotation on it, while the property for "foo" and "bar" will get optimized the the type "common:sometype". So we will loose the information about the element "foo" and "bar", which causes problems, because this is a choice and JAXB will no longer be able to differ between them. The List accepts the generated class for "common:sometype" twice.

@XmlElementRefs({
@XmlElementRef(name = "foo", namespace = "...", type = CommonSomeType.class),
@XmlElementRef(name = "bar", namespace = "...", type = CommonSomeType.class),
})
protected List<JAXBElement<? extends Serializable>> fooOrBar;

As you can see, JAXB will not be able to know, which CommonSomeType is a "bar" or "foo".

Because of this, I added the following bindings to the binding.xjb:

Now, JAXB will generate these two classes "Foo" and "Bar" instead of directly using the "common:sometype"-class for these properties and the choice can be marshalled. This issue is not mainly about the "xs:choice", btw.

The problem is, that the JAXBContext cannot find these two classes in the contextPath, because they look like this:

public class Foo extends JAXBElement {
private QName qname = ....
}

When analyzing JAXBContext.toString() I also do not see them in the list of the known classes.

In this example, the generated Object class looks like this:

@XmlRootElement(...)
public class Object {
@XmlElementRef(name="foo", namespace="...", type=Foo.class)
private Foo foo;
}

How is one supposed to be able to marshal classes, that have properties annotated with @XmlElementRef, which link to classes like Foo?

If you want a real world example, try generating classes using the Sun XACML 1.0 policy schema:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML10

The PolicySet element uses such a choice leading to these problems.