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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
