HSEARCH-1106 : Compile error on MappingModelMetadataProvider on some JVMs only
HSEARCH-1106 Add comments pointing to this issue
HSEARCH-1114 javadoc typo: changed StoreNorm -> Norms
add missing copyright headers
HSEARCH-1110 Add a test to verify stored indexes in Infinispan's cacheloader
Temporarily disable a test which is troublesome on Sybase (until someone fixes HSEARCH-1107)
HSEARCH-1090 Testcase for unclosed files
HSEARCH-1090 IndexReader leaks file handles on close
HSEARCH-1117 Minor version update of core components
Refactoring IndexingActionInterceptorTest and adding test case for mass indexer
Refactoring LuceneQuerySortTest and adding a test for a custom FieldComparator
Change to sort by id test in SortTest (was erroneously testing "default" ordering)
HSEARCH-1118 Making sure that hibernate.search.worker.scope is used instead of just worker.scope
HSEARCH-1118 Making sure the async settings are getting used using Byteman
HSEARCH-1118 Removing note about hibernate.search.default.worker.batch_size
HSEARCH-1118 Removing non existing reference (referred table got deleted)
HSEARCH-1118 Removing mention of obsolete property 'hibernate.search.worker.batch_size'
HSEARCH-1118 Formatting and removing unused getWorkerBatchSize
HSEARCH-1122 Update Avro dependency to 1.6.3
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.