[infinispan-dev] [Pull Request] Modular Classloading Compatibility

[Galder Zamarreño]

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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>> 
>> Lead, Infinispan
>> http://www.infinispan.org
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache