On Wed, 2012-02-08 at 14:14 +0100, Galder Zamarreño wrote: > On Feb 8, 2012, at 11:27 AM, Sanne Grinovero wrote: > > > On 8 February 2012 04:14, Scott Marlow <[email protected]> wrote: > >> On 02/07/2012 10:25 AM, Sanne Grinovero wrote: > >>> > >>> On 7 February 2012 15:21, Scott Marlow<[email protected]> 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…
Require a separate channel for every deployment? I don't think that's the way to go exactly. Rather, I think a better solution is to associate a cache manager with a module - where the module can supply the global configuration with its class loader. Individual caches would be associated with a deployment created by this module. I've opened AS7-3655 to make this possible. Paul > I personally favour this 3rd option > > > --Sanne > > > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
