This sounds like a bug. It would be best to raise a JIRA report with a
small test case (not involving xstream)
Stephen
Huertas Fernández wrote:
Hi all, I'm having problems with serialization/deserialization of a Buffer. My
idea is to implement a persistent queue using the UnboundedFifoBuffer (well, I
want synchronized access, so I use SynchronizedBuffer too):
private Buffer queue = BufferUtils.synchronizedBuffer(new
UnboundedFifoBuffer());
When I serialize the queue to disk an it has elements, all works ok, but when I
serialize an empty queue I have some problems when I create a new object using
the serialized file(BTW, I'm using XStream 1.1.3 to produce the XML).
<org.apache.commons.collections.buffer.SynchronizedBuffer>
<collection class="org.apache.commons.collections.buffer.UnboundedFifoBuffer"
serialization="custom">
<org.apache.commons.collections.buffer.UnboundedFifoBuffer>
<default/>
<int>0</int>
</org.apache.commons.collections.buffer.UnboundedFifoBuffer>
</collection>
<lock class="org.apache.commons.collections.buffer.SynchronizedBuffer"
reference=".."/>
</org.apache.commons.collections.buffer.SynchronizedBuffer>
When I deserialize the queue it has a 'buffer' with size 1 (with null content),
'tail' and 'head' fields are 0 (they are declared transient). So, when I try to
add a new object to the queue, the sentence:
Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];
Is executed in the add() method to increase the buffer length, but the buffer remains with the same size! (buffer.length = 1 --> (1 - 1) * 2 + 1 = 1). So, the object is added and when the tail is going to be incremented, it is reset to 0!!
private int increment(int index) {
index++;
if (index >= buffer.length) {
index = 0;
}
return index;
}
So it is impossible to add new elements after an empty queue has been
serialized / deserialized.
I have solved it just not saving empty queues but deleting the file instead,
but I wanted to write to the list to know if this is a bug in the
UnboundedFifoBuffer or maybe is caused by the way Xtream serializes (but I
don't think so).
Thanks in advance,
Jose Luis.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
