Hi Arnaud
Thanks for the reply. I shall take a look at the Source of Castor and see
what is to be done there.
Question with regards to changing source:
Does the new code have to be sent back to you all as this is an open source
project? Can we continue
to use the modified code with no other implications?
Question with regard to the adapter from SAX 1 to SAX 2 and removal of the
deprecation warnings:
Is there a date / release by which this will be done?
In case we modify the SourceGenerator source for resolving the issue I
talked about,
can we seamlessly move over to the newer version? Or will there be issues
of backward
compatibility?
Regards
C.P.Krishnan
-----Original Message-----
From: Arnaud Blandin [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 11:43 AM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Source Code generation..
Hi,
The code generated by version prior to 0.9.3 was not JavaBean compliant and
since
a requirement for the source code generator is to generator code compliant
with
the JavaBeans specification
(http://java.sun.com/products/javabeans/docs/spec.html), we needed
to do this change and we realize that it can introduce some real
disappointments.
If you want to have the code generated as it was before, you can always
change the source of Castor
(org.exolab.castor.builder.CollectionInfo and
org.exolab.castor.builder.CollectionInfoJ2), take a look
at the webCVS diff to see what is to be done.
For the SAX warning, we will provide our own API with adapters from/to SAX1
and SAX2.
Hope this helps,
Arnaud
-----Original Message-----
From: Krishnan, C.P. [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 11:18 AM
To: [EMAIL PROTECTED]
Subject: [castor-dev] Source Code generation..
Importance: High
Hi
I do not know if any others have faced the upgrade problem with moving from
version 0.9.2 to 0.9.3. I am using Castor strictly as a java source
generation tool.
I have an entity User which can have multiple addresses. And the schema I am
using has remained identical throughout.
Version 0.9.2 generated code for the above entity as:
1. setAddress(Address[] objAddress);
and 2. setAddress(Address vAddress, int iIndex);
This was used by us as a team on all our other development.
Now when I tried to move to Version 0.9.3 the same code is now being
generated as:
1. setAddress(Address[] objAddress);
and 2. setAddress(int iIndex, Address vAddress);
Since we are so far gone along the project this is going to cause heavy
integration issues with all source having to change to meet the new method
calls.
This sort of inconsistency between versions would also lead us to get
trapped into using an older version, even though the newer versions may
offer much more
by way of functionality. There is the promise of being to remove deprecation
warnings on org.xml.SAX.DocumentHandler e.g.
Could the developers take a look at this and resolve it? Or else give an
easy solution to make the new code get generated the way it was?
I am not sure if there are others in the field facing similar issues with
using the tool.
Regards
C.P.Krishnan
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
