|
Ok finally was able to reproduce it, and isolate. It also required patching Hibernate ORM and swap it in a custom build of WildFly.
The TRACE log from JBoss Modules, starting from our call to
ClassLoaderHelper.classForName( TIKA_BRIDGE_NAME, serviceManager );
and ending the log recording after the CNFE is thrown:
Our classloading strategy is able to load the extensions from the user WAR, but while the org.hibernate.search.bridge.builtin.TikaBridge class is found in the composite org.hibernate.search.cfg.impl.DelegatingClassLoaderService - which includes both our modules and the user extension points - it's then identified as found within the hibernate-search-engine module; when this happens, the Class definition is declared as "found" but bound to the hibernate-search-engine module's classloader, and no longer to the composite classloader. In a second step, the class definition needs to be initialized within its associated classloader (the hibernate-search-engine module), but dependencies to org.apache.tika.parser.Parser and similar (imported by TikaBridge) have it fail.
Looks like a possible workaround is to override the TCCL with a fully composite classloader before initializing TikaBridge, however this is horrible, a better solution would be to extract the TikaBridge and its dependencies in a custom module - so that the user could include this jar as an extension within its own appllication, together with the Tika dependencies. And alternative would be to bundle all necessary Tika dependencies.
|