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.
Sanne
Cheers,
On 19 May 2014, at 17:09, Sanne Grinovero <sanne(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev