I generate Java classes from my XSD schema file using XJC command line tool. The ObjectFactory class generates incomplete content. It generates creation methods without JAXBElement<Type> createType decoration.
What may be the reason of this?
Regards
Dominik
Only some types in a JAXB2 XJC-generated binding need JAXBElement wrappers. Those types that have the #XMLRootElement annotation do not need the wrapper, and so the object factory does not generate one.
JAXB generates factory methods that create a JAXBElement from an object instance only if your XSD contains both a complexType definition and a separate element definition using that complexType WITH THE SAME NAME, for example:
<complexType name="my-type">
...
</complexType>
<element name="my-type" type="tns:my-type"/>
In this case, JAXB won't annotate the generated class with an #XmlRootElement annotation, but will provide the factory methods you need to create a JAXBElement from the object instance. That way, you can serialize instances of non-root-element types as root elements easily.
So, you should just add an "element"-declaration with the same name in addition to any complexType definition you intend to be used as a top-level element, and ObjectFactory will generate the expected factory methods.
Related
When using the ObjectFactory class generated by JAXB (from an XSD), I'd like to store it in a field or even constant, so I don't have to pass it around between private methods. As far as I can tell, the ObjectFactory does not have any state, at least for no schema I have used.
Are there cases, e.g. when using specific XSD constructs or JAXB properties, where the ObjectFactory is not stateless?
If there are, is it safe to use a static constant for storing the ObjectFactory or are there thread safety issues?
I was investigating object marshaling and unMarshaling using JAXB. while noticed that there is two option of getting an instance of JAXBContext.
one is based on class: JAXBContext context = JAXBContext.newInstance(ex.getClass());
Other one is based on package name: JAXBContext context = JAXBContext.newInstance(ex.getClass().getPackage().getName());
For the second way, you have to provide jaxb.index file, containing list of bean class names.
Maybe someone can explain, what is the difference between this two methods of getting JAXBContext instance? Which is better to use and when?
For the second way, you have to provide jaxb.index file, containing list of bean class names.
This is not correct. In JAXB2 this works without jaxb.index as well, the classes are "recognized" via ObjectFactory and #XmlSeeAlso.
The usual approach is to use JAXBContext context = JAXBContext.newInstance("my.package:my.another.package); as you normally want to consider all of the relevant classes and don't want to enumerate them explicitly.
I'm using JAXB bindings to unmarshal directly to my domain layer objects, which are subclasses of the generated webservice types. This is a nice solution as I can override methods and provide write custom logic, etc. However, the XJC compiler is insisting on putting the #XmlSeeAlso({MySubclass.class}) annotations on all the generated classes, which is causing them to be tightly coupled to my domain objects. This is obviously undesirable and causing all kinds of reference issues between my projects that I won't get into here.
Is it possible to generate classes that don't have the #XmlSeeAlso annotation? The actual work of unmarshaling to the subclass seems to happen in the ObjectFactory class. Is it possible to omit the jaxb binding, and substitute a custom ObjectFactory for each application? This would allow me to have autogenerated webservice types in a shared util while each web project could unmarshal to different subclasses of these types.
<jaxb:bindings node="//xs:complexType[#name='AutogeneratedWebserviceType']">
<jaxb:class implClass="my.project.CustomSubclass" />
</jaxb:bindings>
This binding will create a method in the ObjectFactory that seems to do the actual work of unmarshaling to my subclass:
public AutogeneratedWebserviceType createAutogeneratedWebserviceType() {
return new CustomSubclass();
}
I want this behavior without the #XmlSeeAlso annotation by providing a customer ObjectFactory, if possible.
Did you try running XJC with the argument -target 2.0? I believe this will disable the generation of the #XmlSeeAlso annotation.
Image you've got auto generated beans and you want to extend them with some extra functionality. So you extend the auto generated beans and in the same file you also extend the ObjectFactory and annotate it with #XmlRegistry.
When unmarshalling some object the extended ObjectFactory ins't used and therefore the auto generated beans are created.
What step am I missing to get my custom beans created? Can I tell JAXB which Factory to use? Or does JAXB not use the factory at all?
Yes, you need to specify the ObjectFactory when configuring your Unmarshaller. I think you can use something like this to provide your own ObjectFactory implemenation:
unmarshaller.setProperty("com.sun.xml.bind.ObjectFactory",new MyObjectFactory());
In a jax-ws web service I cannot directly access the JaxbContext object. JaxbContext uses the class ObjectFactory. I tried extending it (like in Jaxb Adding Behaviors). I put generated code in ObjectFactoryBase, then added
public class ObjectFactory extends ObjectFactoryBase {//.. overriden methods}
However IllegalAnnotationsException came up when publishing to weblogic, because it cannot find a certain #XmlElementDecl present in ObjectFactoryBase. When I move the method with this #XmlElementDecl to ObjectFactory it works.
No luck with adding #XmlSeeAlso({ ObjectFactoryBase.class }) either.
Edit: I now discovered that the generated ObjectFactory is not even used by the jaxws web service. So the above error message are not so relevant any more. Any idea why it is generated but not used?
Any ideas?
JAXB ObjectFactories are strange beasts. Your question has many facets, so I'll just answer with a bullet list:
JAXB1 relied on ObjectFactory to create instances of the bound classes, but with JAXB2 everything is a POJO, and the ObjectFactory becomes mostly unnecessary. It's still generated by XJC, partly for reasons of backwards compatibility.
The annotations on an ObjectFactory are complex and non-obvious, but since it's a generated class, this usually doesn't matter, and most people don't look at it anyway.
ObjectFactory is still useful on occasion because it provides factory methods for bound classes that need a JAXBElement wrapper, and it's much easier to use the provided factory methods than to do this by hand.
The JAXWS web service may choose not to use the ObjectFactory, because it's not strictly speaking necessary. However the JAXBContext may still load and parse it, depending on how the context was initialized.
I've never tried creating an ObjectFactory myself; if the model was XJC-generated then the generated ObjectFactory is usually enough, and if you have a hand-written JAXB model, the ObjectFactory is usually completely unnecessary anyway.