I'd say that this is more a Configuration Management problem in a
distributed development environment than a JAXB problem. (You'd have it
with any kind of protocol while contents and/or representation aren't
stable or taken from the same SW baseline.)
Trying to put the baseline identifier in the data isn't going to help
unless you make sure that unmarshalling a mismatched version of the data
succeeds - at least to the degree you can access the version id.
Now if you have to reckon with differing sets of Java classes with
annotations, you might consider generating XML schemata from them and
validate your XML data against the schema. (This is simple and supported by
JAXB.)
This may exhibit more problems than just versioning problems.
If XML documents are messages, agreement about the protocol versions should
be reached in a simple
message exchanged after connection is established.
This is not along the lines you have proposed - maybe another view helps ;-)
-W
On 1 September 2012 17:58, Mike Summers <msummers57_at_gmail.com> wrote:
> We're building a many developer app using JAXB and keep stumbling on
> problems that all come back to "version" mismatch between producers and
> consumers of JAXB objects.
>
> Process hasn't alleviated the pain so I was thinking about something along
> the lines of CORBA object versioning for JAXB, maybe via a required final
> field whose values must match. Something like a Serializable
> serialVersionUID that is added to the marshal stream when the object is
> marshaled and is required and whose value is *checked* when the object is
> unmarshaled.
>
> Various check rules can be implemented, but in this case I only want
> equality. If the current version of a Foo is 1.1 and I get data to
> unmarshal whose version is anything other than 1.1 I will reject it.
>
> As an added bonus I'd like to inject the version value as the Maven
> version # :-)
>
> This is all using annotations, no xsd.
>
> Any suggestions as to a rational approach?
>
> Thanks.
>