Jochen Theodorou wrote: > oh, ok, so I looked at the wrong method.... Class.forName(String) is > related, but not the same. Which reminds me... I didn't work much with > frameworks using java standard serialization, but is it possible, that > no such frame work really exists? I mean without doing tricks like my > modified ObjectInputStream class. At last the readObject calls can not > be part of that...
I have to say, any other frameworks I've seen that persist objects do so by inspecting the object directly, either by decorating the class with their own logic or by inspecting it directly. It seems Java object serialization has not kept up with our dynamic times. >> So yes, it seems like having unrelated frames there >> would be a problem. I presume this does is not impacted by all the >> intervening Java classes because they're loaded via the bootstrap >> classloader, which would mean they have a null classloader. > > dark corners in Java ;) And overly fragile. See my comments below. > which means that it wouldn't work the first time. Because the bootstrap > method is surely defined in a class loader which is not null. And if it > does not work the first time, then it will not work at all, because I > will get an exception and stop program execution.... unless bootstrap > methods are skipped of course! JRuby run at the command line loads via bootstrap as well, so JRuby's classes have a null classloader; but this isn't typical for a production deployment, where usually JRuby gets loaded under a webapp's classloader structure. So yeah, ultimately invokedynamic won't solve this particular issue. However... > But this opens for me an interesting aspect, a possible cause of > trouble... whenever such stack frame based logic is applied we have a > potential problem with the bootstrap method... ...the problem is not in the dispatch logic, classloader logic, or either of our implementations. The problem lies in the implementation of Java serialization, which makes too many assumptions about the structure of the stack and the nature of the caller. Given these assumptions, even a simple case would fail: - application in classloader A gets a reference to an ObjectInputStream subclass created in classloader B - application tries to deserialize objects of types known only to classloader A, calling a method defined on the OIS subclass - deserialization fails because the OIS subclass method's frame sits between the application and the Java core classes; so the deserialization tries to look in clasloader B. I call bug. Deserialization should attempt to use thread context classloader first. That doesn't fix the JRuby issue, which requires deeper hooking into the object deserialization, but it would fix yours (presuming you can set a context classloader). - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
