When starting an EmbeddedCacheManager from a different module deployed in the AS, I get this stacktrace: Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.hibernate.search.test.integration.jbossas7.model.Member at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:87) at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:232) at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:100) at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227) ... 19 more Caused by: org.infinispan.config.ConfigurationException: org.infinispan.CacheException: Unable to load component metadata! at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:386) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:341) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:328) at org.hibernate.search.infinispan.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:93) at org.hibernate.search.engine.impl.StandardServiceManager$ServiceProviderWrapper.startVirtual(StandardServiceManager.java:178) at org.hibernate.search.engine.impl.StandardServiceManager.requestService(StandardServiceManager.java:124) at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.initialize(InfinispanDirectoryProvider.java:86) at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:84) ... 22 more Caused by: org.infinispan.CacheException: Unable to load component metadata! at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:131) at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:103) at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:381) ... 29 more Caused by: java.lang.NullPointerException at org.infinispan.factories.components.ComponentMetadataRepo.readMetadata(ComponentMetadataRepo.java:53) at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:129) ... 31 more The ComponentMetadataRepo is unable to load "infinispan-core-component-metadata.dat", which contains the critically-important information for wiring together the internal components of Infinispan core. Now I think this is quite silly as locating this resource is trivial: it's in the same jar as all the infinispan core classes: infinispan-core-[version].jar so patching this looks like trivial: it's using the ClassLoader configured as defaultClassLoader in org.infinispan.factories.AbstractComponentRegistry, but really it should just use something like AbstractComponentRegistry.class.getClassLoader() ? Things get a bit more tricky with extension modules, and a lot of magic is being wrapped around this defaultClassLoader which goes beyond my understanding so I would be glad to leave this issue to some core Infinispan developer more familiar with the intentions here. Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

It turns out this resource loading issue is biting also community users; I had worked aroud the problem for deploymens in the AS7 modular classloader by wrapping the configuration parser with the "right" classloader: https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc... But today on IRC I had to point to this class as an example to another user looking to run Infinispan in an isolated classloader. Maybe we should have an (optional) Parser API which takes explicit classloaders ? Sanne On 5 April 2013 12:52, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > I'm not an expert on this (Paul, Rado, Richard should help more…), but to do what you're trying to do, I suspect there might be a need to export the .dat files somehow? I know there's a way to export the metadata in META-INF/services. > > Alternatively, you could let the Infinispan subsystem create the cache managers directly, by configuring them in advance in the standalone.xml or similar. That's what happens with Hibernate Core, which does not start its own cache manager, but simply looks it up based on what's been configured by default in the standalone.xml (there's a named cache manager for it). AFAIK. > > Take this with a pinch of salt (some details are blurry). The experts on these are really AS7 guys… > > Cheers, > > On Mar 27, 2013, at 9:22 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > >> When starting an EmbeddedCacheManager from a different module deployed >> in the AS, I get this stacktrace: >> >> Caused by: org.hibernate.search.SearchException: Unable to initialize >> directory provider: >> org.hibernate.search.test.integration.jbossas7.model.Member >> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:87) >> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:232) >> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:100) >> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227) >> ... 19 more >> Caused by: org.infinispan.config.ConfigurationException: >> org.infinispan.CacheException: Unable to load component metadata! >> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:386) >> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:341) >> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:328) >> at org.hibernate.search.infinispan.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:93) >> at org.hibernate.search.engine.impl.StandardServiceManager$ServiceProviderWrapper.startVirtual(StandardServiceManager.java:178) >> at org.hibernate.search.engine.impl.StandardServiceManager.requestService(StandardServiceManager.java:124) >> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.initialize(InfinispanDirectoryProvider.java:86) >> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:84) >> ... 22 more >> Caused by: org.infinispan.CacheException: Unable to load component metadata! >> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:131) >> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:103) >> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:381) >> ... 29 more >> Caused by: java.lang.NullPointerException >> at org.infinispan.factories.components.ComponentMetadataRepo.readMetadata(ComponentMetadataRepo.java:53) >> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:129) >> ... 31 more >> >> >> The ComponentMetadataRepo is unable to load >> "infinispan-core-component-metadata.dat", which contains the >> critically-important information for wiring together the internal >> components of Infinispan core. >> >> Now I think this is quite silly as locating this resource is trivial: >> it's in the same jar as all the infinispan core classes: >> infinispan-core-[version].jar so patching this looks like trivial: >> it's using the ClassLoader configured as defaultClassLoader in >> org.infinispan.factories.AbstractComponentRegistry, but really it >> should just use something like >> AbstractComponentRegistry.class.getClassLoader() ? >> >> Things get a bit more tricky with extension modules, and a lot of >> magic is being wrapped around this defaultClassLoader which goes >> beyond my understanding so I would be glad to leave this issue to some >> core Infinispan developer more familiar with the intentions here. >> >> Sanne >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > galder(a)redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

It turns out this resource loading issue is biting also community users; I had worked aroud the problem for deploymens in the AS7 modular classloader by wrapping the configuration parser with the "right" classloader: https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc... But today on IRC I had to point to this class as an example to another user looking to run Infinispan in an isolated classloader. Maybe we should have an (optional) Parser API which takes explicit classloaders ?

On 22 April 2013 12:07, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: > > On 19 Apr 2013, at 18:02, Sanne Grinovero wrote: > >> It turns out this resource loading issue is biting also community users; >> >> I had worked aroud the problem for deploymens in the AS7 modular >> classloader by wrapping the configuration parser with the "right" >> classloader: >> https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc... >> >> But today on IRC I had to point to this class as an example to another >> user looking to run Infinispan in an isolated classloader. >> >> Maybe we should have an (optional) Parser API which takes explicit >> classloaders ? > +1 > When reading the metadata only, wouldn't it make sense to try and use both context and (fallback) class's class loaders? Would that solve the issue you reported? Yes that would solve the issue. The Infinispan classloader could be used first, as it's likely the correct one for most components?

It would likely be nicer for many users than to have to use CLs in the API - or having to figure out why Infinispan is throwing an NPE in its own initialization - still I guess some users might want to control the CLs being used for these purposes.

Implement both?