-----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
