[infinispan-dev] On ParserRegistry and classloaders

Mircea Markus mmarkus at redhat.com
Wed Jul 30 14:17:41 EDT 2014


Ion, Martin - what are your thoughts?

On Jul 29, 2014, at 16:34, Sanne Grinovero <sanne at 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 <isavin at 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<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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list