What about using an alternative JAXB implementation (
http://www.eclipse.org/eclipselink/moxy.php ) so that you can explicitly
set the version of the JAXB library, separate than the JVM? Then it's no
longer an environmental disparity issue, but simply managed through your
normal build process...
S
On Sat, Sep 1, 2012 at 5:25 PM, Mike Summers <msummers57_at_gmail.com> 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.
>>>>>
>>>>
>>>>
>>>
>