Thanks Jayashree, that looks like what we'll end-up doing too.
--Mike
On Wed, Sep 5, 2012 at 4:54 AM, jayashree viswanathan <
jviswana_at_linux.vnet.ibm.com> wrote:
> Hi Mike ,
>
> We had also encountered similar problem and we made a fix such that the
> schemas and java class created both holds the version information , it
> might help to some extent .
>
> Regards,
> Jayashree V
>
>
> On 02-09-2012 2:55 AM, Mike Summers wrote:
>
> :-)
>
> 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.
>>>>>
>>>>
>>>>
>>>
>
>