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. (***)
(***) 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 classes themselves).
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:
>> </snip>
>>> 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 unit).
>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>
https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>
>> 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 a
> class resolver loads a class given a name *and* stream information. The
> modular class resolver reads the stream information to know which class
> 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 loader
> 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 should be 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.
>>
>> Possibly…
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>
>
> --
> - DML
> _______________________________________________
> 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