Btw, this discussion should be extended to Infinispan dev list in case we can improve on the custom commands SPI. In the case of Hibernate 2LC, the custom command is really a cache specific one, so we could potentially tie up cache specific custom commands to the cache lifecycle, but still don't see how it can really help with the issue below. Begin forwarded message: > From: Galder Zamarreño <galder(a)redhat.com&gt; > Subject: Re: looking again at AS7-3290 and Hibernate 4.0.1... > Date: February 6, 2012 10:49:03 AM GMT+01:00 > To: Scott Marlow <smarlow(a)redhat.com&gt; > Cc: Tristan Tarrant <ttarrant(a)redhat.com&gt;, Steve Ebersole <steve(a)hibernate.org&gt;, Paul Ferraro <pferraro(a)redhat.com&gt; > > > On Feb 3, 2012, at 6:43 PM, Scott Marlow wrote: > >> On 02/03/2012 10:33 AM, Scott Marlow wrote: >>> I was just reviewing the change we made to address >>> https://issues.jboss.org/browse/AS7-3290 (Infinispan needed to see the >>> Hibernate-Infinispan modules services, when AS7 constructs the >>> Infinispan global component registry). >>> >>> This turns into a dependency from the AS7 >>> org.jboss.as.clustering.infinispan module onto our >>> org.hibernate.infinispan module (contains the Hibernate-Infinispan 4.0.1 >>> jar). >>> >>> Community users are asking to use the Infinispan 2lc with Hibernate >>> 3.6.x also which we don't ship. I would imagine that the same request >>> will come in for OGM in the future. > > If they wanna use Infinispan 2LC with Hibernate 3.6.x, they won't be able to use Infinispan 5.1.x. So far, 3.6.x has only been tested with 4.2.x. > > Are you sure this is gonna be supported?? > >>> >>> Is there another way to avoid this dependency between the constructor of >>> the Infinispan global component registry and all of the persistence >>> provider modules that want to use the 2lc? >> >> Is this the commit that brought this requirement in? https://github.com/hibernate/hibernate-orm/commit/cc9fbf42a9a75a231767590... >> >> Could this be made optional or reverted in a 4.0.2.Final build? > > Hmmmm, that would require going back to using a cache as a way to send evict all invalidation messages around the cluster which is a hack. Custom commands are the best way to handle this use case IMO. > > At the moment, these commands at their factories are loaded on startup, when the GCR is created. > > I wonder if it would help if Infinispan would load them lazily? RemoteCommandFactory could potentially look up the command factory when it receives a request for a custom command, but you still have the same issue of needing to find Hibernate 2LC classes from Infinispan jar. > > Btw, I don't see how different this problem is to when a user defines a custom cache loader (or any other SPIs we have) and wants to plug that into Infinispan. The CL where Infinispan is, is gonna need to know about these custom classes. Same thing happens for Hibernate 2LC which is implementing an SPI. > >> >>> >>> Scott >> > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > -- 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

