[infinispan-dev] (additional use case for WF8) Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x

[Scott Marlow]

On 06/04/2013 04:44 AM, Sanne Grinovero wrote:
> On 4 June 2013 04:04, Scott Marlow <smarlow at redhat.com> wrote:
>> On 06/03/2013 07:20 PM, Sanne Grinovero wrote:
>>>
>>> My very personal opinion is that if the user requires to "bring his
>>> own" Hibernate jars it is fair enough to require in turn that he
>>> should bring his own cache implementations as well.
>>
>>
>> For a non-clustered 2lc application, they could include Infinispan jars with
>> the hibernate jars.
>>
>> For an application using a clustered 2lc, currently, the system Infinispan
>> jars are expected to be used (so that the Infinispan dependency on
>> Hibernate-Infinispan is met for proper initialization).
>
> Couldn't "we expect" that in such case people would be free to bring their own
> Infinispan jars and will be on their own to configure it?
> I don't see why they should not be able to configure a clustered cache, as
> long as they are careful to isolate ports, etc..
>

Its possible that an application could bring its own Infinispan jars in 
but that conflicts with the direct dependencies that the JPA subsystem 
code has on the Infinispan system module (as well as EJB3 and possibly 
other WF8 system modules).

Mostly, I wanted to give a "heads up" that bundling of Hibernate jars 
with an application deployment, might not work when using the system 
Infinispan as the 2lc.

Is this an important use case to worry about?  I'm not sure at this point.

>>
>> Most of the complaints that I hear, are about WFLY-1151 not allowing a
>> different version of Hibernate 4.x to be included in the deployment. After
>> the fix for that is in WF8, we might hear more about deployments bringing
>> their own Hibernate jars and not being able to use the (system level)
>> Infinispan 2lc.
>>
>>
>>>
>>> It would be nice if we could test that one could then use different
>>> versions of Infinispan & JGroups, properly isolated from the ones WF
>>> provides.
>>
>>
>> I think we would hit problems where the JPA EE container/subsystem side
>> interacts with the Infinispan (system) module (probably EJB3 code as well.)
>
> Right, I realize that, but there might be a solution coming we call
> "grafting" JGRP-1613
> basically it should expose virtually independent channels so that
> multiple services
> needing an "owned" channel can use them without conflicts, but still sharing
> some protocols. So in the specific case of this discussion, people could
> reuse the ports, making it easier to configure and possibly faster to
> boot, but also
> reuse the cluster topology definition and failure detection, making it
> less awkward to use as in such
> a case you really don't want the topology from the AS to be out of sync with the
> topology used by some application cache.
>
> Sanne
>
>>
>>
>>>
>>> In an ideal world such a different Infinispan version should have the
>>> option to reuse the "main" JGroups channel managed by the AS... but I
>>> realize that is still a long way to go.
>>>
>>> Sanne
>>>
>>> On 3 June 2013 18:37, Scott Marlow <smarlow at redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm responding to this *old thread* to say that Paul's clustering magic
>>>> changes in AS7 resolved the dependency between the AS7 static Infinispan
>>>> module and the Hibernate-Infinispan module.  *Thanks Paul* and others
>>>> for jumping through hoops for that. :)
>>>>
>>>> However, in WF8, I'm catching up on fixing bugs that prevented Hibernate
>>>> 4.x jars from being packaged with the application.  With my local fixes,
>>>> I found that if the Hibernate jars are packaged with the application,
>>>> the WF8 Infinispan module will *not be able to* load the
>>>> Hibernate-Infinispan services (since the application deployment is not
>>>> visible to Infinispan service loading).
>>>>
>>>> Should we push on getting WF8 application deployments that contain the
>>>> Hibernate jars to work with the WF8 (system level) Infinispan module?
>>>>
>>>> Thanks,
>>>> Scott
>>>>
>>>> On 02/08/2012 10:27 AM, Galder Zamarreño wrote:
>>>>>
>>>>> Btw, I'd rather go with Paul's suggestion to modify AS7 Infinispan
>>>>> subsystem.
>>>>>
>>>>> On Feb 8, 2012, at 4:25 PM, Galder Zamarreño wrote:
>>>>>
>>>>>> Scott, what do you suggest doing instead then? Without the commands,
>>>>>> evictAll invalidation won't work.
>>>>>>
>>>>>> Are you suggesting that I revert back to using the cache as a
>>>>>> notification bus so that regions are invalidated?
>>>>>>
>>>>>> On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote:
>>>>>>
>>>>>>>
>>>>>>> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html
>>>>>>> has more context.
>>>>>>>
>>>>>>> Since there are no easy/quick fixes that can be applied at this time,
>>>>>>> to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module,
>>>>>>> I think we should avoid depending on the service loader way to supply the
>>>>>>> custom commands (in the Hibernate-Infinispan module), at least until this
>>>>>>> can be addressed elsewhere.
>>>>>>>
>>>>>>> I propose that the Hibernate-Infinispan second level cache should not
>>>>>>> use the Service Loader to pass custom commands into Infinispan.  If we
>>>>>>> agree, I'll create a jira for this.
>>>>>>>
>>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Galder Zamarreño
>>>>>> Sr. Software Engineer
>>>>>> Infinispan, JBoss Cache
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>