Not sure when you say "nothing prints" if you mean the file is empty, or
has an empty XML element. The former implies I/O error -- any errors in
your log? The latter can be a number of things.
But here are some points to consider.
First, this isn't real test code since it calls getDriver() instead of
getDriverClass(). Always post the real code you ran.
Second, I don't think you can write more than one object. The output is
a complete XML root and only one root is allowed per file. If you want
the file to contain a list of ConnProperty objects, just write the list
itself. The Encoder will dump the list in XML and all it's parts. Very
neat and simple. No loop on your part.
Third, why are you copying the object before serializing? Just curious.
Fourth, don't forget that if your object only has default data, nothing
will be written except an element representing that there is such an
object. That's because the encoder doesn't write any data that the
default constructor can take care of. So a default object is not a good
test case.
Hope this helps.
> I have a regular class, implements serializable, private variables with
> getter/setter.
[quoted text clipped - 124 lines]
>
> }
timasmith@hotmail.com - 22 Jun 2006 18:45 GMT
ooooohhhhhh mannnn
I've been banging my head against the wall for 3 hours - and all the
time it doesnt write it because my private variables are initialized to
that value????
Well I say that is absurd ... so I persist the object to XML, later
change the default value of my *private* variables - and later
XML-->Object = wrong values
icky
Obviously the workaround is initiliaze nothing but integers and
boolean.
anyway - THANKS!
> Not sure when you say "nothing prints" if you mean the file is empty, or
> has an empty XML element. The former implies I/O error -- any errors in
[quoted text clipped - 149 lines]
> >
> > }
Chris Riesbeck - 23 Jun 2006 19:05 GMT
> ooooohhhhhh mannnn
>
[quoted text clipped - 7 lines]
>
> icky
Design trade-off. The API says it uses a "redundancy elimination
algorithm," which is summarized in 2 sentences at
http://java.sun.com/products/jfc/tsc/articles/persistence4/#intro
The goal is to reduce how much is read and written.
There are lots of ways changing your class could break things later on
when decoding, so they may have felt it was a lost cause trying to
prevent that.