Yes, this seems to be the case. But I have a query at requirements level.
When we deserialise an object the exact state of the object
is retained. That is to say size of an array after deserialisation is same
as
what it was while serialising it.
In our case however the size of the array doubles.
I am not very sure how this could be overcome, or how convieneint
it would be to modify the code, but shouldnt the worflow be something
like this while unmarshalling.
(a) add all the elements of the array to temporary arraylist as they are
encountered in the xml file.
(b) convert this to an array when all elements have been processed
(c) set the array only once using setter.
The workflow currently seems to be this,
(a) get current state of the array.
(b) convert it to an arraylist.
(c) add the new element to the arraylist
(d) convert the arraylist to an array
(e) set the new array
If you see the need for a change in the worflow, I would like to help you
with
it if possible.
Thanks,
Uddhav
----- Original Message -----
From: "Keith Visco" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 11:05 AM
Subject: Re: [castor-dev] Problem with predefiined arrays while
unmarshalling
>
> The unmarshalling seems correct to me...
>
> Castor won't overwrite the strings that already in the array.
>
> --Keith
>
> Uddhav wrote:
> >
> > This is the java source,
> > public class MyOrder {
> > public String[] stringArr = new
> > String[]{"strElement1","strElement2","strElement3","strElement4"};
> > public String[] getStringArr()
> > {
> > return this.stringArr;
> > }
> >
> > public void setStringArr(String[] stringArr)
> > {
> > this.stringArr = stringArr;
> > }
> > }
> >
> > This is the mapping file,
> > <?xml version="1.0"?>
> > <!DOCTYPE mapping SYSTEM "mapping.dtd">
> >
> > <mapping>
> > <class name="MyOrder">
> > <map-to xml="Order"/>
> > <field name="StringArr"
> > type="java.lang.String"
> > collection="array">
> > <bind-xml name="StringArr"/>
> > </field>
> > </class>
> > </mapping>
> >
> > After unmarshalling I print the contents of stringArr and get the
following
> > output,
> > strElement1
> > strElement2
> > strElement3
> > strElement4
> > strElement1
> > strElement2
> > strElement3
> > strElement4
> > i.e. twice the size of the intialised array.
> >
> > I tried to add a method using set-method as
> > set-method="addStringArr"
> > The corresponding java class has following signature
> > public void addStringArr (String stringArr)
> >
> > I found that the function is never reached so I tried changing
> > it to String[] from String. The behaviour is still the same.
> >
> > Thanks,
> > Uddhav
> >
> > ----- Original Message -----
> > From: "Keith Visco" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, February 25, 2002 10:06 AM
> > Subject: Re: [castor-dev] Problem with predefiined arrays while
> > unmarshalling
> >
> > >
> > > Can you attach a small example which demonstrates the problem?
> > >
> > > A possible work around is to use an "add method" so you can control
> > > the collections...
> > >
> > > <field name="someClass" set-method="addSomeClass" ...>
> > >
> > > Note that you need to use the set-method attribute to specify the
> > > add-method.
> > >
> > > Thanks,
> > >
> > > --Keith
> > >
> > > > Uddhav wrote:
> > > >
> > > > Hi,
> > > > I have a class which intitalises the size of the array
> > > > when the class is instantiated.
> > > > SomeClass[] refClass_ = new SomeClass[4];
> > > > // corresponding getter-setter
> > > >
> > > > Marshalling works fine however when I unmarshal I have
> > > > eight elements in the array instead of the expected four.
> > > >
> > > > Has anyone faced a similar situation? If so, what is the
> > > > possible workaround for this.
> > > >
> > > > Thanks,
> > > > Uddhav
> > > >
> > >
> > > -----------------------------------------------------------
> > > 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
>
> -----------------------------------------------------------
> 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
