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
