----- Original Message ----- > From: "Jason T. Greene" <jason.gre...@redhat.com> > To: "David M. Lloyd" <david.ll...@redhat.com> > Cc: "Galder Zamarreño" <gal...@redhat.com>, "Paul Ferraro" > <pferr...@redhat.com>, "Bela Ban" <b...@redhat.com>, > "infinispan -Dev List" <infinispan-...@lists.jboss.org>, > hibernate-dev@lists.jboss.org, > "jboss-as7-...@lists.jboss.org Development" <jboss-as7-...@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/java/org/jboss/as/clustering/MarshalledValue.java https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java 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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
