My approach is to create a bean manager for each element or type and put functionality in the bean manager. The manager does not implement bean's interface but takes the bean as argument in its static functions. Bean's business logic is implemented in those functions and results are set back to the bean. This way one avoids the marshalling/unmarshalling problem. Eventhough a subclass can somehow be marshalled, there is no way to unmarshal datasource back to inheriting class. (don't know if change the
static field PRIMARY_INTERFACE_CLASS of generated classes work).
In the delegation manner, every unmarshalling behavior creates new instances of the member variable. After unmarshalling those member variables need to be updated. That may be the most obervious disadvantage of delegation.
The interface that marshaller operates with is indeed xxxType, an interface that extends the element interface. That's why UnmarshallableObject, XMLSerializableObject and ValidatableObject are
required. If your calss extends the corresponding xxxTypeImpl class, this is not a problem. However, unmarshalling is still a problem.
My hope is a new schema that not only descripts attributes and children of an element, but possible operations on the element. Just like SOAP descriptor does. JAXB then can bind not only bean properties but operations as well, so that the generated interfaces of element/complexType contain function signatures. Datasource can be unmarshalled to xxxImpl by convention, a concrete class that programmer later derives from compiled schema package.
BTW PRIMARY_INTERFACE_CLASS is declared as final. If it was mutable,
we might be able to customize unmarshaller to subclass at runtime. Can that restriction be removed?
Craig Raw <craig_at_quirk.co.za> wrote:
>Hi,
>
>In order to add functionality to a class generated by JAXB, one has two
>options: inheritance or delegation. Inheritance is dodgy because of
>brittleness, the equals() contract, and appropriateness of this
>mechanism. As was pointed out in an earlier post, is XMLCustomer really
>a valid new type of Customer?
>
>Delegation, then, involves creating a class with the binding object as a
>member variable. Take BarDelegator with a member variable of Bar. It
>needs to implement the Bar interface as well, and delegates all Bar
>methods to the member variable. Additional methods with extra
>functionality can be added normally. Well and good.
>
>However, BarDelegator, in order to participate in the JAXB marshalling
>process, needs to do more. If you have interface Foo containing method
>'getBar();' and 'setBar( Bar bar );', you will run into trouble
>marshalling a Foo which has had 'foo.setBar( barDelegator );' called on
>it. BarDelegator needs to implement 3 extra interfaces from jaxb-ri.jar,
>namely:
>
>com.sun.xml.bind.unmarshaller.UnmarshallableObject
>com.sun.xml.bind.serializer.XMLSerializable
>com.sun.xml.bind.validator.ValidatableObject
>
>If the methods these create in BarDelegator all delegate to the Bar
>member variable as before, all is well.
>
>No doubt this is old hat to experienced JAXB developers, but my question
>is: Is this a valid use of public API? The use of Suns interfaces seems
>to suggest not. If not, how 'published' are Suns interfaces? Are there
>any other ways to extend functionality of a jaxb class?
>
>TIA,
>Craig
>
>-