[infinispan-dev] looking again at AS7-3290 and Hibernate 4.0.1...

[Galder Zamarreño]

On Feb 8, 2012, at 11:27 AM, Sanne Grinovero wrote:

> On 8 February 2012 04:14, Scott Marlow <smarlow at redhat.com> wrote:
>> On 02/07/2012 10:25 AM, Sanne Grinovero wrote:
>>> 
>>> On 7 February 2012 15:21, Scott Marlow<smarlow at redhat.com>  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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache