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