From: "Galder Zamarreño" <galder(a)redhat.com&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; Cc: hibernate-dev(a)lists.jboss.org, &quot;jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org&gt; 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 cache So, to summarise all of this. What I suggest is this: - Short term: The "quick fix" I suggest in http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html - 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. (***) https://issues.jboss.org/browse/ISPN-1367 - Long term: https://issues.jboss.org/browse/ISPN-1413 (***) 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev