-
1. Re: Making JavassistTypeInfo serializable
alesj Mar 31, 2010 6:10 AM (in response to kabirkhan)If I do the same for JavassistTypeInfo, then that will load the class. Is that a bad thing? Probably...
I wouldn't bother too much with this -- TypeInfo/ClassInfo serialization shouldn't concern itself with lazy-loading.
Or, if this actually becomes a problem -- which I very much doubt -- then we'll change the mechanism for JavassistTI, OK? ;-)
-
2. Re: Making JavassistTypeInfo serializable
dmlloyd Mar 31, 2010 10:25 PM (in response to kabirkhan)Kabir Khan wrote:
Looking at https://jira.jboss.org/jira/browse/JBREFLECT-16 I wanted to do the same as I did to make the reflect flavour properly serializable, which was simply to add this to ClassInfo, as mentioned here http://community.jboss.org/message/534270#534270:
[...]If I do the same for JavassistTypeInfo, then that will load the class. Is that a bad thing? Probably...
The alternative for this simple implementation to work is to save the name and the classloader, and classloaders are not serializable.
Or am I missing something? When deserializing a class should that happen in the same classloader (or one with access to similar classes if serialized out of the vm) as the one that serialized it in the first place? If the answer is yes, then I can go forward with this.
Yes, it should, however that is really up to the serialization implementation to get right. In most cases, folks just use the thread's context classloader or just one static classloader for deserialization. Perhaps in our modular future, we'll see a trend of classes being annotated with identifiers which will locate the correct corresponding classloader on the receiving side.
In other words... don't sweat it, it should be OK.