On 22 Apr 2013, at 13:16, Sanne Grinovero wrote: > On 22 April 2013 12:07, Mircea Markus <[email protected]> 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-search-infinispan/src/main/java/org/hibernate/search/infinispan/impl/InfinispanConfigurationParser.java >>> >>> 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? +1 > > 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. https://issues.jboss.org/browse/ISPN-3032 > Implement both? That would be an overloaded ConfigurationParser.parse( InputStream, *ClassLoader* )? If so please update the JIRA with the requirement.
Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
