[ https://hibernate.onjira.com/browse/HSEARCH-1060?page=com.atlassian.jira.... ] Emmanuel Bernard commented on HSEARCH-1060: ------------------------------------------- Ah stupid modular system. What would be the cycle - TL - Owner class CL ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-1060?page=com.atlassian.jira.... ] Emmanuel Bernard commented on HSEARCH-1060: ------------------------------------------- from the classloading guide {quote}If you expect portability between different classloading environments, it is always wrong for a framework to load it's classes from the TCCL. Instead use the right classloader, which is most often the defining classloader. If the defining classloader is not the right classloader, then look for a way to get the right loader and use it to load classes. Even if you have an inheritance model with a heirarchy that sees the classes you want, it is always more correct to pick the classloader that "owns" the classes.{quote} So is the defining classloader right in my case (ie this.getClass().getClassLaodeR()? I want to load actual app entities I suspect. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-1060?page=com.atlassian.jira.... ] Emmanuel Bernard commented on HSEARCH-1060: ------------------------------------------- I expect entities from the user's code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-1060?page=com.atlassian.jira.... ] Sanne Grinovero updated HSEARCH-1060: ------------------------------------- Description: The way we usually load a resource it looks in both the caller ClassLoader and the Context ClassLoader but is satisfied as soon as a match is found. When using org.hibernate.search.util.impl.ClassLoaderHelper.getResources(String, Class<?>) we need to list all matches, to we should join the results of scanning both classloaders. Summary: ClassLoaderHelper should look in both classloaders when enumerating multiple matches for a resource name (was: ClassLoaderHelper should not look only in the current thread context classloader) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira