Simon, This is a hard one. In theory, one could tyr to extend the existing code base in such a way that an integer conversion is treid as well (in addition to a long conversion), but I am not really convinced that this is a good option.
In other words, yes, it is a nuisance, and no, we cannot really provide you with backwards compatibility here. This was actually the main reason for us to increase the version number to 1.1, so that it is clear from the start that this is a major change. Unfortunately, not complying with the XML schema spec was considered to be the worse problem. Hence the code change. So what's your options: a) Upgrade to 1.1, re-generate code and change any classes that are affected by the int to long change. b) Investigate (together with me) whether the code could expanded so that we (re)introduce full backwards compatibility. Werner > -----Ursprüngliche Nachricht----- > Von: Simon Lord [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 17. April 2007 10:18 > An: [email protected] > Betreff: Re: AW: [castor-user] [XML] Upgrading to Castor 1.1 > > Hi Werner - i just quickly recompiled my schemas using castor 0.9.5.4 > and changed the runtime castor to 1.1 but it seems the change made at > some point between 0.9.5.4 and 1.1 remapping xsi:integer to long is > upsetting it as you can see from the following exception: > > Caused by: ValidationException: The following exception occured while > validating field: _code of class: > com.xmltravel.beans.googleaddress.Status: Expecting an Long, received > instead: java.lang.Integer; > - location of error: XPATH: /Status > Expecting an Long, received instead: java.lang.Integer > at > org.exolab.castor.xml.FieldValidator.validate(FieldValidator.java:270) > at > org.exolab.castor.xml.util.XMLClassDescriptorImpl.validate(XMLClassDescrip > torImpl.java:931) > at org.exolab.castor.xml.Validator.validate(Validator.java:124) > at > org.exolab.castor.xml.FieldValidator.validateInstance(FieldValidator.java: > 318) > at > org.exolab.castor.xml.FieldValidator.validate(FieldValidator.java:263) > ... 38 more > > > Is this a dead end for this idea? It's looking more likely that we'll > have to upgrade to castor 1.1 and fix/gen all the schemas we use in one > fell swoop. > > > Thank you for your time > > Simon Lord > > > > > > > > Simon Lord wrote: > > An excellent idea, don't know why i didn't think of trying this way > > first instead of the other way round, indeed it makes far more sense > > this way! > > > > I'll get on the case and give it a test. > > > > > > Thanks Werner > > > > > > > > Simon Lord > > > > > > Werner Guttmann wrote: > >> Simon, > >> > >> I'd personally try to avoid this scenario, as it usually works the > other > >> way around. In other words, there should not be any problems using Java > >> classes as generated with 0.9.5.4 with Castor 1.1 for (un)marshalling. > >> > >> Werner > >> > >> Simon Lord wrote: > >>> Hi Ralf, > >>> > >>> I've ran a test using beans created by castor 1.1 srcgen and tried to > >>> use them with castor 0.9.5.4 at runtime and it does not work for me. > >>> > >>> The unmarshaller simply returns a new instance of the class which was > >>> parsed to the unmarshalers contructor - but the instance only contains > >>> null objects. > >>> > >>> e.g., > >>> Unmarshaller u = new Unmarshaller(clazz); > >>> StringReader sr = new StringReader(xml); > >>> obj = u.unmarshal(sr); > >>> > >>> obj is an instance of clazz but everything in it is null :( > >>> > >>> > >>> Thanks > >>> > >>> Simon Lord > >>> > >>> > >>> > >>> Ralf Joachim wrote: > >>>> Hi Simon, > >>>> > >>>> as far as I recall there had been only small changes to Castor XML > >>>> between 0.9.5.4 and 1.0. Most of the changes to XML took place > between > >>>> 1.0 and 1.1. > >>>> > >>>> As we try not to change method signatures of generated code if > >>>> possible, there is a good chance that code generated with 1.1 works > >>>> together with 0.9.5.4. I recall only one exception where we need to > >>>> change java type of xs:Integer from int to long for compliance with > >>>> XML schema definition. > >>>> > >>>> I would give it a try and see what happens. > >>>> > >>>> Regards > >>>> Ralf > >>>> > >>>> > >>>> Werner Guttmann schrieb: > >>>>> Hi Simon, > >>>>> > >>>>> You are going to find the old files at the following locations in > the > >>>>> SVN repository: > >>>>> > >>>>> src/etc/CHANGELOG > >>>>> src/doc/release-notes*.xml > >>>>> > >>>>> which is available at http://svn.castor.codehaus.org. Please check > >>>>> the files in trunk. > >>>>> > >>>>> Regards > >>>>> Werner > >>>>> > >>>>>> -----Ursprüngliche Nachricht----- > >>>>>> Von: Simon Lord [mailto:[EMAIL PROTECTED] > >>>>>> Gesendet: Montag, 16. April 2007 12:03 > >>>>>> An: [email protected] > >>>>>> Betreff: [castor-user] [XML] Upgrading to Castor 1.1 > >>>>>> > >>>>>> Morning everyone, > >>>>>> > >>>>>> > >>>>>> The company i work for wants to upgrade to castor 1.1 but there are > >>>>>> issues with the schemas we use that need to be resolved before we > >>>>>> switch > >>>>>> to castor 1.1 (and we have a lot of schemas from different > clients). > >>>>>> > >>>>>> > >>>>>> Is there any way to use castor 1.1 beans generated from the schemas > >>>>>> with > >>>>>> older versions of castor (we seem to use 0.9.5.2 and 0.9.5.4). > This > >>>>>> would allow us to fix the schemas we have to use over time and once > >>>>>> they're all building under castor 1.1 srcgen we can swap the castor > >>>>>> being used at runtime from 0.9.5.4 to castor 1.1. > >>>>>> > >>>>>> > >>>>>> I tried to find the differences between the versions but the > >>>>>> changelogs > >>>>>> are missing between 0.9.5.4 and 1.0 - does anyone have a link to > >>>>>> these? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thank you for your time > >>>>>> > >>>>>> Simon Lord > >>>>>> > >>>>>> ------------------------------------------------------------------- > -- > >>>>>> To unsubscribe from this list please visit: > >>>>>> > >>>>>> http://xircles.codehaus.org/manage_email > >>>>> > >>>>> -------------------------------------------------------------------- > - > >>>>> To unsubscribe from this list please visit: > >>>>> > >>>>> http://xircles.codehaus.org/manage_email > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
