David Halonen wrote:
>
> At any rate, I have found a possible solution and would like to have a critical review.
>
[...]
>
> At any rate, what do you think of this bright idea?
>
Hi David,
We are actually in the process of publishing a FAQ that outlines almost the
same identical procedure. It should hit the web early next week...
I don't want to go into too many details in this thread, because it is all
covered in the forthcoming FAQ, but I will say that you are right on target.
Using the implClass customization this way is not how the spec intended it
to be used, but it does provide a way to subclass the generated implementation
classes.
> How fragile is this from the perspective that the next release of JAXB will have me crying in my
> milk?
>
Two part answer: the ugly double-xjc hack will only be necessary for the
current JAXB 1.0 FCS release. Using the implClass customization to specify
your own subclasses will continue to be supported in future versions of
Sun's JAXB RI. Future versions of the JAXB spec may include other mechanisms
for controlling things like replacement classes, inheritance, etc.
> What gotcha's do I have to worry about as far as marshalling/unmarshalling fields? ie, if
> OurConnection has a field named _mySpecialField that is not in the XML will it cause problems?
>
The one key thing to keep in mind is that this mechanism provides additional
behavior, not additional data. You can add methods and data to your subclasses,
but the content model will still only reflect the original content model from
the schema. You can add _mySpecialField to your subclass, but you won't be able
to marshal it out in the xml stream.
Thanks for sharing your ideas with the list!
--Ryan
> Regards, David Halonen Compuware 248.737.7300 ext 13578
>