An extension to the schema would generate and overwrite any manual
changes, which would indeed be a pain. The idea is to have the
subclasses maintained manually (in a different source tree) without
risking overwrites. The code injector example
(
http://www.java.net/blog/kohsuke/archive/2005/06/writing_a_plugi.html)
is an option but only for very small amounts of code that hardly ever
change. Otherwise I'd prefer to have some IDE support.
But even if the 'why' is marginally relevant, I consider this an
opportunity to gain some new JAXB knowledge: toying around with the
plugin api already provided some, but knowing where to 'hook into' the
code would help. There seems to be little documentation and the JavaDoc
seems to be primarily aimed at those familiar with the code.
Floris
On 06/12/2011 05:46 PM, Wolfgang Laun wrote:
> The first question that comes to my mind is: Why create those
> subclasses manually? The natural approach seems to be an extension of
> the XML schema. "Some logic" can be inserted using available plugins.
> Fiddling with the generated code tends to be a pain in the neck as well
> as a maintenance risk.
>
> -W
>
> On 12 June 2011 17:14, Floris Ouwendijk <floris233_at_gmail.com
> <mailto:floris233_at_gmail.com>> wrote:
>
> Hi,
>
> I've been looking at how to customize the JAXB binding to implement
> the Generation Gap Pattern but cannot figure it out.
> Essentially I would like to have xjc generate the code from a schema
> file, where the generated code contains the basic implementations. I
> will manually create subclasses of those generated files containing
> some logic. When unmarshalling a document, I want the type to be my
> subclass, and navigating the document I want the return types of all
> elements (or those that I specified as using the pattern) to be my
> subtypes, and not the basic implementations.
> I've tried the class binding declarations and modifying the object
> factory, but while instances of my classes are returned, the types
> are the basic types, thus forcing me to cast.
> It seems the route to go then is to create a plug-in that keeps all
> references to the specified name, but generate the file with a
> slightly different name.
> Any suggestions on where to make the modifications? So far I've had
> no luck inserting new CClassInfo objects into the model during
> postProcessModel. (Or is there a way using the regular customizations?)
>
> Kind regards,
> Floris
>
>