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). > > On Mar 5, 2012, at 11:07 PM, Scott Marlow wrote: > >> Galder, >> >> I'm trying to identify the right fix for addressing AS7-4007. I started a >> clustered second level cache test that currently fails since Infinispan >> isn't on the test application classpath. >> >> The exception call stack that I'm getting is shown here >> http://pastie.org/3503803. >> >> I would like to discuss how we can address AS7-4007 (either on email or IRC). >> >> Initially, I worked around this by ensuring that the infinispan module is >> available in the test application classpath >> (https://github.com/jbossas/jboss-as/commit/31f3547960775dac88275447253fdae942f952b9#L0R40). >> The hack was to export the Infinispan module when the Hibernate module is >> brought into an application. This covered both JPA and Hibernate native >> applications, however it exports into every other module that references the >> Hibernate module (increasing the time that it takes to link the Hibernate >> module into other modules). There are other problems with requiring >> Infinipan to be in the application classpath (see >> https://community.jboss.org/wiki/ModularSerialization). >> >> I would like to better understand the alternatives (both short term and long >> term) to address AS7-4007 and issues like it. Perhaps by using >> MarshallingConfiguration.setClassResolver() to pass a ModuleClassResolver to >> be used with Infinispan marshalling/unmarshalling. Is that currently >> configurable with Infinispan? >> >> Paul Ferraro, David Lloyd and myself chatted on irc briefly about this a few >> days ago (see http://pastie.org/3528553). >> >> https://github.com/dmlloyd/jboss-marshalling/blob/master/api/src/main/java/org/jboss/marshalling/ModularClassResolver.java >> contains the source for the ModularClassResolver class that David referred >> to (as well as the ModularSerialization article linked above). >> >> Scott > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > -- - DML _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
