On 4 June 2013 04:04, Scott Marlow <smarlow(a)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..
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(a)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(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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>