On May 19, 2011, at 11:45 AM, Galder Zamarreño wrote:
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
> 2) Class loader per invocation.
>
> I've been less than happy with this, not just because it pollutes the API but
that it adds a layer of confusion. If all use cases discussed can be solved with (1)
above, then I'd prefer to just do that.
>
> The way I see it, most user apps directly using Infinispan would only be exposed to a
single class loader per cache reference (even if multiple references talk to the same
cache).
>
> Frameworks, OTOH, are a bit tougher, Hibernate being a good example on this thread.
So this is a question for Galder - is it feasible to maintain several references to a
cache, one for each app/persistence unit?
Sorry, missed the second part of the email, forget it my questions are irrelevant after
this.
I think this might be doable. Each entity/collection region has a cache associated which
is built of the region factory. As long as when the region's classloader can be
identified at that point and passed to the cache manager on cache retrieval, we should be
Ok.
Actually Manik, for this to really work, a Cache would need to be identified not only by
its name but by its classloader too, so:
cacheManager.getCache("entities", CL1)
and
cacheManager.getCache("entities", CL2)
would be different cache instances. The problem then is that if an RPC comes for
"entities" cache and entity P1, which of the "entities" caches do I go
for? You'd need to know which classloader P1 is living in the remote node and
you'd have to now that at the Infinispan level to be able to store it in a non-binary
format.
Otherwise, storeAsBinary would be the alternative for these cases.
>
> 3) Can all OSGi requirements be handled by (1)? I would guess so, from what I have
read here, since the class loader is explicitly passed in when getting a handle on a
cache.
>
> Cheers
> Manik
>
>
> On 27 Apr 2011, at 17: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.
>> If it's a class that is just internal wiring of infinispan, then
>> Infinispan's defining classloader should always be used.
>>
>> The one case I can think of in infnispan where TCCL really makes sense
>> is in the case of lazy deserialization from an EE application. However
>> that is only guaranteed to work when you are executing in a context that
>> has that style of contract (like in an EE component). There are many
>> other cases though where someone would expect it to work from a non-EE
>> context (e.g. from a thread pool). What you really want is the caller's
>> classloader, but that is not cheap to get at, so it's something that
>> should be supplied as part of the API interaction (in the case where
>> there is no EE context). Alternatively you can just just require that
>> folks push/pop TCCL, but users often get this wrong.
>>
>> Thanks!
>>
>> --
>> Jason T. Greene
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Lead, Infinispan
>
http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache