[Simple-support] classloaders, interfaces, and misc. issues

[A. R. <am...@am...>]

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