On Sep 9, 2008, at 9:32 PM, Jochen Theodorou wrote:
> > Hi all, > > is there somewhere documentation as of what class loader will be > used if > Class.forName is called with only a String? <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#forName(java.lang.String) > It uses the defining class loader of the current class (one to which the code executing the Class.forName call belongs). > and maybe if there is a way > to influence that? No... > The background is, that deserialization often fails > to work in Groovy because of class loader issues when used in scripts. > Afaik deserialization uses Class.forName(String) to do its work. Well, that ain't completely true. It'll use the loader of the first class on the stack that has a non-null loader (meaning, it's not a class loaded from the system class loader). But from the POV of the overall effect, that doesn't change much. *Sigh* It's an old, sad story. Serialization predates thread context class loaders, hence doesn't rely on them (for backwards compatibility), even though that would be the ideal thing to do. It's one of those places where I *really* wish Sun would break backwards compatibility, because the default behaviour hardly seems ideal. When it's your code doing deserialization, you can of course just override resolveClass() as you did below. > I did find two "solutions" to this problem: > > (1) ensure there is only one class loader. > this solves a few cases, but in other cases you want more complex > structures and it would be very nice if a evaluate call from inside a > script wold just do > > (2) use this class: > >> ObjectInputStream ois = new ObjectInputStream(new >> ByteArrayInputStream(data)) { >> protected Class resolveClass(ObjectStreamClass objectStreamClass) >> throws IOException, ClassNotFoundException { >> return Class.forName(objectStreamClass.getName(), true, >> myClassLoader); >> } >> }; > > instead of ObjectInputStream. > > Now this gives me several problems... for once I would like to have > more > control over the serialization and deserialization process, but with > the > standard deserialization there is no chance it seems. Well, overriding resolveClass() seems like a good solution to me. What problems do you have with that? Attila. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
