Currently I’m busy on a project using XML messaging. I have one general schema, with abstract types and some reusable type definitions and elements. For each sort of message I’m dealing with, there’s a separate schema (with a different target namespace) that imports the general one. In other words, it’s a two-level hierarchy. Pretty simple.
Each of these schemas is used for generating Java classes. Each schema corresponds to one package. The code generation is handled by the Maven JAXB 2.1 plugin. When I’m using the code, I create a separate JAXBContext for each message type. The JAXBContext is created using the package name of the general schema and that of the specific message type, so the context should only see those classes it has to deal with.
To my surprise I noticed that when I unmarshal an XML document to beans and then marshal those back to XML, there were namespace declarations for each and every message type (= schema target namespace). Wondering how JAXB got that info despite the context scope, I found out some @XmlSeeAlso annotations were placed on some abstract class definitions. This causes JAXB to seek information regarding classes outside of the target packages.
Is there any way to avoid generating the @XmlSeeAlso annotations? Looking around here, I found out this was new for JAXB 2.1. I could switch to an XJC plugin for 2.0, but I’m not certain if this would have unwanted side effects. Plus, I’d like to keep following new JAXB releases in the future. The unrequired namespace declarations are not a problem (the XML is still valid) but will be confusing once more message types are added. Also, this has made it clear my JAXB contexts loaded more classes than I thought and are basically duplicates of each other. I could go with one context encompassing all, but I’ve got an API of my own built around this separation.
Thanks for reading and any answers supplied.
I have the same issue and I do not think there is an easy answer. I found the source of the com.sun.tools.xjc.generator.bean.BeanGenerator class which appears to be responsible for generating the java source code (jaxb-xjc-2.1.4.jar). The code, starting from line 496 looks like this:
The XMLSeeAlso annotation appears to be hard-coded and NOT optional or configurable (at least with JAXB 2.1.4).