It looks like that when Hibernate Search is being bootstrapped in a
JPA deployment on WidFly the current context classloader was
overriden.
That's expected I guess, but it's of a type which surprised me:
-
org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader
while I really need to access the deployment classloader; on WildFly
this would be a ModularClassloader having a toString of the form:
ModuleClassLoader for Module "deployment.DeploymentName:main" from
Service Module Loader
The ClassLoaderService itself is of no use in this case as it only
exposes the same aggregate ClassLoader which is loading Hibernate
Search, while I need to get fine-grained access to the ClassLoader
which is loading the user deployment.
There is no such problem when I start the Hibernate SessionFactory
directly (not in a container): in that case the Context Classloader
matches the system one so I don't think is being set by Hibernate ORM.
If such a semantics is needed in WildFly, could we then expose the
original TCCL via an accessor on ClassLoaderService ?
Thanks,
Sanne