Resolve classloading issues (for eg. OSGi) without changing API

While the JARs deploy happily and the speedy serialization is great, deserialization doesn't work (and wouldn't without the jackson bundles importing everything).

I initially had the same conclusion as in JACKSON-323, but instead patched the latest trunk using Thread.setContextClassLoader - this should AFAIK have no effect on existing J2SE apps, though I know it's possible to do some exotic stuff with custom classloaders. Not given much thought regarding framework threads (app servers etc), but guess an OSGi config flag could added to ensure all classloading strategies catered for.

Attached is a patch against trunk rev 1098, it affects

org.codehaus.jackson.map.type.TypeParser
org.codehaus.jackson.map.ObjectMapper
org.codehaus.jackson.map.jsontype.impl.ClassNameIdResolver

With two specific repeated changes:

• Class<?> cls = Class.forName(className);

+ ClassLoader loader = Thread.currentThread().getContextClassLoader();

+ Class<?> cls = loader.loadClass(className);

and in ObjectMapper's readValue methods:
+ ClassLoader loader = (valueType.getClassLoader() == null) ? Thread.currentThread().getContextClassLoader() : valueType.getClassLoader();

+ Thread.currentThread().setContextClassLoader(loader);

It certainly doesn't give complete coverage, only the readValue(*, Class<T>) methods, but allows me to serialize and deserialize by a bundle importing the T class and Jackson bundles.
Sorry I don't have time to create a testcase and more complete patch, but hope this is of some use.