[infinispan-dev] On ParserRegistry and classloaders

[Sanne Grinovero]

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.

Sanne

>
> Cheers,
>
> On 19 May 2014, at 17:09, Sanne Grinovero <sanne at infinispan.org> wrote:
>
>> I see the ParserRegistry was changed quite a bit; in Infinispan 6 it
>> allowed to specify a different classloader for some operations, now it
>> only takes a classloader during construction time.
>>
>> For WildFly/JBoss users, it is quite common that the configuration
>> file we want parsed is not in the same classloader that the
>> ParserRegistry needs to lookup its own parser components (as its
>> design uses the ServiceLoader to discover components of the parser).
>> This is especially true when Infinispan is not used by the application
>> directly but via another module (so I guess also critical for
>> capedwarf).
>>
>> I initially though to workaround the problem using a "wrapping
>> classloader" so that I could pass a single CL instance which would try
>> both the deployment classloader and the Infinispan's module
>> classloader, but - besides this being suboptimal - it doesn't work as
>> I'm violating isolation between modules: I can get exposed to an
>> Infinispan 6 module which contains also Parser components, which get
>> loaded as a service but are not compatible (different class
>> definition).
>>
>> I'll need these changes in the ParserRegistry reverted please. Happy
>> to send a pull myself, but before I attempt to patch it myself could
>> someone explain what the goal was?
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev