Right, manually doing it is probably the easiest route for me.
That works, but I am trying to automate the creation of the derived classes
as much as possible. My XSD has gone through a variety of changes as I work
through the initial stages of this project. I feel like this "XSD churn" is
probably going to happen to some degree in future projects where we reuse
some of the underlying code.
Also, some of the changes I needed didn't become apparent until I began
implementing the business logic specific to this project. After each
change, I leverage XJC to create the derived classes. With this generated
code I feel the difference between 0 and any hand-crafting of the code is
larger than with other generated code where you're already expected to
modify it to some degree.
For now, I'll probably just wind up doing this by hand, as you suggest. But
I'd be willing to help with the "extract" plugin for interfaces.
-Colin
On Wed, Mar 23, 2011 at 3:32 AM, Aleksei Valikov <valikov_at_gmx.net> wrote:
> Hi Colin,
>
> > Apologies is this is too off topic for the list...
>
> I think you're quite allrigt on topic.
>
> > So, part of my application's data model contains a simple parent-child
> > relationship, where you can think of the parent as an event (in the
> everyday
> > sense, not as in onclick) and the child as an attachment containing
> binary
> > data for that event, maybe a pdf or a Word document.
> > Anyway, my XSD defines CRUD requests and responses which are consumed by
> a
> > pre-existing web service.
> > Here's a snippet of XSD:
> > <xs:element name="CreateEventRequest">
> > <xs:complexType>
> > <xs:all>
> > <xs:element name="event" type="app:newEvent"/>
> > <xs:element name="eventAttachment" type="app:newEventAttachment"
> > minOccurs="0"/>
> > </xs:all>
> > </xs:complexType>
> > </xs:element>
> > ...
> > ...
> > <xs:element name="ReadEventResponse">
> > <xs:complexType>
> > <xs:all>
> > <xs:element name="status" type="app:statusCode"/>
> > <xs:element name="event" type="app:existingEvent" minOccurs="0"/>
> > <xs:element name="eventAttachment"
> > type="app:existingEventAttachment" minOccurs="0"/>
> > </xs:all>
> > </xs:complexType>
> > </xs:element>
> > What would be ideal is if I could have both of these implement base
> > appRequest and appResponse interfaces, which themselves could also be
> > defined in the XSD. I do use <extension> in a few places right now, for
> > instance newEventAttachment and
> > existingEventAttachment extend baseEventAttachment. But that mechanism
> > doesn't feel like the best solution here, which is why I am exploring the
> > Inheritance plugin of JAXB2 Basics.
> > I don't really know what the best way to define interfaces "on the fly"
> > would be, if it isn't possible right now. Probably a new <annotation>.
> > Defines maybe? Something like:
> > <xs:complexType name="BaseAppResponseInterface">
> > <xs:annotation>
> > <xs:appinfo>
> >
> >
> <inheritance:defines>my.app.package.BaseAppInterface</inheritance:defines>
> > </xs:appinfo>
> > </xs:annotation>
> > <xs:all>
> > <xs:element name="status" type="app:statusCode"/>
> > </xs:all
> > </xs:complexType>
> > Here, running a schema with this through XJC would produce a Java
> interface
> > called BaseAppResponseInterface which other classes could implement. The
> > interface would consist of a getter and setter for status using a
> statusCode
> > type (defined elsewhere in the XSD.)
> > Maybe there's a better way to implement the feature, or maybe there's
> > another way of doing already.
>
>
> "Extracting" interfaces from schema-derived classes makes sense for
> me. The inheritance plugin does not cover this - and I think it will
> not. There should be another plugin to "extract" interfaces. However,
> this task is far from trivial.
>
> My use case for this plugin would be to make something which works
> cross-schema. For instance, if we have WMS 1.1.0 and WMS 1.3.0
> switching from one version to another is painful at the moment. I'd
> like to have someting like WMS 1.x interfaces which both WMS 1.1.0 and
> WMS 1.3.0 classes would implement. I can the develop against WMS 1.x
> and have no trouble using one WMS version or another - I just switch
> the implementation.
>
> However I don't think my use case is your use case. You seem to have
> just few interfaces to be implemented - why don't you just write them
> manually and use the inheritance plugin? Why doesn't this work?
>
> Bye,
> /lexi
>