Ion, Martin - what are your thoughts? On Jul 29, 2014, at 16:34, Sanne Grinovero <sa...@infinispan.org> wrote:
> All, > in Search we wrap the Parser in a decorator which workarounds the > classloader limitation. > I still think you should fix this, it doesn't matter how/why it was changed. > > Sanne > > On 26 May 2014 11:06, Ion Savin <isa...@redhat.com> wrote: >> Hi Sanne, Galder, >> >> On 05/23/2014 07:08 PM, Sanne Grinovero wrote: >>> On 23 May 2014 08:03, Galder Zamarreño<gal...@redhat.com> wrote: >>>>> Hey Sanne, >>>>> >>>>> I’ve looked at ParserRegistry and not sure I see the changes you are >>>>> referring to… >>>>> >>>>>> From what I’ve seen, ParserRegistry has taken class loader in the >>>>>> constructor since the start. >>> Yes, and that was good as we've been using it: it might need >>> directions to be pointed at the right modules to load extension >>> points. >>> >>> My problem is not that the constructor takes a ClassLoader, but that >>> other options have been removed; essentially in my scenario the module >>> containing the extension points does not contain the configuration >>> file I want it to load, and the actual classLoader I want the >>> CacheManager to use is yet a different one. As explained below, >>> assembling a single "catch all" ClassLoader to delegate to all doesn't >>> work as some of these actually need to be strictly isolated to prevent >>> ambiguities. >>> >>>>> I suspect you might be referring to classloader related changes as a >>>>> result of OSGI integration? >>> I didn't check but that sounds like a reasonable estimate. >> >> I had a look at the OSGi-related changes done for this class and they >> don't alter the class interface in any way. The implementation changes >> related to FileLookup seem to maintain the same behavior for non-OSGi >> contexts also. >> >> Regards, >> Ion Savin >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev