So it seems I can workaround most of the below issues by temporarily
setting the ContectClassLoader,
but then there is an additional problem: since I can't pass the
JGroups configuration as an InputStream but this is hardcoded by
resource name in the Infinispan configuration, Infinispan is unable
Hi all,
sorry it took me quite some time to return on this, but it's still
troublesome and quite critical to allow using Infinispan as a module.
I'm again trying to use Infinispan's JBoss Modules as a (library) for
deployed application, and it fails because of:
Caused by:
Ion, Martin - what are your thoughts?
On Jul 29, 2014, at 16:34, Sanne Grinovero sa...@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
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?
On 23 May 2014 08:03, Galder Zamarreño gal...@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
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
