Ion, Martin - what are your thoughts?
On Jul 29, 2014, at 16:34, Sanne Grinovero <sanne(a)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(a)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(a)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(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