[infinispan-dev] On ParserRegistry and classloaders

[Ion Savin]

Hi Sanne, Galder,

On 05/23/2014 07:08 PM, Sanne Grinovero wrote:
> On 23 May 2014 08:03, Galder Zamarreño<galder at 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