(I'd have preferred the cc'd guys had continued with the conversation in the dev list...) So, Hibernate 3.6.x support is a potential requirement coming down the line the in AS7. Users are asking for it ... So Scott is voicing his concerns with Hibernate 2LC which now builds custom commands to deal with evict all situations. The previous solution used existing caches as a notification bus which was a PITA to maintain. Module custom commands and their factories are kept at the cache manager level and they're loaded with the cache manager CL, so that means that the AS7 Infinispan subsystem is hooked to Hibernate 4.0.x now because on startup, Infinispan loads commands and their factories, so any custom commands need to be available on at that point. This makes it hard for AS7 to support other Hibernate versions. According to Paul, they might be able to workardound this for AS 7.1.1 by allow attaching specific classloaders to a cache manager, but they don't do it in AS7 7.1.0, hence why Hibernate and AS7 subsystem need to be within same classloader. Although Paul's suggestion should work, I still think there's room for improvement in our custom commands (kinda related to https://issues.jboss.org/browse/ISPN-1835). There's a difference between cache-level commands (i.e. http://goo.gl/OkvU4) and global commands which are not associated with a particular cache (i.e. http://goo.gl/isR00). So, the lifecycle and the classloader used for each should be different. Thoughts? Cheers, On Feb 6, 2012, at 7:05 PM, Manik Surtani wrote: > What's the actual issue at hand? Wanting to use Infinispan with Hibernate 3.6 in AS 7? > > On 6 Feb 2012, at 09:53, Galder Zamarreño wrote: > >> Btw, this discussion should be extended to Infinispan dev list in case we can improve on the custom commands SPI. >> >> In the case of Hibernate 2LC, the custom command is really a cache specific one, so we could potentially tie up cache specific custom commands to the cache lifecycle, but still don't see how it can really help with the issue below. >> >> Begin forwarded message: >> >>> From: Galder Zamarreño <galder(a)redhat.com&gt; >>> Subject: Re: looking again at AS7-3290 and Hibernate 4.0.1... >>> Date: February 6, 2012 10:49:03 AM GMT+01:00 >>> To: Scott Marlow <smarlow(a)redhat.com&gt; >>> Cc: Tristan Tarrant <ttarrant(a)redhat.com&gt;, Steve Ebersole <steve(a)hibernate.org&gt;, Paul Ferraro <pferraro(a)redhat.com&gt; >>> >>> >>> On Feb 3, 2012, at 6:43 PM, Scott Marlow wrote: >>> >>>> On 02/03/2012 10:33 AM, Scott Marlow wrote: >>>>> I was just reviewing the change we made to address >>>>> https://issues.jboss.org/browse/AS7-3290 (Infinispan needed to see the >>>>> Hibernate-Infinispan modules services, when AS7 constructs the >>>>> Infinispan global component registry). >>>>> >>>>> This turns into a dependency from the AS7 >>>>> org.jboss.as.clustering.infinispan module onto our >>>>> org.hibernate.infinispan module (contains the Hibernate-Infinispan 4.0.1 >>>>> jar). >>>>> >>>>> Community users are asking to use the Infinispan 2lc with Hibernate >>>>> 3.6.x also which we don't ship. I would imagine that the same request >>>>> will come in for OGM in the future. >>> >>> If they wanna use Infinispan 2LC with Hibernate 3.6.x, they won't be able to use Infinispan 5.1.x. So far, 3.6.x has only been tested with 4.2.x. >>> >>> Are you sure this is gonna be supported?? >>> >>>>> >>>>> Is there another way to avoid this dependency between the constructor of >>>>> the Infinispan global component registry and all of the persistence >>>>> provider modules that want to use the 2lc? >>>> >>>> Is this the commit that brought this requirement in? https://github.com/hibernate/hibernate-orm/commit/cc9fbf42a9a75a231767590... >>>> >>>> Could this be made optional or reverted in a 4.0.2.Final build? >>> >>> Hmmmm, that would require going back to using a cache as a way to send evict all invalidation messages around the cluster which is a hack. Custom commands are the best way to handle this use case IMO. >>> >>> At the moment, these commands at their factories are loaded on startup, when the GCR is created. >>> >>> I wonder if it would help if Infinispan would load them lazily? RemoteCommandFactory could potentially look up the command factory when it receives a request for a custom command, but you still have the same issue of needing to find Hibernate 2LC classes from Infinispan jar. >>> >>> Btw, I don't see how different this problem is to when a user defines a custom cache loader (or any other SPIs we have) and wants to plug that into Infinispan. The CL where Infinispan is, is gonna need to know about these custom classes. Same thing happens for Hibernate 2LC which is implementing an SPI. >>> >>>> >>>>> >>>>> Scott >>>> >>> >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >> >> -- >> 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 > > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > _______________________________________________ > 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

(I'd have preferred the cc'd guys had continued with the conversation in the dev list...)

So, Hibernate 3.6.x support is a potential requirement coming down the line the in AS7. Users are asking for it ... So Scott is voicing his concerns with Hibernate 2LC which now builds custom commands to deal with evict all situations. The previous solution used existing caches as a notification bus which was a PITA to maintain. Module custom commands and their factories are kept at the cache manager level and they're loaded with the cache manager CL, so that means that the AS7 Infinispan subsystem is hooked to Hibernate 4.0.x now because on startup, Infinispan loads commands and their factories, so any custom commands need to be available on at that point. This makes it hard for AS7 to support other Hibernate versions. According to Paul, they might be able to workardound this for AS 7.1.1 by allow attaching specific classloaders to a cache manager, but they don't do it in AS7 7.1.0, hence why Hibernate and AS7 subsystem need to be within same classloader. Although Paul's suggestion should work, I still think there's room for improvement in our custom commands (kinda related to https://issues.jboss.org/browse/ISPN-1835). There's a difference between cache-level commands (i.e. http://goo.gl/OkvU4) and global commands which are not associated with a particular cache (i.e. http://goo.gl/isR00). So, the lifecycle and the classloader used for each should be different. Thoughts?

Cheers, On Feb 6, 2012, at 7:05 PM, Manik Surtani wrote: > What's the actual issue at hand? Wanting to use Infinispan with Hibernate 3.6 in AS 7? > > On 6 Feb 2012, at 09:53, Galder Zamarreño wrote: > >> Btw, this discussion should be extended to Infinispan dev list in case we can improve on the custom commands SPI. >> >> In the case of Hibernate 2LC, the custom command is really a cache specific one, so we could potentially tie up cache specific custom commands to the cache lifecycle, but still don't see how it can really help with the issue below. >> >> Begin forwarded message: >> >>> From: Galder Zamarreño&lt;galder(a)redhat.com&gt; >>> Subject: Re: looking again at AS7-3290 and Hibernate 4.0.1... >>> Date: February 6, 2012 10:49:03 AM GMT+01:00 >>> To: Scott Marlow&lt;smarlow(a)redhat.com&gt; >>> Cc: Tristan Tarrant&lt;ttarrant(a)redhat.com&gt;, Steve Ebersole&lt;steve(a)hibernate.org&gt;, Paul Ferraro&lt;pferraro(a)redhat.com&gt; >>> >>> >>> On Feb 3, 2012, at 6:43 PM, Scott Marlow wrote: >>> >>>> On 02/03/2012 10:33 AM, Scott Marlow wrote: >>>>> I was just reviewing the change we made to address >>>>> https://issues.jboss.org/browse/AS7-3290 (Infinispan needed to see the >>>>> Hibernate-Infinispan modules services, when AS7 constructs the >>>>> Infinispan global component registry). >>>>> >>>>> This turns into a dependency from the AS7 >>>>> org.jboss.as.clustering.infinispan module onto our >>>>> org.hibernate.infinispan module (contains the Hibernate-Infinispan 4.0.1 >>>>> jar). >>>>> >>>>> Community users are asking to use the Infinispan 2lc with Hibernate >>>>> 3.6.x also which we don't ship. I would imagine that the same request >>>>> will come in for OGM in the future. >>> >>> If they wanna use Infinispan 2LC with Hibernate 3.6.x, they won't be able to use Infinispan 5.1.x. So far, 3.6.x has only been tested with 4.2.x. >>> >>> Are you sure this is gonna be supported?? >>> >>>>> >>>>> Is there another way to avoid this dependency between the constructor of >>>>> the Infinispan global component registry and all of the persistence >>>>> provider modules that want to use the 2lc? >>>> >>>> Is this the commit that brought this requirement in? https://github.com/hibernate/hibernate-orm/commit/cc9fbf42a9a75a231767590... >>>> >>>> Could this be made optional or reverted in a 4.0.2.Final build? >>> >>> Hmmmm, that would require going back to using a cache as a way to send evict all invalidation messages around the cluster which is a hack. Custom commands are the best way to handle this use case IMO. >>> >>> At the moment, these commands at their factories are loaded on startup, when the GCR is created. >>> >>> I wonder if it would help if Infinispan would load them lazily? RemoteCommandFactory could potentially look up the command factory when it receives a request for a custom command, but you still have the same issue of needing to find Hibernate 2LC classes from Infinispan jar. >>> >>> Btw, I don't see how different this problem is to when a user defines a custom cache loader (or any other SPIs we have) and wants to plug that into Infinispan. The CL where Infinispan is, is gonna need to know about these custom classes. Same thing happens for Hibernate 2LC which is implementing an SPI. >>> >>>> >>>>> >>>>> Scott >>>> >>> >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >> >> -- >> 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 > > -- > Manik Surtani > manik(a)jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > _______________________________________________ > 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

> > I'm not that worried about OGM (unless someone wants double buffering > > ;), its more about users wanting to package in different versions in > > Hibernate (newer/older). Even if someone wanted double buffering, OGM was already upgraded to use Hibernate 4, so this doesn't apply.

On 7 February 2012 15:21, Scott Marlow&lt;smarlow(a)redhat.com&gt; wrote: > On 02/07/2012 10:07 AM, Sanne Grinovero wrote: >>>> I'm not that worried about OGM (unless someone wants double buffering >>>> ;), its more about users wanting to package in different versions in >>>> Hibernate (newer/older). >> Even if someone wanted double buffering, OGM was already upgraded to >> use Hibernate 4, so this doesn't apply. >> >> > > I think it depends on whether OGM will always work with the Hibernate > 4.x version that is used in AS 7.x. If OGM moves forward (Hibernate > version wise) and starts requiring a different version than the one that > is static wired into the Infinispan module, the user might want multiple > Hibernate 4.x versions to be wired into the Infinispan module. I'm not > sure but if Infinispan has multiple versions of Hibernate in its > classpath, that probably would interfere with the custom commands (I > would think). Good point. It's unlikely for OGM to need a 2nd level cache, but this reasoning applies to Hibernate Search as well, for which we often depend on a newer version of Core than what is provided by the AS.

--Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 8 February 2012 04:14, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > On 02/07/2012 10:25 AM, Sanne Grinovero wrote: >> >> On 7 February 2012 15:21, Scott Marlow&lt;smarlow(a)redhat.com&gt; wrote: >>> >>> On 02/07/2012 10:07 AM, Sanne Grinovero wrote: >>>>>> >>>>>> I'm not that worried about OGM (unless someone wants double buffering >>>>>> ;), its more about users wanting to package in different versions in >>>>>> Hibernate (newer/older). >>>> >>>> Even if someone wanted double buffering, OGM was already upgraded to >>>> use Hibernate 4, so this doesn't apply. >>>> >>>> >>> >>> I think it depends on whether OGM will always work with the Hibernate >>> 4.x version that is used in AS 7.x. If OGM moves forward (Hibernate >>> version wise) and starts requiring a different version than the one that >>> is static wired into the Infinispan module, the user might want multiple >>> Hibernate 4.x versions to be wired into the Infinispan module. I'm not >>> sure but if Infinispan has multiple versions of Hibernate in its >>> classpath, that probably would interfere with the custom commands (I >>> would think). >> >> >> Good point. It's unlikely for OGM to need a 2nd level cache, but this >> reasoning applies to Hibernate Search as well, for which we often >> depend on a newer version of Core than what is provided by the AS. > > > How hard would it be to allow a different way of passing the custom commands > in? Would this be a short term change in the next few weeks or longer term? Sorry I'm not sure I understood what you are proposing. How do you suggest it should work? --Sanne

On Feb 8, 2012, at 11:27 AM, Sanne Grinovero wrote: > On 8 February 2012 04:14, Scott Marlow&lt;smarlow(a)redhat.com&gt; wrote: >> On 02/07/2012 10:25 AM, Sanne Grinovero wrote: >>> >>> On 7 February 2012 15:21, Scott Marlow&lt;smarlow(a)redhat.com&gt; wrote: >>>> >>>> On 02/07/2012 10:07 AM, Sanne Grinovero wrote: >>>>>>> >>>>>>> I'm not that worried about OGM (unless someone wants double buffering >>>>>>> ;), its more about users wanting to package in different versions in >>>>>>> Hibernate (newer/older). >>>>> >>>>> Even if someone wanted double buffering, OGM was already upgraded to >>>>> use Hibernate 4, so this doesn't apply. >>>>> >>>>> >>>> >>>> I think it depends on whether OGM will always work with the Hibernate >>>> 4.x version that is used in AS 7.x. If OGM moves forward (Hibernate >>>> version wise) and starts requiring a different version than the one that >>>> is static wired into the Infinispan module, the user might want multiple >>>> Hibernate 4.x versions to be wired into the Infinispan module. I'm not >>>> sure but if Infinispan has multiple versions of Hibernate in its >>>> classpath, that probably would interfere with the custom commands (I >>>> would think). >>> >>> >>> Good point. It's unlikely for OGM to need a 2nd level cache, but this >>> reasoning applies to Hibernate Search as well, for which we often >>> depend on a newer version of Core than what is provided by the AS. >> >> >> How hard would it be to allow a different way of passing the custom commands >> in? Would this be a short term change in the next few weeks or longer term? > > Sorry I'm not sure I understood what you are proposing. How do you > suggest it should work? Hmmm, I don't see an easy/quick way to fix this. So far, these are the options that could be implemented in Infinispan: 1. Separate between cache-level and global module command extensions. By doing that, Hibernate 2LC can implement a cache command factory and that would get resolved (via service loader) when the cache is created, which happens when application is deployed. This avoids AS7 Infinispan subsystem being tied to Hibernate. 2. Alternatively something suggested by Sanne is plugging the command factories (and initializer) via an SPI (i.e. addModuleCommandExtensions or similar), so that loading happens in Hibernate and it passes it into the created cache (similar to listeners). A problem with this is unless this is passed when the cache is started, there could be a small window when the cache receives a command for which no factory to resolve it is available cos addModuleCommandExtensions has not been called yet. I also see an option for those in charge of managed environments: 3. A third solution here is for AS7, or any other managed env, to associate a cache manager with each deployment and associate pass the right classloader in. That way, the cache manager is created when deployment comes in and we can pass in the right Hibernate and Infinispan CLs. As said by Paul, this would require work on the AS7, but conceptually, this is in line with what we want to do with https://issues.jboss.org/browse/ISPN-1413 long term… I personally favour this 3rd option

> --Sanne > > _______________________________________________ > 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