Improve class loading to use both contextual ClassLoader and 'Class.forName(...)'

Additionally should just add something like "DeserializationContext.findClass(String className)", to enclose details. This could also use fallbacks.

Further, I think it actually makes sense to try both approaches: perhaps first contextual ClassLoader, and if that fails, Class.forName().

(I'm on 1.9.10)
The functionality is implemented in org.codehaus.jackson.map.util.ClassUtils.findClass(String), and used in ClassNameIdResolver and TypeParser, but you missed another direct usage of Class.forName(String), which is
org.codehaus.jackson.map.deser.std.ClassDeserializer.deserialize(String).

This actually led us to a problem when in an OSGi environment. In order to be able for Jackson to load our classes, we have set our classloader as the thread-context classloader before deserializion. This works fine except when we need to deserialize a String into Class<?> object, due to the fact that ClassDeserializer.deserialize(String) does not use thread-context classloader.

Is there a reason why ClassDeserializer does not make a direct use of ClassUtils.findClass() ? (It would as well prevent you from duplicating the code related to primitives).

Proposed patch : ClassDeserializer that uses ClassUtil.findClass(String)

Sounds good to me – will try to check this out later on when I have access to Codehaus SVN. I think it is simple oversight.

Fixed the remaining case; grepping didn't show up other cases. Thanks!

This will be in 1.9.12 once it gets released.