On 2/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
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.
Yeah, I have to do that as well I just found out.
* 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.
Cool. I tested a little bit and saw your stuff works for anon/ local classes.
* 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?
Take a look at SerializableChecker$HandleTable, which I basically
copied from ObjectOutputStream. That's what you should use instead of
the hasmap you're using as you're looking for system hash rather then
what the object thinks it's identity should be like. It's not only way
cheaper to do that, but it also shields against problems that can
arise when objects have a hashcode implementation that e.g. depends on
a hibernate session being available and current. But anyway, the speed
argument alone is more than worth it.
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 ... :)
Yeah. Error reporting isn't very helpful atm. E.g. this is a stacktrace:
Exception in thread "main" java.lang.RuntimeException: Failed to get
the constructor from clz: class TestWithError$1Foo
at wicket.util.io.ClassStreamHandler.<init>(ClassStreamHandler.java:171)
at wicket.util.io.ClassStreamHandler.lookup(ClassStreamHandler.java:124)
at
wicket.util.io.WicketObjectOutputStream.writeObjectOverride(WicketObjectOutputStream.java:112)
...
That's a test where an object is not serializable.
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..
I've searched around for it, and it doesn't seem to be a license
violation. And as you said, many others, including JBoss, use Unsafe.
Related read: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6379948
But it is a very very very interesting class that Unsave!! do you see for
example the reallocateMemory method..??
That looks very very cool! :)
But I wouldn't get carried away. :) It's an internal class and people
are officially encouraged to never depend on sun.* classes. And that
10 times more important for a framework too.
Eelco
