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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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.
>
>
>
>