users@jaxb.java.net

Re: Specifying Interfaces that generated classes extend/implement

From: Marcus Walls <marcus.walls_at_ASPECTIVE.COM>
Date: Wed, 09 Jul 2003 01:39:10 -0600

On Thu, 6 Mar 2003 17:46:32 -0500, Ryan Shoemaker wrote:

Apologies for re-opening this thread after 4 months, but I
now find myself needing an answer to this one as well!

I have the same problem as the original poster - I have
several schemas which have common properties, (e.g. height
and width) and I'd like to be able to pass them around in
my code without having to copy the JAXB objects into
intermediate objects.

Sticking with the original example: I have two objects
defined in two separate schemas, both of which have
width and height elements. I want to define an interface

    public interface Sizeable {
        public int getHeight();
        public void setHeight(int value);
        public int getWidth();
        public void setWidth(int value);
    }

and be able to pass the two objects around inside my code
to functions that expect a Sizeable interface.

>I still don't see how we could allow an "implements"
>customization on the generated impl classes.

[...]

>If we were to allow such a customization today, you would
>have to compile your schema and then edit the generated
>code before it could be used or even compiled.

I can see what you're saying here, however I'm not sure I
agree. If the schema definition guarantees that the RI
implementation (or any other implementation for that matter)
will generate get/set methods for width/height, then the
code should automatically compile and do what I want.

Is this something the RI could support as a vendor extension?
I guess the functionality is a bit like the serialization
interface support, but applied at a local level like implClass
rather than a global customisation.

This would save me a lot of useless code. At the moment I
have 8 schemas I cannot change, and all of them share 20+
fields. Presently I have to create a common class to store
the 20+ fields, and then have 8 pieces of conversion code
which is rather nasty, and a pain to maintain.

Marcus