My gut feeling is that the Java class IntegerValidator needs to be revisited if that additional code should be added, namely the validate() method in this class.
Werner > -----Ursprüngliche Nachricht----- > Von: Simon Lord [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 17. April 2007 12:47 > An: [email protected] > Betreff: Re: AW: AW: AW: [castor-user] [XML] Upgrading to Castor 1.1 > > http://jira.codehaus.org/browse/CASTOR-1948 > > Ralph's idea is not bad at all ;) it's a definite possibility for us - > i'll speak to my colleagues soon about it. > > Either way we're still happy to help with adding backward compatibility. > > > Thanks > > Simon Lord > > > > > Werner Guttmann wrote: > > Yes, please. I've CCed the dev list for any discussions that happen > outside of the Jira issue (though I suppose most of the discussions will > happen within this Jira issue). > > > > Werner > > > > PS Actually, I think that Ralf's suggestion is not a bad one, if there > isn't too any places where this code fragments need to be added. > > > >> -----Ursprüngliche Nachricht----- > >> Von: Simon Lord [mailto:[EMAIL PROTECTED] > >> Gesendet: Dienstag, 17. April 2007 11:46 > >> An: [email protected] > >> Betreff: Re: AW: AW: [castor-user] [XML] Upgrading to Castor 1.1 > >> > >> Hi Werner, > >> > >> I've spoken with my colleagues and we agree that backwards > compatibility > >> in Castor is *really* important if you want people to upgrade (and > >> therefore stick with Castor in the future) and we are happy to work > with > >> you to achieve this. > >> > >> I guess the first port of call is to create a Jira? Shall i do this? > >> > >> > >> Thank you for your time > >> > >> Simon Lord > >> > >> > >> > >> > >> > >> > >> Werner Guttmann wrote: > >>> 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 > >>> > >> --------------------------------------------------------------------- > >> 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
