From: "Galder Zamarreño" <galder(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development"
Sent: Tuesday, March 6, 2012 2:27:13 PM
Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for
clustered JPA second level
So, to summarise all of this. What I suggest is this:
- Short term:
The "quick fix" I suggest in
- Medium term:
Have a way to pass in marshalling configurations per cache manager
and per-cache (or an abstraction of it), which allows the right
class resolver to be passed in. (***)
- Long term:
(***) I still don't fully understand how web apps don't have the same
issue as 2LC of not seeing Infinispan classes (Reminder: we're not
talking about the contents of the cache, but about the Infinispan
To reiterate: in the case of web sessions, the cache instance for an application is
associated with the classloader of the org.jboss.as.clustering.web.infinispan module. The
AS clustering code shields Infinispan from direct interaction with application objects by
storing sessions as MarshalledValues which are eagerly marshalled into byte and lazily
unmarshalled using an application-specific MarshallingConfiguration.
This has been the case since AS5, if not earlier (albeit using JBoss Serialization + JBoss
Cache + TCCL manipulation).
On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
> On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
>> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
>>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
>>>> To work around this, we typically store MarshalledValues in the
>>>> cache - which are marshalled/unmarshalled using a marshalling
>>>> configuration specific to the application (e.g. via a
>>>> ModularClassResolver using the ModuleLoader of the deployment
>>> Isn't a class resolver and a class loader, functionality wise,
>>> doing the same thing? I wonder if a custom classloader could not
>>> be built that delegates to a ModularClassResolver...
>> No, not really. A class loader loads a class, given a name. But
>> class resolver loads a class given a name *and* stream
>> information. The
>> modular class resolver reads the stream information to know which
>> loader houses the class in question. This is critically important
>> because it's possible (common even) for more than one class to
>> exist in
>> an AS instance with the same name. And there is no single class
>> which has visibility to all classes which could potentially be
>> stored in
>> a cache.
>> Yes, accepting a class loader to use is a powerful feature.
>> However it
>> *should* just be a convenience abstraction over a more fundamental
>> feature which allows a class resolver to be set.
> Thanks for the clarification, makes sense.
> So, if I understand this correctly, Infinispan should really be
> enhanced to accept global and per-cache class resolvers, or more
> globally, as paul suggested below, marshalling configuration
> instances (or abstractions of them).
> I think https://issues.jboss.org/browse/ISPN-1367
> reporpoused to do this.
>>>> So, essentially Infinispan itself only ever has to
>>>> marshal/unmarshal a byte wrapper - so the AS has full control
>>>> over the marshalling process.
>>>> I would recommend that the 2LC do something similar, and include
>>>> a mechanism for providing a MarshallingConfiguration per
>>>> persistence unit.
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>> - DML
>> infinispan-dev mailing list
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> infinispan-dev mailing list
Sr. Software Engineer
Infinispan, JBoss Cache
infinispan-dev mailing list