Hi Ryan
>
>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 really like this double xjc hack. Has this been published to a FAQ ?
>
>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.
Will the future version have JAXB spec allow specifying a superclass for the implementation class? I am a little wary of using of using the vendor extension as it might go away in the future.
I am facing a small problem with the double xjc. If I have a named complexType "foo" which contains an element "bar" of an anonymous complexType, then even if I specify a custom implementation class for "foo", jaxb will still generate an implementation class for "foo", and all that will have is a inner class for "bar". This class will overwrite the class that I generated the first time.
Obviously if I use named complexTypes instead of anonymous ones, the problem goes away.
Pratik