Thread: [Simple-support] classloaders, interfaces, and misc. issues
Brought to you by:
niallg
Menu
▾
▴
simple-support
|
From: A. R. <ami...@am...> - 2007-08-05 12:19:16
|
Hi, and once again thanx for this great package! I've come across a few issues when using the package: 1. When using Simple's jar file in an extension directory while the application is in the regular classpath, this results in a ClassDefNotFoundException when attempting deserialization. When researching the problem, I came across the article at http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf (somewhat old but still relevant) that explains the problem in detail and provides two possible solutions. In a nutshell, calling Class.forName(name) in DefaultStrategy uses the classloader that was used to load the library, which is the ext classloader, which doesn't see the classpath. I've tried replacing this call with both suggested alternatives, and they both worked properly: type = Class.forName(name, true, Thread.currentThread().getContextClassLoader()); type = Class.forName(name, true, ClassLoader.getSystemClassLoader()); It sounds like the former is the better one, since it gives the caller the ability to set a custom classloader as well, but I'm not sure if there are other consequences of using one or the other. In any case, both worked in my case and allowed deserialization to complete successfully. 2. As a side note, if the DefaultStrategy were publicly extendable, making such a fix locally (until it is integrated into the Simple distribution) would be quite simple. However, with the existing DefaultStrategy, the only way to do this is to copy the entire class into a custom strategy with a single-line fix, or, as I did when testing the solutions, change the original package and recompile it. I think making DefaultStrategy easily extendable would be the best solution for making such small tweaks to the default strategy. 3. When attempting to serialize an interface or abstract class (as the root element), and exception is thrown. However, making a simple wrapper class with a single field holding this interface/abstract class works correctly by serializing the "class" attribute for correct deserialization of the original concrete class. It would be great if this were fixed so it worked also on the top level class without requiring this redundant wrapper. Note that this would also enable deserializing an arbitrary object without knowing it's type in advance! 4. The Persister class javadocs don't specify how it relates to thread safety - it can be helpful to specify explicitly whether a single static instance can be used from many threads, or each thread needs its own Persister instance, etc. Thanks again! Amichai |
|
From: A. R. <am...@am...> - 2007-08-05 12:04:13
|
Hi, and once again thanx for this great package! I've come across a few issues when using the package: 1. When using Simple's jar file in an extension directory while the application is in the regular classpath, this results in a ClassDefNotFoundException when attempting deserialization. When researching the problem, I came across the article at http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf (somewhat old but still relevant) that explains the problem in detail and provides two possible solutions. In a nutshell, calling Class.forName(name) in DefaultStrategy uses the classloader that was used to load the library, which is the ext classloader, which doesn't see the classpath. I've tried replacing this call with both suggested alternatives, and they both worked properly: type = Class.forName(name, true, Thread.currentThread().getContextClassLoader()); type = Class.forName(name, true, ClassLoader.getSystemClassLoader()); It sounds like the former is the better one, since it gives the caller the ability to set a custom classloader as well, but I'm not sure if there are other consequences of using one or the other. In any case, both worked in my case and allowed deserialization to complete successfully. 2. As a side note, if the DefaultStrategy were publicly extendable, making such a fix locally (until it is integrated into the Simple distribution) would be quite simple. However, with the existing DefaultStrategy, the only way to do this is to copy the entire class into a custom strategy with a single-line fix, or, as I did when testing the solutions, change the original package and recompile it. I think making DefaultStrategy easily extendable would be the best solution for making such small tweaks to the default strategy. 3. When attempting to serialize an interface or abstract class (as the root element), and exception is thrown. However, making a simple wrapper class with a single field holding this interface/abstract class works correctly by serializing the "class" attribute for correct deserialization of the original concrete class. It would be great if this were fixed so it worked also on the top level class without requiring this redundant wrapper. Note that this would also enable deserializing an arbitrary object without knowing it's type in advance! 4. The Persister class javadocs don't specify how it relates to thread safety - it can be helpful to specify explicitly whether a single static instance can be used from many threads, or each thread needs its own Persister instance, etc. Thanks again! Amichai |
|
From: Niall G. <gal...@ya...> - 2007-08-07 11:43:37
|
Hi, In relation to your comments: 1) Yes I am aware that the Class.forName is not going to offer a suitable solution to the problem you mention. At the same time there are issues with the class loading strategies available. Ill make sure that a better class loading strategy is used in the next release. 2) Ya, this is true. I typically tend not to expose default compontents in this way, however it may be a good idea to allow extension. 3) Mmm.. I thought this was working, I am sure I have a test case for it. Perhaps I have only supported abstract classes? Certainly an addition that should be there. 4) The Persister is fully thread safe and can be shared without concerns, I will mention it in the javadocs. Thank you for your feedback, Niall --- "A. Rothman" <ami...@am...> wrote: > > Hi, and once again thanx for this great package! > > I've come across a few issues when using the > package: > > 1. When using Simple's jar file in an extension > directory while the > application is in the regular classpath, this > results in a > ClassDefNotFoundException when attempting > deserialization. When > researching the problem, I came across the article > at > http://www.javageeks.com/Papers/ClassForName/ClassForName.pdf > (somewhat > old but still relevant) that explains the problem in > detail and provides > two possible solutions. In a nutshell, calling > Class.forName(name) in > DefaultStrategy uses the classloader that was used > to load the library, > which is the ext classloader, which doesn't see the > classpath. I've > tried replacing this call with both suggested > alternatives, and they > both worked properly: > > type = Class.forName(name, true, > Thread.currentThread().getContextClassLoader()); > > type = Class.forName(name, true, > ClassLoader.getSystemClassLoader()); > > It sounds like the former is the better one, since > it gives the caller > the ability to set a custom classloader as well, but > I'm not sure if > there are other consequences of using one or the > other. In any case, > both worked in my case and allowed deserialization > to complete successfully. > > 2. As a side note, if the DefaultStrategy were > publicly extendable, > making such a fix locally (until it is integrated > into the Simple > distribution) would be quite simple. However, with > the existing > DefaultStrategy, the only way to do this is to copy > the entire class > into a custom strategy with a single-line fix, or, > as I did when testing > the solutions, change the original package and > recompile it. I think > making DefaultStrategy easily extendable would be > the best solution for > making such small tweaks to the default strategy. > > 3. When attempting to serialize an interface or > abstract class (as the > root element), and exception is thrown. However, > making a simple wrapper > class with a single field holding this > interface/abstract class works > correctly by serializing the "class" attribute for > correct > deserialization of the original concrete class. It > would be great if > this were fixed so it worked also on the top level > class without > requiring this redundant wrapper. Note that this > would also enable > deserializing an arbitrary object without knowing > it's type in advance! > > 4. The Persister class javadocs don't specify how it > relates to thread > safety - it can be helpful to specify explicitly > whether a single static > instance can be used from many threads, or each > thread needs its own > Persister instance, etc. > > Thanks again! > > Amichai > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? > Stop. > Now Search log events and configuration files using > AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/> _______________________________________________ > Simple-support mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simple-support > ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 |
