On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> for eelco: you had to disable both methods! (objectToByte and byteToObject) > For now i enabled both so that it gets tested as much as possible the coming > few days Ok, we can keep it in for a few days, but it has to improve quite a bit before it's ready for real world use.
the only thing i need to improve as far as i see now is that i need to traverse the class super classes and try to find the private readObject and writeObject methods i now only do it for the given class now (i was wondering that but i didn't see how they really did that in the normal In/Out) But i have to do it. * Does your code anonymous and local class instances and traverse
parents? Not from what I can see as you're basically doing normal introspection, right?
What do you mean wint traverse parents? The only thing i don't do is the traversing and call the read/writeobject when they are there. But for the rest all the fields are stored that are not static and not transient of the complete object. * Externalizable is not supported yet? no that is not yet supported. read and write object is. * Whenever you put objects in a hashSet/Map you'll need to be ready to
catch exceptions. Wicket was trying to serializale some Hibernate objects in my app (which it shouldn't, but that's exactly what I'm trying to diagnose) and they throw exceptions in some occasions when they are trying e.g. to use a lazy connection. If fact, we (me for the diagnostics thinghy as well) probably should just use identity directly.
Error reporting should improve a bit yes. i can do that perfectly because i can really build up the exact stack. But what do you mean with put objects in a hashset/map? what kind of object do a put in what kind of map? I guess i need now and then a bit more check if it is serializeable because it could be that i serialize now pretty much everything ... :) * The code depends on SUN code directly. I'm wondering if we can even
do that considering our license, but I'm also wondering how quick that'll fail. The diagnostics class depends on some quasi internals - quasi because they are package private but at least they are part of the normal JDK and seem unlikely to chance - and has a fall back when it recognizes it is not available. It also seems that if for whatever reason our custom serialization wouldn't be available, that's currently bad luck for the client as it just won't work then.
JBossSer does exactly the same. And i have now idea how anybody that writes custom serialization can do it any other way. Thats just not possible. Because thats the only way to set final fields (reflection can't do that since 1.2) And we in wicket uses final fields all the time. I am very curious how for example xml serialization or other kinds are really doing this.. But it is a very very very interesting class that Unsave!! do you see for example the reallocateMemory method..?? That looks very very cool! :) * It needs a lot of improvement for error reporting yes as i said above that is one of the improvements that should be done. But not directly critical for the usage. * Document soon please. Or it doesn't get done at all. will do but most methods are just ObjectOutput/InStream things. Except the simple Class id generator. (and fields updater class) johan Eelco
