On Mar 6, 2012, at 6:44 PM, Jason T. Greene wrote:
On 3/6/12 11:31 AM, Paul Ferraro wrote:
> ----- Original Message -----
>> From: "Jason T. Greene"<jason.greene(a)redhat.com>
>> To: "David M. Lloyd"<david.lloyd(a)redhat.com>
>> Cc: "Galder Zamarreño"<galder(a)redhat.com>, "Paul
Ferraro"<pferraro(a)redhat.com>, "Bela Ban"<bban(a)redhat.com>,
>> "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>,
hibernate-dev(a)lists.jboss.org,
>> "jboss-as7-dev(a)lists.jboss.org
Development"<jboss-as7-dev(a)lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 10:30:11 AM
>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered
JPA second level cache
>>
>> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>>> This reminds me that we had a discussion about this a few months
>>>> back:
http://goo.gl/DJLhB
>>>>
>>>> At the time, it wasn't clear whether you can use
>>>> ModularClassResolver in a non-module env. Seems like it's not
>>>> possible.
>>>>
>>>> So, one option is to have a class resolver lookup class, or
>>>> similar so that AS7 can pass us the right ClassResolver.
>>>>
>>>> There might a quicker option here though:
>>>> - Extend VersionAwareMarshaller (
http://goo.gl/bu8CF) and provide
>>>> a variant of JBossMarshaller (
http://goo.gl/o9Ro3) in Infinispan
>>>> (this requires JBossMarshaller to be made non-final)
>>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>>> call baseCfg.setClassResolver(…)
>>>> - This would require that the VersionAwareMarshaller extension be
>>>> passed the ModuleLoader that ModularClassResolver requires.
>>>> - Configure Infinispan with this new marshaller, via
>>>> SerializationConfiguration. Thankfully you can now pass an
>>>> instance of the marshaller to it, so no need to do any magic
>>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>>
>>>> Scott, other than the change in JBossMarshaller to be made
>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>>> IRC if you need help.
>>>>
>>>> Cheers,
>>>>
>>>> p.s. Silly question, how come this issue is not present in HTTP
>>>> session replication use case or EJB3 SFSB?
>>>
>>> It actually is present anywhere we're using Infinispan (I think).
>>> It
>>> just hasn't blown up yet anywhere public (in this case it's a 90%
>>> effective solution versus a 100% effective solution).
>>
>> Session replication does setup a custom marshaller, so it does in
>> fact
>> work. I think the issue is just that the hibernate-infinispan, which
>> is
>> part of the hibernate project set, and not AS code does not do this,
>> and
>> it doesn't expose a way to do it.
>
> Sort of...
>
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller instance for all
caches within a cache manager - which doesn't map cleanly to our use case, which uses
a cache instance per application - thus requires cache-grained marshalling configuration.
>
> 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...
>
> 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.
Well the lazy deserialization thing was really to solve the legacy
problem of receiving deployment data without knowing the classloader for
the deployment. In 7 we know this know, although we still have the
problem that the value is only usable if the deployment is up and running.
Thinking through this, I don't think this is the problem here. And 2LC is configured
with lazy deserialization already.
The problem here is that the deployment cannot see the Infinispan classes, not that
Infinispan cannot deserialize the deployment classes.
Although, I don't see how we need per application marshalling
configuration.
The ModularClassResolver will work globally as deployment
module identity is globally unique.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
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