problem subclassing ObjectFactory in jax-ws web service

Question

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?

Answer 1

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.