On Oct 23, 2007, at 12:32 AM, Adam Heath wrote:
David E Jones wrote:Interesting... this is worrisome as it means something isn't using the ByteWrapper properly. Only the bytes in the ByteWrapper should be sentto the database, not a serialized version of the object itself. Because this issue exists we have a problem though... updating the ByteWrapper object will make existing database data stored with it useless unless the ByteWrapper object NEVER changes.Tim, do you have a full stack trace on that? I'd like to trace through the code in the content stuff as well as the database that does both thesaves and loads.As an interim fix, change the ByteWrapper.java file back to its original version (before the enhancements that Adam did recently). I don't know if we want to do this in the trunk, but I'll look at that as part of theabove mentioned review.Oh bother.I added 2 new write methods. Since ByteWrapper implements Serializable, and does *not* set it's own serialVersionID, one is auto-generated basedon the defined method signatures, and a hash.This can be fixed, but requires implementing the hidden private methods.That'll fix it going forward. Since there is no set serialVersionID, each compiler is free to implement it's own algorithm for setting it; it's really poor to nothave one. I'm not sure this can be fixed in a backwards compatible manner.(this goes for other serializable classes too)
The REAL problem, as I see it, is that what makes it into the database is not the binary content, it is the binary content in a serialized Java object, which is really weird. So, I'm working on code changes to get away from that and just send the bytes over.
To make migration possible I'm reverting the ByteWrapper object to it's previous state, and deprecating it.
Where an object to wrap the byte[] is needed I'm changing everything from using the ByteWrapper to use the java.nio.ByteBuffer (hopefully a little more standardized and flexible...).
-David
smime.p7s
Description: S/MIME cryptographic signature
