[infinispan-dev] On ParserRegistry and classloaders

[Galder Zamarreño]

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.

I suspect you might be referring to classloader related changes as a result of OSGI integration?

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