----- Original Message ----- > From: "Scott Marlow" <smar...@redhat.com> > To: "infinispan -Dev List" <infinispan-...@lists.jboss.org> > Cc: hibernate-dev@lists.jboss.org, "jboss-as7-...@lists.jboss.org > Development" <jboss-as7-...@lists.jboss.org>, > "Galder Zamarreño" <gal...@redhat.com> > Sent: Tuesday, March 6, 2012 2:45:03 PM > Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan > dependency for clustered JPA second level > cache > > On 03/06/2012 02:27 PM, Galder Zamarreño wrote: > > 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 > > Do we want to try this (requires a new build of Infinispan I think)? > Or > should applications workaround the issue until we can reach the > medium/long term? > > > > > - 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 > > ISPN-1367 is targeted to Infinispan 5.2, any idea of the target > release > date for that? I'm curious as to which AS release it might align > with. > > > > > - 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). > > https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jboss/as/web/deployment/JBossContextConfig.java > appears to be wired to use Paul's ClassLoaderAwareClassResolver.
ClassLoaderAwareClassResolver is just a hack to workaround AS7-2496 (i.e. Weld still does TCCL switching). The bottom line is, we still rely on ModularClassResolver to marshal/unmarshal session objects. > > > > 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/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 > >>>> > >>>> 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-...@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-...@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-...@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
