HSEARCH-1115 Changed use of ReflectHelper to specify classloader

Two uses of ReflectHelper.classForName(String) were changed to use the
classForName(String,Class) form instead. In the latter method, if
the class cannot be found on the thread's context class loader then the
class will be loaded using the classloader of the class specified in
the second parameter.

In one of the cases (DocumentBuilderHelper), the DocumentBuilderHelper class
was passed, meaning that the same classloader used to load the Hibernate Search
classes will be used.

In the second case (ConfigContext), the second parameter is the class of
the SearchConfiguration implementation that was supplied to the ConfigContext.
This is better than the ConfigContext class, since the SearchConfiguration
implementation will be provided by the components using the SearchFactoryBuilder
to build a SearchFactory. This means that the components' classloader
will be used to load the Analyzer implementation class.

There are a few other uses of ReflectionHelper.classForName(String) in the Hibernate
Search codebase, but I don't think they require the same classloading logic.

When used in a Java SE environment, there is no net difference in classloading
behavior. However, in JBoss AS7 (or even OSGi) the different classloaders have
a significant effect. Specifically, when used in JBoss AS7, the modules might look
like this (where "-->" signifies 'depends on'):

  org.foo (uses Hibernate Search, implements SearchConfiguration)
   --> org.hibernate.search.engine
       --> org.hibernate (specifically the hibernate-commons-annotations JAR)
       --> org.apache.lucene
       --> others

In this case, the result of the code before this change is that ConfigContext
would expect to find the Analyzer implementation using the 'org.hibernate'
module (where the ReflectHelper class exists), which does cannot see any of
the 'org.apache.lucene' Analyzer implementations nor any implementations
provided by 'org.foo'. After this change, ConfigContext uses 'org.foo' classloader
(since that's where the SearchConfiguration class exists), and thus can see
any Analyzer implementation provide in 'org.foo', 'org.hibernate.search.engine',
'org.apache.lucene', 'org.hibernate' (if there were any), or any of the other
modules.

All unit tests run by the build pass successfully with these changes.

hibernate-search-engine/src/main/java/org/hibernate/search/engine/impl/DocumentBuilderHelper.java

@@ -57,7 +57,8 @@ private DocumentBuilderHelper() {
 
 	public static Class getDocumentClass(String className) {
 		try {
-			return ReflectHelper.classForName( className );
+			// Use the same class loader used to load this class ...
+			return ReflectHelper.classForName( className, DocumentBuilderHelper.class );
 		}
 		catch ( ClassNotFoundException e ) {
 			throw new SearchException( "Unable to load indexed class: " + className, e );

hibernate-search-engine/src/main/java/org/hibernate/search/impl/ConfigContext.java

@@ -176,7 +176,8 @@ private Analyzer initAnalyzer(SearchConfiguration cfg) {
 		String analyzerClassName = cfg.getProperty( Environment.ANALYZER_CLASS );
 		if ( analyzerClassName != null ) {
 			try {
-				analyzerClass = ReflectHelper.classForName( analyzerClassName );
+				// Use the same class loader used to load the SearchConfiguration implementation class ...
+				analyzerClass = ReflectHelper.classForName( analyzerClassName, cfg.getClass() );
 			}
 			catch ( Exception e ) {
 				return buildLazyAnalyzer( analyzerClassName );