:-)
Our problem tends to be that we have development, qa, and acceptance teams
in 4 different countries, something like 75-100 people on a system that is
under very active development. No amount of process or CM can keep this all
consistent so we end-up with bug tickets that boil down to version
mismatches... extremely aggravating and time consuming (as I'm the guy that
deals with the marshal/unmarshal problems)
If/when I get a solution implemented I'll see if I can't release it into
the wild.
On Sat, Sep 1, 2012 at 4:04 PM, Steven Siebert <smsiebe_at_gmail.com> wrote:
> This has been a very annoying problem with me, especially when using
> jaxws+jaxb.
>
> I found that if I am very specific in my jaxb annotations, and not assume
> the way jaxb default behavior when marshaling will continue to be that way,
> it results in pretty consistent marshaling between versions and
> implementations. One way I test (though its obviously not perfect) is that
> if two jaxb implementations result in the same schema and resultant XML, it
> should be good. Note his approach is more work, sacrificing context over
> configuration advantages...but at least my clients don't complain when I
> upgrade from java 1.6 to 1.7!!
>
> Hope this helps.
>
> S
> On Sep 1, 2012 3:37 PM, "Mike Summers" <msummers57_at_gmail.com> wrote:
>
>> Thanks.
>>
>> Config management ("Process") hasn't helped, the project is too large
>> with too many players.
>>
>> This was easy with CORBA, the IDL had a version stamp that was checked.
>> It surprises me this isn't more of an issue for JAXB users.
>>
>> Thanks again.
>>
>> On Sat, Sep 1, 2012 at 12:24 PM, Wolfgang Laun <wolfgang.laun_at_gmail.com>wrote:
>>
>>> 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.
>>>>
>>>
>>>
>>