On 4/28/11 4:52 PM, Manik Surtani wrote:
On 27 Apr 2011, at 12:39, Jason T. Greene wrote:
> Available here:
>
https://github.com/infinispan/infinispan/pull/278
>
> The problem is basically that infinispan currently is using TCCL for all
> class loading and resource loading. This has a lot of problems in
> modular containers (OSGi, AS7, etc), where you dont have framework
> implementation classes on the same classloader as user classes (that is
> how they achieve true isolation)
>
> You can read about this in more detail here:
>
http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
>
> The patch in the pull request is a first step, and should fix many
> issues, but it does not address all (there is still a lot of TCCL usage
> spread out among cacheloaders and so on), and ultimately it's just a
> work around. It should, however, be compatible in any other non-modular
> environment.
>
> Really the ultimate solution is to setup a proper demarcation between
> what the user is supposed to provide, and what is expected to be bundled
> with infinispan. Whenever there is something the user can provide a
> class, then the API should accept a classloader to load that class from.
As in, user API? That's a little intrusive... e.g., put(K, V, cl) ?
Not for put, since you have the class, just get, and I was thinking
something more like:
Foo foo = getUsing(key, Foo.class)
This could verify type compatibility and use the classloader of the
type. But that does of course mean more methods on AdvancedCache (not so
great).
Alternatively you could just have a method on the invocation context.
For friendlier interaction and elimination of thread locals, you could
introduce a session based API.
CacheSession session = CacheSession.from(cache);
session.setClassLoader(blah);
session.setOtherInterestingOptionsLikeBatchingEtc
session.get/put etc
--
Jason T. Greene
JBoss, a division of Red Hat