From galder at redhat.com  Mon Jan  4 10:32:05 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 4 Jan 2016 16:32:05 +0100
Subject: [infinispan-dev] IRC team meeting 4/Jan/2016
Message-ID: <7E9D6E12-FE1C-4E19-8316-3236BB5152A3@redhat.com>

Hi all,

Not many of us were online, but we managed to have a quick catch up, here are the minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-04-15.08.html

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From galder at redhat.com  Wed Jan  6 11:29:22 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 6 Jan 2016 17:29:22 +0100
Subject: [infinispan-dev] Atomic counters / sequences over Hot Rod
In-Reply-To: <CAFm4XO2Efspvueb_hHDYiuvuN7Ln41Obd2Y18x3J30=15XBFzg@mail.gmail.com>
References: <CAFm4XO2Efspvueb_hHDYiuvuN7Ln41Obd2Y18x3J30=15XBFzg@mail.gmail.com>
Message-ID: <1BABD46D-EDA3-4C7A-B739-12CDC071C94F@redhat.com>

Did you consider the option presented in [1]?

Cheers,

[1] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ReplaceWithVersionConcurrencyTest.java
--
Galder Zamarre?o
Infinispan, Red Hat

> On 18 Dec 2015, at 11:24, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> Hi all,
> I'm well aware that we don't have support for counters generally
> speaking, but for Infinispan in embedded mode I could so far use some
> clumsy workarounds: inefficient solutions but at least I could get it
> to work.
> 
> I'm not as expert in using the remote client though. Could someone
> volunteer to draft me some possible solution?
> 
> I would still hope the team will attack the issue of having efficient
> atomic counters too, but at this very moment I'd be happy with a
> temporary, low performance workaround.
> Server side scripting maybe?
> 
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From jsenko at redhat.com  Wed Jan 13 10:56:10 2016
From: jsenko at redhat.com (Jakub Senko)
Date: Wed, 13 Jan 2016 10:56:10 -0500 (EST)
Subject: [infinispan-dev] Formal verification (thesis)
In-Reply-To: <1571417169.4926046.1452698561908.JavaMail.zimbra@redhat.com>
Message-ID: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>

Hi all!

I'm considering a thesis topic [1] inspired by the successful use
of automated formal verification methods by Amazon engineers for AWS S3 and others [2].

The basic idea is to use similar tools to verify core parts of Infinispan
by constructing a simplified model (because of the state space explosion).
Most useful areas seem to be the transport layer, command object execution
(get, put, topology change, state transfer), entry locks etc.
On the other hand, I'd exclude transactional operations
which would be too complicated/costly to verify.

Do you think this would be useful for you as the infinispan developers?
Do you have suggestions on what (not) to focus?
I'd be happy for any comments.

Cheers,
Jakub Senko

[1] https://diplomky.redhat.com/topic/show/355/formal-design-of-distributed-hash-table
[2] http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext

From ttarrant at redhat.com  Thu Jan 14 03:34:30 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 14 Jan 2016 09:34:30 +0100
Subject: [infinispan-dev] Formal verification (thesis)
In-Reply-To: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
References: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
Message-ID: <56975D96.1080204@redhat.com>

Hello Jakub,

not only are we interested: we have been talking about it for a while, 
but lack of time has not allowed us to pursue it.
So yes, it would be very useful. As far as scope it seems like you 
already have a good grasp of what to tackle, and we are more than happy 
to answer any questions you might have.
I would like both Bela Ban and Richard Achmatowicz to add their thoughts 
to this, as they have more intimate knowledge with the tools and the 
concepts behind formal verification.

Tristan

On 13/01/2016 16:56, Jakub Senko wrote:
> Hi all!
>
> I'm considering a thesis topic [1] inspired by the successful use
> of automated formal verification methods by Amazon engineers for AWS S3 and others [2].
>
> The basic idea is to use similar tools to verify core parts of Infinispan
> by constructing a simplified model (because of the state space explosion).
> Most useful areas seem to be the transport layer, command object execution
> (get, put, topology change, state transfer), entry locks etc.
> On the other hand, I'd exclude transactional operations
> which would be too complicated/costly to verify.
>
> Do you think this would be useful for you as the infinispan developers?
> Do you have suggestions on what (not) to focus?
> I'd be happy for any comments.
>
> Cheers,
> Jakub Senko
>
> [1] https://diplomky.redhat.com/topic/show/355/formal-design-of-distributed-hash-table
> [2] http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From slaskawi at redhat.com  Thu Jan 14 03:59:00 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 14 Jan 2016 09:59:00 +0100
Subject: [infinispan-dev] Formal verification (thesis)
In-Reply-To: <56975D96.1080204@redhat.com>
References: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
	<56975D96.1080204@redhat.com>
Message-ID: <CAA9R9O4NQn0cOEmAyLyWt+BeTxhf8Y9rvHmDGCC=Z0TgQWnP=w@mail.gmail.com>

I would be also interested in this. Please keep me in the loop.

On Thu, Jan 14, 2016 at 9:34 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Hello Jakub,
>
> not only are we interested: we have been talking about it for a while,
> but lack of time has not allowed us to pursue it.
> So yes, it would be very useful. As far as scope it seems like you
> already have a good grasp of what to tackle, and we are more than happy
> to answer any questions you might have.
> I would like both Bela Ban and Richard Achmatowicz to add their thoughts
> to this, as they have more intimate knowledge with the tools and the
> concepts behind formal verification.
>
> Tristan
>
> On 13/01/2016 16:56, Jakub Senko wrote:
> > Hi all!
> >
> > I'm considering a thesis topic [1] inspired by the successful use
> > of automated formal verification methods by Amazon engineers for AWS S3
> and others [2].
> >
> > The basic idea is to use similar tools to verify core parts of Infinispan
> > by constructing a simplified model (because of the state space
> explosion).
> > Most useful areas seem to be the transport layer, command object
> execution
> > (get, put, topology change, state transfer), entry locks etc.
> > On the other hand, I'd exclude transactional operations
> > which would be too complicated/costly to verify.
> >
> > Do you think this would be useful for you as the infinispan developers?
> > Do you have suggestions on what (not) to focus?
> > I'd be happy for any comments.
> >
> > Cheers,
> > Jakub Senko
> >
> > [1]
> https://diplomky.redhat.com/topic/show/355/formal-design-of-distributed-hash-table
> > [2]
> http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160114/aaf976e4/attachment-0001.html 

From rvansa at redhat.com  Thu Jan 14 04:34:12 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 14 Jan 2016 10:34:12 +0100
Subject: [infinispan-dev] jdk8backported package
Message-ID: <56976B94.9010704@redhat.com>

Hi,

although we're on Java 8, there's still the package 
org.infinispan.*.jdk8backported in our codebase. Is there any plan (and 
possibility) to remove these and use implementation provided by runtime? 
Or have we tweaked them too much, so shall we rather rename them?

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From ttarrant at redhat.com  Thu Jan 14 09:25:36 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 14 Jan 2016 15:25:36 +0100
Subject: [infinispan-dev] Release schedule
Message-ID: <5697AFE0.7030109@redhat.com>

Hi all,

since the amount of pending PRs is quite large, I'm proposing we skip 
Alpha releases for 8.2 and release a Beta at the end of January after 
we've integrated them. Most of the PR are for internals only, so I don't 
see this as a problem.

Wdyt ?

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From bban at redhat.com  Thu Jan 14 09:52:37 2016
From: bban at redhat.com (Bela Ban)
Date: Thu, 14 Jan 2016 15:52:37 +0100
Subject: [infinispan-dev] Formal verification (thesis)
In-Reply-To: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
References: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
Message-ID: <5697B635.80304@redhat.com>

Hi Jakub,

interesting topic!

Here are some areas where an investigation would be fruitful, in no 
particular order:

Correctness of reads and writes in a distributed cache wrt state transfer:
- Model gets and puts against a distributed data store
- Run the model checker against this and see that there's no scenario 
where we can end up with inconsistent data
- Add state transfer into the fold

Split brain / network partitions:
- Model a network partition, clients continue accessing the same values
- Remove the split
- Make sure the data in all nodes is consistent
- Simulate multiple network partitions, e.g. from {A,B,C,D,E} -> {ABC} 
and {DE}, then {ABC} -> {AB} and {C} etc

This may be too complex to model in TLA+, have you considered looking 
into Jepsen/Knossos as well? You'd have to talk to the Infinispan team 
to see what behavior is guaranteed by which configuration and then use 
these tools to make sure the actual behavior == the expected behavior.
Cheers,


On 13/01/16 16:56, Jakub Senko wrote:
> Hi all!
>
> I'm considering a thesis topic [1] inspired by the successful use
> of automated formal verification methods by Amazon engineers for AWS S3 and others [2].
>
> The basic idea is to use similar tools to verify core parts of Infinispan
> by constructing a simplified model (because of the state space explosion).
> Most useful areas seem to be the transport layer, command object execution
> (get, put, topology change, state transfer), entry locks etc.
> On the other hand, I'd exclude transactional operations
> which would be too complicated/costly to verify.
>
> Do you think this would be useful for you as the infinispan developers?
> Do you have suggestions on what (not) to focus?
> I'd be happy for any comments.
>
> Cheers,
> Jakub Senko
>
> [1] https://diplomky.redhat.com/topic/show/355/formal-design-of-distributed-hash-table
> [2] http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


From rvansa at redhat.com  Thu Jan 14 10:27:39 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 14 Jan 2016 16:27:39 +0100
Subject: [infinispan-dev] Formal verification (thesis)
In-Reply-To: <5697B635.80304@redhat.com>
References: <1447398337.4938284.1452700570206.JavaMail.zimbra@redhat.com>
	<5697B635.80304@redhat.com>
Message-ID: <5697BE6B.3070108@redhat.com>

AFAIK Jepsen/Knossos verify actual behaviour of a system (execute random 
requests, record return values and then analyse consistency of these 
data). That's testing, but not verification - it can find some failing 
scenarios, but it cannot prove correctness.

Not that this wouldn't be useful, but it would be completely different 
subject.

Radim

On 01/14/2016 03:52 PM, Bela Ban wrote:
> Hi Jakub,
>
> interesting topic!
>
> Here are some areas where an investigation would be fruitful, in no
> particular order:
>
> Correctness of reads and writes in a distributed cache wrt state transfer:
> - Model gets and puts against a distributed data store
> - Run the model checker against this and see that there's no scenario
> where we can end up with inconsistent data
> - Add state transfer into the fold
>
> Split brain / network partitions:
> - Model a network partition, clients continue accessing the same values
> - Remove the split
> - Make sure the data in all nodes is consistent
> - Simulate multiple network partitions, e.g. from {A,B,C,D,E} -> {ABC}
> and {DE}, then {ABC} -> {AB} and {C} etc
>
> This may be too complex to model in TLA+, have you considered looking
> into Jepsen/Knossos as well? You'd have to talk to the Infinispan team
> to see what behavior is guaranteed by which configuration and then use
> these tools to make sure the actual behavior == the expected behavior.
> Cheers,
>
>
> On 13/01/16 16:56, Jakub Senko wrote:
>> Hi all!
>>
>> I'm considering a thesis topic [1] inspired by the successful use
>> of automated formal verification methods by Amazon engineers for AWS S3 and others [2].
>>
>> The basic idea is to use similar tools to verify core parts of Infinispan
>> by constructing a simplified model (because of the state space explosion).
>> Most useful areas seem to be the transport layer, command object execution
>> (get, put, topology change, state transfer), entry locks etc.
>> On the other hand, I'd exclude transactional operations
>> which would be too complicated/costly to verify.
>>
>> Do you think this would be useful for you as the infinispan developers?
>> Do you have suggestions on what (not) to focus?
>> I'd be happy for any comments.
>>
>> Cheers,
>> Jakub Senko
>>
>> [1] https://diplomky.redhat.com/topic/show/355/formal-design-of-distributed-hash-table
>> [2] http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods/fulltext
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From paranoiabla at gmail.com  Thu Jan 14 10:39:15 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 Jan 2016 17:39:15 +0200
Subject: [infinispan-dev] Jboss-logging old dependency
Message-ID: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>

Hello all,

I have a spring-boot application with Hibernate 5.0.6 and I'm using
hibernate-infinispan-5.0.6, which is depends on infinispan-7.2.1.Final.
When I start my application I get the following exception:


Caused by: java.lang.IllegalArgumentException: Logger implementation class
org.infinispan.persistence.remote.logging.Log_$logger has no matching
constructor

  at org.jboss.logging.Logger$1.run(Logger.java:2562)

  at java.security.AccessController.doPrivileged(Native Method)

  at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)

  at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)

  at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)

  at
org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)

  ... 198 more


I think it's a mismatch of the jboss-logging versions.


As far as I can see the infinispan brings, jboss-logging-processor
1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is quite
old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it possible
that someone would update the dependencies please, or help me debug this
error?


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160114/fa7dad7d/attachment.html 

From ttarrant at redhat.com  Thu Jan 14 10:48:40 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 14 Jan 2016 16:48:40 +0100
Subject: [infinispan-dev] Jboss-logging old dependency
In-Reply-To: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
References: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
Message-ID: <5697C358.9090203@redhat.com>

You can use Infinispan 8.1 with Hibernate 5.0.6.

Tristan

On 14/01/2016 16:39, Petar Tahchiev wrote:
> Hello all,
>
> I have a spring-boot application with Hibernate 5.0.6 and I'm using
> hibernate-infinispan-5.0.6, which is depends on infinispan-7.2.1.Final.
> When I start my application I get the following exception:
>
>
> Caused by: java.lang.IllegalArgumentException: Logger implementation
> class org.infinispan.persistence.remote.logging.Log_$logger has no
> matching constructor
>
>    at org.jboss.logging.Logger$1.run(Logger.java:2562)
>
>    at java.security.AccessController.doPrivileged(Native Method)
>
>    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)
>
>    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)
>
>    at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
>
>    at
> org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)
>
>    ... 198 more
>
>
> I think it's a mismatch of the jboss-logging versions.
>
>
> As far as I can see the infinispan brings, jboss-logging-processor
> 1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is quite
> old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it
> possible that someone would update the dependencies please, or help me
> debug this error?
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From paranoiabla at gmail.com  Thu Jan 14 11:20:25 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 Jan 2016 18:20:25 +0200
Subject: [infinispan-dev] Jboss-logging old dependency
In-Reply-To: <5697C358.9090203@redhat.com>
References: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
	<5697C358.9090203@redhat.com>
Message-ID: <CAKnbemX41Vj4ROa7rTECQD_zM_Eo-ahEiWCC7_1118n6NCbusQ@mail.gmail.com>

Thanks Tristan,

you're right - it's just a compile scope dependency. I updated the version
to 8.1.0.Final and now I get network is unreachable exception:

2016-01-14 18:00:08,031 com.zaxxer.hikari.HikariDataSource [main] INFO :
HikariPool-0 - is starting.
2016-01-14 18:00:09,524 org.hibernate.dialect.Dialect [main] INFO :
HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
2016-01-14 18:00:15,794 org.hibernate.cache.spi.UpdateTimestampsCache
[main] INFO : HHH000250: Starting update timestamps cache at region:
org.hibernate.cache.spi.UpdateTimestampsCache
2016-01-14 18:00:17,124
org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] INFO :
ISPN000078: Starting JGroups channel infinispan-hibernate-cluster
2016-01-14 18:00:17,161
org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] WARN :
ISPN000304: More than one configuration file with specified name on
classpath. The first one will be used:
 [jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-embedded/8.1.0.Final/infinispan-embedded-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml,
jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-core/8.1.0.Final/infinispan-core-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml]
2016-01-14 18:00:18,382 org.jgroups.protocols.MPING [main] ERROR: failed
sending discovery request
java.io.IOException: Network is unreachable
    at java.net.PlainDatagramSocketImpl.send(Native Method)
    at java.net.DatagramSocket.send(DatagramSocket.java:693)
    at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295)
    at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61)
    at org.jgroups.protocols.PING.findMembers(PING.java:31)
    at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
    at org.jgroups.protocols.Discovery.down(Discovery.java:384)
    at org.jgroups.protocols.MERGE3.down(MERGE3.java:255)
    at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:372)
    at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233)
    at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92)
    at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589)
    at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669)
    at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
    at
org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76)
    at
org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
    at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087)
    at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
    at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
    at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
    at org.jgroups.JChannel.down(JChannel.java:791)
    at org.jgroups.JChannel._connect(JChannel.java:564)
    at org.jgroups.JChannel.connect(JChannel.java:294)
    at org.jgroups.JChannel.connect(JChannel.java:279)
    at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:199)
    at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at
org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1426)
    at
org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
    at
org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
    at
org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
    at
org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
    at
org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
    at
org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
    at
org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:610)
    at
org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:572)
    at
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
    at
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:426)
    at
org.hibernate.cache.infinispan.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:672)
    at
org.hibernate.cache.infinispan.InfinispanRegionFactory.buildTimestampsRegion(InfinispanRegionFactory.java:326)
    at
org.hibernate.cache.spi.UpdateTimestampsCache.<init>(UpdateTimestampsCache.java:57)
    at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:53)
    at
org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:28)
    at
org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:20)
    at
org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:46)
    at
org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:234)
    at
org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:208)
    at
org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189)
    at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:242)
    at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
    at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:575)
    at
org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:541)
    at
org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:707)
    at
org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.getResourceToInject(PersistenceAnnotationBeanPostProcessor.java:680)
    at
org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
    at
org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
    at
org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessPropertyValues(PersistenceAnnotationBeanPostProcessor.java:354)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1116)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
    at
org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:813)
    at
org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
    at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:464)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.autowireResource(CommonAnnotationBeanPostProcessor.java:512)
    at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.getResource(CommonAnnotationBeanPostProcessor.java:486)
    at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor$ResourceElement.getResourceToInject(CommonAnnotationBeanPostProcessor.java:615)
    at
org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
    at
org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
    at
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:308)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:545)
    at
org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
    at
org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
    at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
    at
org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
    at
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at
org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
    at
org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
    at
org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
    at
org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
    at
org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at
org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
    at
org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
    at
org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
    at
org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
    at
org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
    at
org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at
org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
    at
org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
    at
org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
    at
org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
    at
org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
    at
org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:240)
    at
org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:687)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:523)
    at
org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118)
    at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764)
    at
org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357)
    at
org.springframework.boot.SpringApplication.run(SpringApplication.java:305)
    at
com.samplestore.SamplestoreApplication.main(SamplestoreApplication.java:41)


2016-01-14 17:48 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com>:

> You can use Infinispan 8.1 with Hibernate 5.0.6.
>
> Tristan
>
> On 14/01/2016 16:39, Petar Tahchiev wrote:
> > Hello all,
> >
> > I have a spring-boot application with Hibernate 5.0.6 and I'm using
> > hibernate-infinispan-5.0.6, which is depends on infinispan-7.2.1.Final.
> > When I start my application I get the following exception:
> >
> >
> > Caused by: java.lang.IllegalArgumentException: Logger implementation
> > class org.infinispan.persistence.remote.logging.Log_$logger has no
> > matching constructor
> >
> >    at org.jboss.logging.Logger$1.run(Logger.java:2562)
> >
> >    at java.security.AccessController.doPrivileged(Native Method)
> >
> >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)
> >
> >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)
> >
> >    at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
> >
> >    at
> >
> org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)
> >
> >    ... 198 more
> >
> >
> > I think it's a mismatch of the jboss-logging versions.
> >
> >
> > As far as I can see the infinispan brings, jboss-logging-processor
> > 1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is quite
> > old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it
> > possible that someone would update the dependencies please, or help me
> > debug this error?
> >
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160114/f98c82fb/attachment-0001.html 

From ttarrant at redhat.com  Thu Jan 14 11:33:56 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 14 Jan 2016 17:33:56 +0100
Subject: [infinispan-dev] Jboss-logging old dependency
In-Reply-To: <CAKnbemX41Vj4ROa7rTECQD_zM_Eo-ahEiWCC7_1118n6NCbusQ@mail.gmail.com>
References: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
	<5697C358.9090203@redhat.com>
	<CAKnbemX41Vj4ROa7rTECQD_zM_Eo-ahEiWCC7_1118n6NCbusQ@mail.gmail.com>
Message-ID: <5697CDF4.4090702@redhat.com>

Odd, it's pulling in both infinispan-embedded and infinispan-core: it 
should be either one or the other.
Also is it your intention to have a clustered cache ?

Tristan

On 14/01/2016 17:20, Petar Tahchiev wrote:
> Thanks Tristan,
>
> you're right - it's just a compile scope dependency. I updated the
> version to 8.1.0.Final and now I get network is unreachable exception:
>
> 2016-01-14 18:00:08,031 com.zaxxer.hikari.HikariDataSource [main] INFO :
> HikariPool-0 - is starting.
> 2016-01-14 18:00:09,524 org.hibernate.dialect.Dialect [main] INFO :
> HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
> 2016-01-14 18:00:15,794 org.hibernate.cache.spi.UpdateTimestampsCache
> [main] INFO : HHH000250: Starting update timestamps cache at region:
> org.hibernate.cache.spi.UpdateTimestampsCache
> 2016-01-14 18:00:17,124
> org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] INFO :
> ISPN000078: Starting JGroups channel infinispan-hibernate-cluster
> 2016-01-14 18:00:17,161
> org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] WARN :
> ISPN000304: More than one configuration file with specified name on
> classpath. The first one will be used:
>   [jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-embedded/8.1.0.Final/infinispan-embedded-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml, jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-core/8.1.0.Final/infinispan-core-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml]
> 2016-01-14 18:00:18,382 org.jgroups.protocols.MPING [main] ERROR: failed
> sending discovery request
> java.io.IOException: Network is unreachable
>      at java.net.PlainDatagramSocketImpl.send(Native Method)
>      at java.net.DatagramSocket.send(DatagramSocket.java:693)
>      at
> org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295)
>      at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61)
>      at org.jgroups.protocols.PING.findMembers(PING.java:31)
>      at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
>      at org.jgroups.protocols.Discovery.down(Discovery.java:384)
>      at org.jgroups.protocols.MERGE3.down(MERGE3.java:255)
>      at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:372)
>      at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233)
>      at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92)
>      at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589)
>      at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669)
>      at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>      at
> org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76)
>      at
> org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
>      at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087)
>      at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
>      at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>      at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
>      at org.jgroups.JChannel.down(JChannel.java:791)
>      at org.jgroups.JChannel._connect(JChannel.java:564)
>      at org.jgroups.JChannel.connect(JChannel.java:294)
>      at org.jgroups.JChannel.connect(JChannel.java:279)
>      at
> org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:199)
>      at
> org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>      at java.lang.reflect.Method.invoke(Method.java:497)
>      at
> org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1426)
>      at
> org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>      at
> org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
>      at
> org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
>      at
> org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
>      at
> org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
>      at
> org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
>      at
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:610)
>      at
> org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:572)
>      at
> org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
>      at
> org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:426)
>      at
> org.hibernate.cache.infinispan.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:672)
>      at
> org.hibernate.cache.infinispan.InfinispanRegionFactory.buildTimestampsRegion(InfinispanRegionFactory.java:326)
>      at
> org.hibernate.cache.spi.UpdateTimestampsCache.<init>(UpdateTimestampsCache.java:57)
>      at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:53)
>      at
> org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:28)
>      at
> org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:20)
>      at
> org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:46)
>      at
> org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:234)
>      at
> org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:208)
>      at
> org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189)
>      at
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:242)
>      at
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
>      at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
>      at
> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>      at
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>      at
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:575)
>      at
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:541)
>      at
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:707)
>      at
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.getResourceToInject(PersistenceAnnotationBeanPostProcessor.java:680)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>      at
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessPropertyValues(PersistenceAnnotationBeanPostProcessor.java:354)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1116)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:813)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:464)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>      at
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.autowireResource(CommonAnnotationBeanPostProcessor.java:512)
>      at
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.getResource(CommonAnnotationBeanPostProcessor.java:486)
>      at
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor$ResourceElement.getResourceToInject(CommonAnnotationBeanPostProcessor.java:615)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>      at
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:308)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:545)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>      at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
>      at
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>      at
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>      at
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>      at
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>      at
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>      at
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>      at
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>      at
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>      at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>      at
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>      at
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>      at
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>      at
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>      at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>      at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>      at
> org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:240)
>      at
> org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:687)
>      at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:523)
>      at
> org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118)
>      at
> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764)
>      at
> org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357)
>      at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:305)
>      at
> com.samplestore.SamplestoreApplication.main(SamplestoreApplication.java:41)
>
>
> 2016-01-14 17:48 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>>:
>
>     You can use Infinispan 8.1 with Hibernate 5.0.6.
>
>     Tristan
>
>     On 14/01/2016 16:39, Petar Tahchiev wrote:
>      > Hello all,
>      >
>      > I have a spring-boot application with Hibernate 5.0.6 and I'm using
>      > hibernate-infinispan-5.0.6, which is depends on
>     infinispan-7.2.1.Final.
>      > When I start my application I get the following exception:
>      >
>      >
>      > Caused by: java.lang.IllegalArgumentException: Logger implementation
>      > class org.infinispan.persistence.remote.logging.Log_$logger has no
>      > matching constructor
>      >
>      >    at org.jboss.logging.Logger$1.run(Logger.java:2562)
>      >
>      >    at java.security.AccessController.doPrivileged(Native Method)
>      >
>      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)
>      >
>      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)
>      >
>      >    at
>     org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
>      >
>      >    at
>      >
>     org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)
>      >
>      >    ... 198 more
>      >
>      >
>      > I think it's a mismatch of the jboss-logging versions.
>      >
>      >
>      > As far as I can see the infinispan brings, jboss-logging-processor
>      > 1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is
>     quite
>      > old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it
>      > possible that someone would update the dependencies please, or
>     help me
>      > debug this error?
>      >
>      >
>      >
>      > --
>      > Regards, Petar!
>      > Karlovo, Bulgaria.
>      > ---
>      > Public PGP Key at:
>      > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>      > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From paranoiabla at gmail.com  Thu Jan 14 12:55:25 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 Jan 2016 19:55:25 +0200
Subject: [infinispan-dev] Jboss-logging old dependency
In-Reply-To: <5697CDF4.4090702@redhat.com>
References: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
	<5697C358.9090203@redhat.com>
	<CAKnbemX41Vj4ROa7rTECQD_zM_Eo-ahEiWCC7_1118n6NCbusQ@mail.gmail.com>
	<5697CDF4.4090702@redhat.com>
Message-ID: <CAKnbemXnC0fF3-JMK91+Hs90S+qAMferOdbCncn2H5EKHK2JCA@mail.gmail.com>

Hi Tristan,

in my pom.xml I have these three:

org.hibernate:hibernate-infinispan
org.infinispan:infinispan-embedded
org.infinispan:infninispan-jcache

Turned out hibernate-infinispan and infinispan-jcache were bringing the
infinispan-core. I excluded it but the exception is still there. And odd
enough even though the exception is being thrown all around, my app seems
to be working.

Yes, clustered cache would be nice to have.


2016-01-14 18:33 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com>:

> Odd, it's pulling in both infinispan-embedded and infinispan-core: it
> should be either one or the other.
> Also is it your intention to have a clustered cache ?
>
> Tristan
>
> On 14/01/2016 17:20, Petar Tahchiev wrote:
> > Thanks Tristan,
> >
> > you're right - it's just a compile scope dependency. I updated the
> > version to 8.1.0.Final and now I get network is unreachable exception:
> >
> > 2016-01-14 18:00:08,031 com.zaxxer.hikari.HikariDataSource [main] INFO :
> > HikariPool-0 - is starting.
> > 2016-01-14 18:00:09,524 org.hibernate.dialect.Dialect [main] INFO :
> > HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
> > 2016-01-14 18:00:15,794 org.hibernate.cache.spi.UpdateTimestampsCache
> > [main] INFO : HHH000250: Starting update timestamps cache at region:
> > org.hibernate.cache.spi.UpdateTimestampsCache
> > 2016-01-14 18:00:17,124
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] INFO :
> > ISPN000078: Starting JGroups channel infinispan-hibernate-cluster
> > 2016-01-14 18:00:17,161
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] WARN :
> > ISPN000304: More than one configuration file with specified name on
> > classpath. The first one will be used:
> >
>  [jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-embedded/8.1.0.Final/infinispan-embedded-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml,
> jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-core/8.1.0.Final/infinispan-core-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml]
> > 2016-01-14 18:00:18,382 org.jgroups.protocols.MPING [main] ERROR: failed
> > sending discovery request
> > java.io.IOException: Network is unreachable
> >      at java.net.PlainDatagramSocketImpl.send(Native Method)
> >      at java.net.DatagramSocket.send(DatagramSocket.java:693)
> >      at
> > org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295)
> >      at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61)
> >      at org.jgroups.protocols.PING.findMembers(PING.java:31)
> >      at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
> >      at org.jgroups.protocols.Discovery.down(Discovery.java:384)
> >      at org.jgroups.protocols.MERGE3.down(MERGE3.java:255)
> >      at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:372)
> >      at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233)
> >      at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92)
> >      at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589)
> >      at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669)
> >      at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> >      at
> >
> org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76)
> >      at
> > org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
> >      at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087)
> >      at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
> >      at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> >      at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
> >      at org.jgroups.JChannel.down(JChannel.java:791)
> >      at org.jgroups.JChannel._connect(JChannel.java:564)
> >      at org.jgroups.JChannel.connect(JChannel.java:294)
> >      at org.jgroups.JChannel.connect(JChannel.java:279)
> >      at
> >
> org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:199)
> >      at
> >
> org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
> >      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >      at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >      at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >      at java.lang.reflect.Method.invoke(Method.java:497)
> >      at
> >
> org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1426)
> >      at
> >
> org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> >      at
> >
> org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
> >      at
> >
> org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> >      at
> >
> org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
> >      at
> >
> org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
> >      at
> >
> org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
> >      at
> >
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:610)
> >      at
> >
> org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:572)
> >      at
> >
> org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> >      at
> >
> org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:426)
> >      at
> >
> org.hibernate.cache.infinispan.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:672)
> >      at
> >
> org.hibernate.cache.infinispan.InfinispanRegionFactory.buildTimestampsRegion(InfinispanRegionFactory.java:326)
> >      at
> >
> org.hibernate.cache.spi.UpdateTimestampsCache.<init>(UpdateTimestampsCache.java:57)
> >      at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:53)
> >      at
> >
> org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:28)
> >      at
> >
> org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:20)
> >      at
> >
> org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:46)
> >      at
> >
> org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:234)
> >      at
> >
> org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:208)
> >      at
> >
> org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189)
> >      at
> >
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:242)
> >      at
> >
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> >      at
> >
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> >      at
> >
> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
> >      at
> >
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
> >      at
> >
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:575)
> >      at
> >
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:541)
> >      at
> >
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:707)
> >      at
> >
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.getResourceToInject(PersistenceAnnotationBeanPostProcessor.java:680)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
> >      at
> >
> org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessPropertyValues(PersistenceAnnotationBeanPostProcessor.java:354)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1116)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:813)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:464)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> >      at
> >
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.autowireResource(CommonAnnotationBeanPostProcessor.java:512)
> >      at
> >
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.getResource(CommonAnnotationBeanPostProcessor.java:486)
> >      at
> >
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor$ResourceElement.getResourceToInject(CommonAnnotationBeanPostProcessor.java:615)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
> >      at
> >
> org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:308)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:545)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
> >      at
> >
> org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
> >      at
> >
> org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
> >      at
> >
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> >      at
> >
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
> >      at
> >
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
> >      at
> >
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> >      at
> >
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
> >      at
> >
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
> >      at
> >
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> >      at
> >
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> >      at
> >
> org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
> >      at
> >
> org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
> >      at
> >
> org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
> >      at
> >
> org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
> >      at
> >
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
> >      at
> >
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
> >      at
> >
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
> >      at
> >
> org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:240)
> >      at
> >
> org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:687)
> >      at
> >
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:523)
> >      at
> >
> org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118)
> >      at
> >
> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764)
> >      at
> >
> org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357)
> >      at
> >
> org.springframework.boot.SpringApplication.run(SpringApplication.java:305)
> >      at
> >
> com.samplestore.SamplestoreApplication.main(SamplestoreApplication.java:41)
> >
> >
> > 2016-01-14 17:48 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com
> > <mailto:ttarrant at redhat.com>>:
> >
> >     You can use Infinispan 8.1 with Hibernate 5.0.6.
> >
> >     Tristan
> >
> >     On 14/01/2016 16:39, Petar Tahchiev wrote:
> >      > Hello all,
> >      >
> >      > I have a spring-boot application with Hibernate 5.0.6 and I'm
> using
> >      > hibernate-infinispan-5.0.6, which is depends on
> >     infinispan-7.2.1.Final.
> >      > When I start my application I get the following exception:
> >      >
> >      >
> >      > Caused by: java.lang.IllegalArgumentException: Logger
> implementation
> >      > class org.infinispan.persistence.remote.logging.Log_$logger has no
> >      > matching constructor
> >      >
> >      >    at org.jboss.logging.Logger$1.run(Logger.java:2562)
> >      >
> >      >    at java.security.AccessController.doPrivileged(Native Method)
> >      >
> >      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)
> >      >
> >      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)
> >      >
> >      >    at
> >     org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
> >      >
> >      >    at
> >      >
> >
>  org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)
> >      >
> >      >    ... 198 more
> >      >
> >      >
> >      > I think it's a mismatch of the jboss-logging versions.
> >      >
> >      >
> >      > As far as I can see the infinispan brings, jboss-logging-processor
> >      > 1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is
> >     quite
> >      > old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it
> >      > possible that someone would update the dependencies please, or
> >     help me
> >      > debug this error?
> >      >
> >      >
> >      >
> >      > --
> >      > Regards, Petar!
> >      > Karlovo, Bulgaria.
> >      > ---
> >      > Public PGP Key at:
> >      >
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >      > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
> 0611
> >      >
> >      >
> >      > _______________________________________________
> >      > infinispan-dev mailing list
> >      > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >      >
> >
> >     --
> >     Tristan Tarrant
> >     Infinispan Lead
> >     JBoss, a division of Red Hat
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160114/654eb8ab/attachment-0001.html 

From sanne at infinispan.org  Thu Jan 14 15:31:35 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 14 Jan 2016 20:31:35 +0000
Subject: [infinispan-dev] Jboss-logging old dependency
In-Reply-To: <CAKnbemXnC0fF3-JMK91+Hs90S+qAMferOdbCncn2H5EKHK2JCA@mail.gmail.com>
References: <CAKnbemX69oM2_L2+_GsX85ZDOCTmTTki_7H=uNHrtNy=JNxxUQ@mail.gmail.com>
	<5697C358.9090203@redhat.com>
	<CAKnbemX41Vj4ROa7rTECQD_zM_Eo-ahEiWCC7_1118n6NCbusQ@mail.gmail.com>
	<5697CDF4.4090702@redhat.com>
	<CAKnbemXnC0fF3-JMK91+Hs90S+qAMferOdbCncn2H5EKHK2JCA@mail.gmail.com>
Message-ID: <CAFm4XO26hRyx9224zp8nMCwuWSfduo0WSerZaWx4s6s6dZx1bw@mail.gmail.com>

Hi Petar,
you do not need infinispan-embedded and infinispan-jcache.
I would recommend to use just org.hibernate:hibernate-infinispan and
the dependencies it explicitly declares; however you might want to
override those to use Infinispan 8.1

In our conversation on the Hibernate mailing list I mentioned that you
can use Infinispan in embedded mode; I realize now this terms is a bit
confusing as you went looking for the infinispan-embedded jar. This
jar is just a jar which includes infinispan-core, infinispan-commons
and several other dependencies.
To run Infinispan in "embedded mode" you don't need this jar.
Also the Hibernate 2nd level cache integration for Infinispan doesn't
support Hot Rod, the remote protocol version of Infinispan so you
can't go wrong with that ;)

Finally, as I mentioned on the Hibernate mailing list Hibernate
doesn't integrate yet with JCache at this moment; it just sports
Infinispan and Ehcache directly without using the caching standard API
so there's no need for the jcache bridge either.

Sanne

On 14 January 2016 at 17:55, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Hi Tristan,
>
> in my pom.xml I have these three:
>
> org.hibernate:hibernate-infinispan
> org.infinispan:infinispan-embedded
> org.infinispan:infninispan-jcache
>
> Turned out hibernate-infinispan and infinispan-jcache were bringing the
> infinispan-core. I excluded it but the exception is still there. And odd
> enough even though the exception is being thrown all around, my app seems to
> be working.
>
> Yes, clustered cache would be nice to have.
>
>
> 2016-01-14 18:33 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com>:
>>
>> Odd, it's pulling in both infinispan-embedded and infinispan-core: it
>> should be either one or the other.
>> Also is it your intention to have a clustered cache ?
>>
>> Tristan
>>
>> On 14/01/2016 17:20, Petar Tahchiev wrote:
>> > Thanks Tristan,
>> >
>> > you're right - it's just a compile scope dependency. I updated the
>> > version to 8.1.0.Final and now I get network is unreachable exception:
>> >
>> > 2016-01-14 18:00:08,031 com.zaxxer.hikari.HikariDataSource [main] INFO :
>> > HikariPool-0 - is starting.
>> > 2016-01-14 18:00:09,524 org.hibernate.dialect.Dialect [main] INFO :
>> > HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> > 2016-01-14 18:00:15,794 org.hibernate.cache.spi.UpdateTimestampsCache
>> > [main] INFO : HHH000250: Starting update timestamps cache at region:
>> > org.hibernate.cache.spi.UpdateTimestampsCache
>> > 2016-01-14 18:00:17,124
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] INFO :
>> > ISPN000078: Starting JGroups channel infinispan-hibernate-cluster
>> > 2016-01-14 18:00:17,161
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport [main] WARN :
>> > ISPN000304: More than one configuration file with specified name on
>> > classpath. The first one will be used:
>> >
>> > [jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-embedded/8.1.0.Final/infinispan-embedded-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml,
>> > jar:file:/home/petar/.m2/repository/org/infinispan/infinispan-core/8.1.0.Final/infinispan-core-8.1.0.Final.jar!/default-configs/default-jgroups-tcp.xml]
>> > 2016-01-14 18:00:18,382 org.jgroups.protocols.MPING [main] ERROR: failed
>> > sending discovery request
>> > java.io.IOException: Network is unreachable
>> >      at java.net.PlainDatagramSocketImpl.send(Native Method)
>> >      at java.net.DatagramSocket.send(DatagramSocket.java:693)
>> >      at
>> > org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295)
>> >      at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61)
>> >      at org.jgroups.protocols.PING.findMembers(PING.java:31)
>> >      at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
>> >      at org.jgroups.protocols.Discovery.down(Discovery.java:384)
>> >      at org.jgroups.protocols.MERGE3.down(MERGE3.java:255)
>> >      at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:372)
>> >      at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233)
>> >      at
>> > org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92)
>> >      at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589)
>> >      at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669)
>> >      at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
>> >      at
>> >
>> > org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76)
>> >      at
>> > org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
>> >      at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087)
>> >      at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
>> >      at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
>> >      at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
>> >      at org.jgroups.JChannel.down(JChannel.java:791)
>> >      at org.jgroups.JChannel._connect(JChannel.java:564)
>> >      at org.jgroups.JChannel.connect(JChannel.java:294)
>> >      at org.jgroups.JChannel.connect(JChannel.java:279)
>> >      at
>> >
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:199)
>> >      at
>> >
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
>> >      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >      at
>> >
>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> >      at
>> >
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >      at java.lang.reflect.Method.invoke(Method.java:497)
>> >      at
>> >
>> > org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1426)
>> >      at
>> >
>> > org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>> >      at
>> >
>> > org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
>> >      at
>> >
>> > org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
>> >      at
>> >
>> > org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
>> >      at
>> >
>> > org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
>> >      at
>> >
>> > org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
>> >      at
>> >
>> > org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:610)
>> >      at
>> >
>> > org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:572)
>> >      at
>> >
>> > org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
>> >      at
>> >
>> > org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:426)
>> >      at
>> >
>> > org.hibernate.cache.infinispan.InfinispanRegionFactory.getCache(InfinispanRegionFactory.java:672)
>> >      at
>> >
>> > org.hibernate.cache.infinispan.InfinispanRegionFactory.buildTimestampsRegion(InfinispanRegionFactory.java:326)
>> >      at
>> >
>> > org.hibernate.cache.spi.UpdateTimestampsCache.<init>(UpdateTimestampsCache.java:57)
>> >      at org.hibernate.internal.CacheImpl.<init>(CacheImpl.java:53)
>> >      at
>> >
>> > org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:28)
>> >      at
>> >
>> > org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:20)
>> >      at
>> >
>> > org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistryImpl.java:46)
>> >      at
>> >
>> > org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:234)
>> >      at
>> >
>> > org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:208)
>> >      at
>> >
>> > org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189)
>> >      at
>> >
>> > org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:242)
>> >      at
>> >
>> > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
>> >      at
>> >
>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
>> >      at
>> >
>> > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>> >      at
>> >
>> > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>> >      at
>> >
>> > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:575)
>> >      at
>> >
>> > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:541)
>> >      at
>> >
>> > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.resolveEntityManager(PersistenceAnnotationBeanPostProcessor.java:707)
>> >      at
>> >
>> > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor$PersistenceElement.getResourceToInject(PersistenceAnnotationBeanPostProcessor.java:680)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>> >      at
>> >
>> > org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessPropertyValues(PersistenceAnnotationBeanPostProcessor.java:354)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1116)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:813)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:464)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>> >      at
>> >
>> > org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.autowireResource(CommonAnnotationBeanPostProcessor.java:512)
>> >      at
>> >
>> > org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.getResource(CommonAnnotationBeanPostProcessor.java:486)
>> >      at
>> >
>> > org.springframework.context.annotation.CommonAnnotationBeanPostProcessor$ResourceElement.getResourceToInject(CommonAnnotationBeanPostProcessor.java:615)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata$InjectedElement.inject(InjectionMetadata.java:169)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>> >      at
>> >
>> > org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.postProcessPropertyValues(CommonAnnotationBeanPostProcessor.java:308)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:545)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1192)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1068)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:618)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:88)
>> >      at
>> >
>> > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:331)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1214)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:543)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>> >      at
>> >
>> > org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>> >      at
>> >
>> > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>> >      at
>> >
>> > org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>> >      at
>> >
>> > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
>> >      at
>> >
>> > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:368)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans(BeanFactoryAdvisorRetrievalHelper.java:92)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findCandidateAdvisors(AbstractAdvisorAutoProxyCreator.java:101)
>> >      at
>> >
>> > org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:85)
>> >      at
>> >
>> > org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:103)
>> >      at
>> >
>> > org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessBeforeInstantiation(AbstractAutoProxyCreator.java:248)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:988)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.resolveBeforeInstantiation(AbstractAutowireCapableBeanFactory.java:959)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:472)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
>> >      at
>> >
>> > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
>> >      at
>> >
>> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>> >      at
>> >
>> > org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:240)
>> >      at
>> >
>> > org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:687)
>> >      at
>> >
>> > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:523)
>> >      at
>> >
>> > org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118)
>> >      at
>> >
>> > org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764)
>> >      at
>> >
>> > org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357)
>> >      at
>> >
>> > org.springframework.boot.SpringApplication.run(SpringApplication.java:305)
>> >      at
>> >
>> > com.samplestore.SamplestoreApplication.main(SamplestoreApplication.java:41)
>> >
>> >
>> > 2016-01-14 17:48 GMT+02:00 Tristan Tarrant <ttarrant at redhat.com
>> > <mailto:ttarrant at redhat.com>>:
>> >
>> >     You can use Infinispan 8.1 with Hibernate 5.0.6.
>> >
>> >     Tristan
>> >
>> >     On 14/01/2016 16:39, Petar Tahchiev wrote:
>> >      > Hello all,
>> >      >
>> >      > I have a spring-boot application with Hibernate 5.0.6 and I'm
>> > using
>> >      > hibernate-infinispan-5.0.6, which is depends on
>> >     infinispan-7.2.1.Final.
>> >      > When I start my application I get the following exception:
>> >      >
>> >      >
>> >      > Caused by: java.lang.IllegalArgumentException: Logger
>> > implementation
>> >      > class org.infinispan.persistence.remote.logging.Log_$logger has
>> > no
>> >      > matching constructor
>> >      >
>> >      >    at org.jboss.logging.Logger$1.run(Logger.java:2562)
>> >      >
>> >      >    at java.security.AccessController.doPrivileged(Native Method)
>> >      >
>> >      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529)
>> >      >
>> >      >    at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516)
>> >      >
>> >      >    at
>> >     org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
>> >      >
>> >      >    at
>> >      >
>> >
>> > org.infinispan.persistence.remote.configuration.RemoteStoreConfigurationParser70.<clinit>(RemoteStoreConfigurationParser70.java:35)
>> >      >
>> >      >    ... 198 more
>> >      >
>> >      >
>> >      > I think it's a mismatch of the jboss-logging versions.
>> >      >
>> >      >
>> >      > As far as I can see the infinispan brings,
>> > jboss-logging-processor
>> >      > 1.1.0.Final, which depends on jboss-logging 3.1.2Final - which is
>> >     quite
>> >      > old. Hibernate 5.0.6 depends on jboss-logging 3.3.0.Final. Is it
>> >      > possible that someone would update the dependencies please, or
>> >     help me
>> >      > debug this error?
>> >      >
>> >      >
>> >      >
>> >      > --
>> >      > Regards, Petar!
>> >      > Karlovo, Bulgaria.
>> >      > ---
>> >      > Public PGP Key at:
>> >      >
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> >      > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>> > 0611
>> >      >
>> >      >
>> >      > _______________________________________________
>> >      > infinispan-dev mailing list
>> >      > infinispan-dev at lists.jboss.org
>> >     <mailto:infinispan-dev at lists.jboss.org>
>> >      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >      >
>> >
>> >     --
>> >     Tristan Tarrant
>> >     Infinispan Lead
>> >     JBoss, a division of Red Hat
>> >     _______________________________________________
>> >     infinispan-dev mailing list
>> >     infinispan-dev at lists.jboss.org
>> > <mailto:infinispan-dev at lists.jboss.org>
>> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>> >
>> >
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> > ---
>> > Public PGP Key at:
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From rory.odonnell at oracle.com  Fri Jan 15 05:48:45 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 15 Jan 2016 10:48:45 +0000
Subject: [infinispan-dev] Early Access builds of JDK 8u76 b02,
 JDK 9 build b100 & build b99 for JDK 9 with Project Jigsaw are
 available on java.net
Message-ID: <5698CE8D.8080104@oracle.com>


Hi Galder,

Early Access b02 <https://jdk8.java.net/download.html> for JDK 8u76 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/jdk8u76/changes/jdk8u76-b02.html>.

Early Access b100 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/jdk9/changes/jdk-9+100.html>.

Early Access b99 <https://jdk9.java.net/jigsaw/> for JDK 9 with Project 
Jigsaw is available on java.net, summary of changes are listed here 
<http://download.java.net/jigsaw/archive/99/binaries/jdk-9+99.html> .

Dalibor and I will be at FOSDEM '16, Brussels 30 & 31 January, link to 
our presentation here. 
<https://fosdem.org/2016/schedule/event/preparing_for_jdk_nine/>
Let us know if you will be there, hopefully we can meet up !

Rgds,Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160115/b641e33d/attachment.html 

From vrigamon at redhat.com  Fri Jan 15 11:00:53 2016
From: vrigamon at redhat.com (Vittorio Rigamonti)
Date: Fri, 15 Jan 2016 11:00:53 -0500 (EST)
Subject: [infinispan-dev] Release schedule
In-Reply-To: <5697AFE0.7030109@redhat.com>
References: <5697AFE0.7030109@redhat.com>
Message-ID: <1551704703.17222344.1452873653871.JavaMail.zimbra@redhat.com>

Hi,

just to discuss let me go slightly OT.

Do you known where can I find a precise definition for alpha, beta, cr
related to the infinispan/jboss dev process?


Thanks all,
Vittorio


----- Original Message -----
From: "Tristan Tarrant" <ttarrant at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Thursday, January 14, 2016 3:25:36 PM
Subject: [infinispan-dev] Release schedule

Hi all,

since the amount of pending PRs is quite large, I'm proposing we skip 
Alpha releases for 8.2 and release a Beta at the end of January after 
we've integrated them. Most of the PR are for internals only, so I don't 
see this as a problem.

Wdyt ?

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

From ttarrant at redhat.com  Mon Jan 18 10:46:19 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 18 Jan 2016 16:46:19 +0100
Subject: [infinispan-dev] Weekly IRC Meeting logs 2016-01-18
Message-ID: <569D08CB.1010607@redhat.com>

Dear all,

please find the logs for this week's meeting at the following address:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-18-15.00.log.html

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From ttarrant at redhat.com  Mon Jan 18 10:47:04 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 18 Jan 2016 16:47:04 +0100
Subject: [infinispan-dev] Weekly IRC Meeting logs 2016-01-11
Message-ID: <569D08F8.5010809@redhat.com>

Dear all,

I forgot to send the logs for last week's meeting, so here they are :)

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-11-15.01.log.html

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From cstroe at gmail.com  Tue Jan 19 12:32:17 2016
From: cstroe at gmail.com (Cosmin Stroe)
Date: Tue, 19 Jan 2016 11:32:17 -0600
Subject: [infinispan-dev] Infinispan Cache Store Failure Detection and
	Recovery
Message-ID: <CAAGUZXAkdEh17EKaz=rytTA0f6-EzChWWvkM1USFsZORswLrbA@mail.gmail.com>

Hello everyone,

We're setting up an Infinispan deployment for a web application.  Our use
case includes a local Infinispan cache (running in the same JVM as the web
app) backed by a remote Infinispan cache (running in a separate JVM).

We have to investigate failure modes of said cache.  One of the scenarios
we have to handle is "What happens if the remote Infinispan cache goes
away?".  This could happen for various reasons, including if we restart the
remote Infinispan cache.  We would like to have some known state during
remote cache outages (which we hope would happen very infrequently).

My conversation with "ttarrant" on Freenode led us to believe that
Infinispan doesn't currently have any failure mode handling built in, and
that it's possible that we could make the Async Store decorator optionally
be able to "resist" store failures.  Not sure what other options we have.

The correct answer might also be, "Just have the cache return null if an
entry is not in the local cache and the remote cache is unresponsive, and
have the application gracefully handle the empty cache".  I'm not sure if
that option can be implemented with the current Infinispan code.

Any thoughts on this?
Cosmin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160119/9ee27471/attachment.html 

From rvansa at redhat.com  Mon Jan 25 05:57:53 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Jan 2016 11:57:53 +0100
Subject: [infinispan-dev] Repeatable read nulls
Message-ID: <56A5FFB1.4090505@redhat.com>

Hi,

in transactional mode with repeatable reads, the read entry is stored in 
the context, even if it is null (iiuc). However, in 
TxDistributionInterceptor.visitGetKeyValueCommand the valueIsMissing() 
is checked which returns true if entry.isNull() (in RepeatableReadEntry 
this is implemented as value == null). Therefore, null reads are not 
repeatable.

Any reason for that?

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From pedro at infinispan.org  Mon Jan 25 06:03:36 2016
From: pedro at infinispan.org (Pedro Ruivo)
Date: Mon, 25 Jan 2016 11:03:36 +0000
Subject: [infinispan-dev] Repeatable read nulls
In-Reply-To: <56A5FFB1.4090505@redhat.com>
References: <56A5FFB1.4090505@redhat.com>
Message-ID: <56A60108.7040201@infinispan.org>

Hi Radim

For RepeatableRead, skipLookup is set to true so valueIsMissing() is 
going to return false.

Cheers,
Pedro

On 01/25/2016 10:57 AM, Radim Vansa wrote:
> Hi,
>
> in transactional mode with repeatable reads, the read entry is stored in
> the context, even if it is null (iiuc). However, in
> TxDistributionInterceptor.visitGetKeyValueCommand the valueIsMissing()
> is checked which returns true if entry.isNull() (in RepeatableReadEntry
> this is implemented as value == null). Therefore, null reads are not
> repeatable.
>
> Any reason for that?
>
> Radim
>

From ttarrant at redhat.com  Mon Jan 25 08:29:14 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 Jan 2016 14:29:14 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
Message-ID: <56A6232A.4060402@redhat.com>

Hi all,

Jakub has recently revived the Cassandra Cache Store (CCS from now on) 
which, as you all will remember, was pushed to an external repository 
where it lay in abandonment ever since.

We now need to add support for this store to Infinispan Server, but 
unfortunately, because of the "monolithic schema" approach that WildFly 
imposes on subsystems, this has to be done within the Infinispan 
subsystem itself.
This creates a conundrum, since the CCS depends on Infinispan core, 
server would depend on the CCS but server is part of the Infinispan build.

Possible solutions:
1) move the CCS back into the main repo
    - pros: no more conundrum, built by default, easier to maintain
    - cons: makes the repo even bigger, binds the lifecycle of the CCS 
to Infinispan's
2) extend the server to be able to interpret the CCS schema but not 
actually depend on its code and provide the code to instantiate the CCS 
as an overlay module which can be installed on server
    - pros: keeps the lifecycle of the CCS independent
    - cons: additional complexity to handle the split, forces us to 
still keep server aligned with schema changes in the CCS itself.
3) make the CCS a deployable cache store
    - pros: easiest
    - cons: not really ootb experience, no nice schema
4) create a dedicated subsystem for the CCS and "invent" a way to 
reference it from the main Infinispan subsystem using a naming 
convention, similar to how datasources are currently implemented.
    - pros: keeps the two projects independent, reusable for other 
Cachestores
    - cons: writing a subsystem from scratch is complex (although bits 
of it could be made reusable for multiple cachestores).

Your thoughts please.

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From galder at redhat.com  Mon Jan 25 09:03:30 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 25 Jan 2016 15:03:30 +0100
Subject: [infinispan-dev] Hot Rod encoding
Message-ID: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com>

Hi all,

As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up.

The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set?

To be able to answer this question correctly, the Hot Rod client needs to know the type of the data.

Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream.

Protostream based marshaller adds encoding to the byte arrays by adding information of what the type of that is written, whether raw type or complex. Protostream is based around Protobuf which works well as medium for compatibility mode.

So, in essence, if we want get different clients working together, the simplest thing to do is to implement the Protostream marshaller in each client lang, and they should work together without probs. 

This option has the downside that by limiting our compatibility marshalling to Protostream, how would a standard REST client would understand this format? They'd need to have a way to understand Protostream...

Another option would be to setlle on UTF-8 String as compatibility medium and get the languages to convert types into JSON UTF-8 String. I think this would work better for REST-based clients. Also, AFAIK protobuf objects can be transformed into JSON, so if there's already a protostream marshaller available, that can be used to transform to JSON.

Down the line we might want to add encoding to Hot Rod or switch to a technology where encoding is sorted out for us, e.g. HTTP-based protocols...

Thoughts?

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From mudokonman at gmail.com  Mon Jan 25 09:15:39 2016
From: mudokonman at gmail.com (William Burns)
Date: Mon, 25 Jan 2016 14:15:39 +0000
Subject: [infinispan-dev] jdk8backported package
In-Reply-To: <56976B94.9010704@redhat.com>
References: <56976B94.9010704@redhat.com>
Message-ID: <CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>

Unfortunately this isn't really possible to remove these classes.  They
have additional changes over and above the jdk8 classes.  We could move it
into a different package though if we wanted to.

To be honest the only reason this is still really needed is for the
BoundedConcurrentHashMapV8.  I have been talking with Dan on and off for a
while about even possibly looking into using a different map implementation
(such as caffeine or something else equivalent).  We haven't looked into it
very seriously though.

We could look into this more if people think we want to tackle that.

 - Will

On Thu, Jan 14, 2016 at 4:34 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> although we're on Java 8, there's still the package
> org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
> possibility) to remove these and use implementation provided by runtime?
> Or have we tweaked them too much, so shall we rather rename them?
>
> Radim
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160125/00f18db9/attachment.html 

From sanne at infinispan.org  Mon Jan 25 09:24:28 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 25 Jan 2016 14:24:28 +0000
Subject: [infinispan-dev] jdk8backported package
In-Reply-To: <CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
References: <56976B94.9010704@redhat.com>
	<CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
Message-ID: <CAFm4XO3RMyZorf8bBKD6TQK+KHdaK4kfysxzBp=1J12cEzUezA@mail.gmail.com>

On 25 January 2016 at 14:15, William Burns <mudokonman at gmail.com> wrote:
> Unfortunately this isn't really possible to remove these classes.  They have
> additional changes over and above the jdk8 classes.  We could move it into a
> different package though if we wanted to.

+1 to change package: I have been confused about this too in the recent past.

>
> To be honest the only reason this is still really needed is for the
> BoundedConcurrentHashMapV8.  I have been talking with Dan on and off for a
> while about even possibly looking into using a different map implementation
> (such as caffeine or something else equivalent).  We haven't looked into it
> very seriously though.

Could you remove the other ones which are no longer needed?

>
> We could look into this more if people think we want to tackle that.
>
>  - Will
>
> On Thu, Jan 14, 2016 at 4:34 AM Radim Vansa <rvansa at redhat.com> wrote:
>>
>> Hi,
>>
>> although we're on Java 8, there's still the package
>> org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
>> possibility) to remove these and use implementation provided by runtime?
>> Or have we tweaked them too much, so shall we rather rename them?
>>
>> Radim
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> 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

From rvansa at redhat.com  Mon Jan 25 09:39:25 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Jan 2016 15:39:25 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <56A6232A.4060402@redhat.com>
References: <56A6232A.4060402@redhat.com>
Message-ID: <56A6339D.2030502@redhat.com>

Would the deployable cache stores benefit from 4) as well? It seems to 
me as the only 'right' option.

R.

On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> Hi all,
>
> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
> which, as you all will remember, was pushed to an external repository
> where it lay in abandonment ever since.
>
> We now need to add support for this store to Infinispan Server, but
> unfortunately, because of the "monolithic schema" approach that WildFly
> imposes on subsystems, this has to be done within the Infinispan
> subsystem itself.
> This creates a conundrum, since the CCS depends on Infinispan core,
> server would depend on the CCS but server is part of the Infinispan build.
>
> Possible solutions:
> 1) move the CCS back into the main repo
>      - pros: no more conundrum, built by default, easier to maintain
>      - cons: makes the repo even bigger, binds the lifecycle of the CCS
> to Infinispan's
> 2) extend the server to be able to interpret the CCS schema but not
> actually depend on its code and provide the code to instantiate the CCS
> as an overlay module which can be installed on server
>      - pros: keeps the lifecycle of the CCS independent
>      - cons: additional complexity to handle the split, forces us to
> still keep server aligned with schema changes in the CCS itself.
> 3) make the CCS a deployable cache store
>      - pros: easiest
>      - cons: not really ootb experience, no nice schema
> 4) create a dedicated subsystem for the CCS and "invent" a way to
> reference it from the main Infinispan subsystem using a naming
> convention, similar to how datasources are currently implemented.
>      - pros: keeps the two projects independent, reusable for other
> Cachestores
>      - cons: writing a subsystem from scratch is complex (although bits
> of it could be made reusable for multiple cachestores).
>
> Your thoughts please.
>
> Tristan


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From ttarrant at redhat.com  Mon Jan 25 09:42:20 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 Jan 2016 15:42:20 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <56A6339D.2030502@redhat.com>
References: <56A6232A.4060402@redhat.com> <56A6339D.2030502@redhat.com>
Message-ID: <56A6344C.3080400@redhat.com>

Yes, that would be nice.

I found another "cons" for #4: an embedded config would not translate 
1:1 to server. Well, it doesn't translate directly now either, but at 
least it's "closer".

Tristan

On 25/01/2016 15:39, Radim Vansa wrote:
> Would the deployable cache stores benefit from 4) as well? It seems to
> me as the only 'right' option.
>
> R.
>
> On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
>> Hi all,
>>
>> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
>> which, as you all will remember, was pushed to an external repository
>> where it lay in abandonment ever since.
>>
>> We now need to add support for this store to Infinispan Server, but
>> unfortunately, because of the "monolithic schema" approach that WildFly
>> imposes on subsystems, this has to be done within the Infinispan
>> subsystem itself.
>> This creates a conundrum, since the CCS depends on Infinispan core,
>> server would depend on the CCS but server is part of the Infinispan build.
>>
>> Possible solutions:
>> 1) move the CCS back into the main repo
>>       - pros: no more conundrum, built by default, easier to maintain
>>       - cons: makes the repo even bigger, binds the lifecycle of the CCS
>> to Infinispan's
>> 2) extend the server to be able to interpret the CCS schema but not
>> actually depend on its code and provide the code to instantiate the CCS
>> as an overlay module which can be installed on server
>>       - pros: keeps the lifecycle of the CCS independent
>>       - cons: additional complexity to handle the split, forces us to
>> still keep server aligned with schema changes in the CCS itself.
>> 3) make the CCS a deployable cache store
>>       - pros: easiest
>>       - cons: not really ootb experience, no nice schema
>> 4) create a dedicated subsystem for the CCS and "invent" a way to
>> reference it from the main Infinispan subsystem using a naming
>> convention, similar to how datasources are currently implemented.
>>       - pros: keeps the two projects independent, reusable for other
>> Cachestores
>>       - cons: writing a subsystem from scratch is complex (although bits
>> of it could be made reusable for multiple cachestores).
>>
>> Your thoughts please.
>>
>> Tristan
>
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From slaskawi at redhat.com  Mon Jan 25 10:01:20 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 25 Jan 2016 16:01:20 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <56A6344C.3080400@redhat.com>
References: <56A6232A.4060402@redhat.com> <56A6339D.2030502@redhat.com>
	<56A6344C.3080400@redhat.com>
Message-ID: <CAA9R9O5ZUTyXdDgdXCbiAc0sYbgDL-GEnomZpjvn3O9dxV9-aA@mail.gmail.com>

Is it possible to have #3 and use a dedicated configuration schema per
Cache Store? Otherwise the only way to configure a Cache Store it to use
properties (key/value pairs).

If it's not possible to have a custom configuration schema - I would vote
for #4.

On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Yes, that would be nice.
>
> I found another "cons" for #4: an embedded config would not translate
> 1:1 to server. Well, it doesn't translate directly now either, but at
> least it's "closer".
>
> Tristan
>
> On 25/01/2016 15:39, Radim Vansa wrote:
> > Would the deployable cache stores benefit from 4) as well? It seems to
> > me as the only 'right' option.
> >
> > R.
> >
> > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> >> Hi all,
> >>
> >> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
> >> which, as you all will remember, was pushed to an external repository
> >> where it lay in abandonment ever since.
> >>
> >> We now need to add support for this store to Infinispan Server, but
> >> unfortunately, because of the "monolithic schema" approach that WildFly
> >> imposes on subsystems, this has to be done within the Infinispan
> >> subsystem itself.
> >> This creates a conundrum, since the CCS depends on Infinispan core,
> >> server would depend on the CCS but server is part of the Infinispan
> build.
> >>
> >> Possible solutions:
> >> 1) move the CCS back into the main repo
> >>       - pros: no more conundrum, built by default, easier to maintain
> >>       - cons: makes the repo even bigger, binds the lifecycle of the CCS
> >> to Infinispan's
> >> 2) extend the server to be able to interpret the CCS schema but not
> >> actually depend on its code and provide the code to instantiate the CCS
> >> as an overlay module which can be installed on server
> >>       - pros: keeps the lifecycle of the CCS independent
> >>       - cons: additional complexity to handle the split, forces us to
> >> still keep server aligned with schema changes in the CCS itself.
> >> 3) make the CCS a deployable cache store
> >>       - pros: easiest
> >>       - cons: not really ootb experience, no nice schema
> >> 4) create a dedicated subsystem for the CCS and "invent" a way to
> >> reference it from the main Infinispan subsystem using a naming
> >> convention, similar to how datasources are currently implemented.
> >>       - pros: keeps the two projects independent, reusable for other
> >> Cachestores
> >>       - cons: writing a subsystem from scratch is complex (although bits
> >> of it could be made reusable for multiple cachestores).
> >>
> >> Your thoughts please.
> >>
> >> Tristan
> >
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160125/f5bcf7f6/attachment.html 

From slaskawi at redhat.com  Mon Jan 25 10:09:04 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 25 Jan 2016 16:09:04 +0100
Subject: [infinispan-dev] jdk8backported package
In-Reply-To: <CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
References: <56976B94.9010704@redhat.com>
	<CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
Message-ID: <CAA9R9O5JVYyWgEWJi_h=SDpt=Cic6rDmQNGJGAZjqBK66abEig@mail.gmail.com>

Would it be possible to decouple Map implementation from our custom code
(like eviction policy or setting max size)? Or the dependency between those
two is too strong?

On Mon, Jan 25, 2016 at 3:15 PM, William Burns <mudokonman at gmail.com> wrote:

> Unfortunately this isn't really possible to remove these classes.  They
> have additional changes over and above the jdk8 classes.  We could move it
> into a different package though if we wanted to.
>
> To be honest the only reason this is still really needed is for the
> BoundedConcurrentHashMapV8.  I have been talking with Dan on and off for a
> while about even possibly looking into using a different map implementation
> (such as caffeine or something else equivalent).  We haven't looked into it
> very seriously though.
>
> We could look into this more if people think we want to tackle that.
>
>  - Will
>
> On Thu, Jan 14, 2016 at 4:34 AM Radim Vansa <rvansa at redhat.com> wrote:
>
>> Hi,
>>
>> although we're on Java 8, there's still the package
>> org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
>> possibility) to remove these and use implementation provided by runtime?
>> Or have we tweaked them too much, so shall we rather rename them?
>>
>> Radim
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160125/cb044e82/attachment-0001.html 

From ttarrant at redhat.com  Mon Jan 25 10:52:08 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 Jan 2016 16:52:08 +0100
Subject: [infinispan-dev] Weekly IRC meeting logs 2016-01-25
Message-ID: <56A644A8.1010309@redhat.com>

Hi all,

get the meeting logs from here:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-25-15.02.log.html

Cheers

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From ttarrant at redhat.com  Mon Jan 25 11:44:30 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 25 Jan 2016 17:44:30 +0100
Subject: [infinispan-dev] Infinispan Cache Store Failure Detection and
 Recovery
In-Reply-To: <CAAGUZXAkdEh17EKaz=rytTA0f6-EzChWWvkM1USFsZORswLrbA@mail.gmail.com>
References: <CAAGUZXAkdEh17EKaz=rytTA0f6-EzChWWvkM1USFsZORswLrbA@mail.gmail.com>
Message-ID: <56A650EE.3040104@redhat.com>

Hi Cosmin,

sorry for the delay.
Yes, the correct approach would be to implement some kind of 
"UnreliableCacheReader/Writer" as a wrapper to a concrete Cache Store, 
which would ignore any errors in the underlying store. This wrapper 
would also probably implement some kind of fail-fast mechanism so that 
it would only retry going to a failing store after a certain time has 
elapsed, to avoid unnecessary repeat failures.

I have created [1] to track this, so please let's add any concerns/ideas 
to that.

Tristan

[1] https://issues.jboss.org/browse/ISPN-6097

On 19/01/2016 18:32, Cosmin Stroe wrote:
> Hello everyone,
>
> We're setting up an Infinispan deployment for a web application.  Our
> use case includes a local Infinispan cache (running in the same JVM as
> the web app) backed by a remote Infinispan cache (running in a separate
> JVM).
>
> We have to investigate failure modes of said cache.  One of the
> scenarios we have to handle is "What happens if the remote Infinispan
> cache goes away?".  This could happen for various reasons, including if
> we restart the remote Infinispan cache.  We would like to have some
> known state during remote cache outages (which we hope would happen very
> infrequently).
>
> My conversation with "ttarrant" on Freenode led us to believe that
> Infinispan doesn't currently have any failure mode handling built in,
> and that it's possible that we could make the Async Store decorator
> optionally be able to "resist" store failures.  Not sure what other
> options we have.
>
> The correct answer might also be, "Just have the cache return null if an
> entry is not in the local cache and the remote cache is unresponsive,
> and have the application gracefully handle the empty cache".  I'm not
> sure if that option can be implemented with the current Infinispan code.
>
> Any thoughts on this?
> Cosmin.
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From mudokonman at gmail.com  Mon Jan 25 15:16:19 2016
From: mudokonman at gmail.com (William Burns)
Date: Mon, 25 Jan 2016 20:16:19 +0000
Subject: [infinispan-dev] jdk8backported package
In-Reply-To: <CAFm4XO3RMyZorf8bBKD6TQK+KHdaK4kfysxzBp=1J12cEzUezA@mail.gmail.com>
References: <56976B94.9010704@redhat.com>
	<CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
	<CAFm4XO3RMyZorf8bBKD6TQK+KHdaK4kfysxzBp=1J12cEzUezA@mail.gmail.com>
Message-ID: <CA+YCuUPkLz1P2ie4px3uANH-9foZCzf1jVWJJwT8Ofxjso0NpA@mail.gmail.com>

On Mon, Jan 25, 2016 at 9:24 AM Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 25 January 2016 at 14:15, William Burns <mudokonman at gmail.com> wrote:
> > Unfortunately this isn't really possible to remove these classes.  They
> have
> > additional changes over and above the jdk8 classes.  We could move it
> into a
> > different package though if we wanted to.
>
> +1 to change package: I have been confused about this too in the recent
> past.
>

I am guessing we can just put these in the concurrent package 1 below?
WDYT?


>
> >
> > To be honest the only reason this is still really needed is for the
> > BoundedConcurrentHashMapV8.  I have been talking with Dan on and off for
> a
> > while about even possibly looking into using a different map
> implementation
> > (such as caffeine or something else equivalent).  We haven't looked into
> it
> > very seriously though.
>
> Could you remove the other ones which are no longer needed?
>

There is only one class that can be really removed and that is once M/R is
removed I believe (ConcurrentParallelHashMapV8).


>
> >
> > We could look into this more if people think we want to tackle that.
> >
> >  - Will
> >
> > On Thu, Jan 14, 2016 at 4:34 AM Radim Vansa <rvansa at redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> although we're on Java 8, there's still the package
> >> org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
> >> possibility) to remove these and use implementation provided by runtime?
> >> Or have we tweaked them too much, so shall we rather rename them?
> >>
> >> Radim
> >>
> >> --
> >> Radim Vansa <rvansa at redhat.com>
> >> JBoss Performance Team
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160125/1e74db79/attachment.html 

From mudokonman at gmail.com  Mon Jan 25 15:18:27 2016
From: mudokonman at gmail.com (William Burns)
Date: Mon, 25 Jan 2016 20:18:27 +0000
Subject: [infinispan-dev] jdk8backported package
In-Reply-To: <CAA9R9O5JVYyWgEWJi_h=SDpt=Cic6rDmQNGJGAZjqBK66abEig@mail.gmail.com>
References: <56976B94.9010704@redhat.com>
	<CA+YCuUNV+BLiLKHuym+O8ftSVwE93bQoAwFiMQ1RAK9=P0CUJg@mail.gmail.com>
	<CAA9R9O5JVYyWgEWJi_h=SDpt=Cic6rDmQNGJGAZjqBK66abEig@mail.gmail.com>
Message-ID: <CA+YCuUMZ-3_d7o9MNyofo3EoYkbJDXJRUU8svnEm3qupJbZ63Q@mail.gmail.com>

On Mon, Jan 25, 2016 at 10:09 AM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Would it be possible to decouple Map implementation from our custom code
> (like eviction policy or setting max size)? Or the dependency between those
> two is too strong?
>

This is possible.  I had already thought of doing that at some point, but
haven't been able to look into it or have a great reason yet (we lose some
stuff like better size estimations - since we have access to the underlying
array).

Unfortunately the equivalent versions have to stay even if we remove the
eviction stuff, since there is no pluggable way to do this with the JVM
classes.


>
> On Mon, Jan 25, 2016 at 3:15 PM, William Burns <mudokonman at gmail.com>
> wrote:
>
>> Unfortunately this isn't really possible to remove these classes.  They
>> have additional changes over and above the jdk8 classes.  We could move it
>> into a different package though if we wanted to.
>>
>> To be honest the only reason this is still really needed is for the
>> BoundedConcurrentHashMapV8.  I have been talking with Dan on and off for a
>> while about even possibly looking into using a different map implementation
>> (such as caffeine or something else equivalent).  We haven't looked into it
>> very seriously though.
>>
>> We could look into this more if people think we want to tackle that.
>>
>>  - Will
>>
>> On Thu, Jan 14, 2016 at 4:34 AM Radim Vansa <rvansa at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> although we're on Java 8, there's still the package
>>> org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
>>> possibility) to remove these and use implementation provided by runtime?
>>> Or have we tweaked them too much, so shall we rather rename them?
>>>
>>> Radim
>>>
>>> --
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160125/30a4997f/attachment.html 

From ttarrant at redhat.com  Tue Jan 26 03:17:47 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 26 Jan 2016 09:17:47 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <CAA9R9O5ZUTyXdDgdXCbiAc0sYbgDL-GEnomZpjvn3O9dxV9-aA@mail.gmail.com>
References: <56A6232A.4060402@redhat.com> <56A6339D.2030502@redhat.com>
	<56A6344C.3080400@redhat.com>
	<CAA9R9O5ZUTyXdDgdXCbiAc0sYbgDL-GEnomZpjvn3O9dxV9-aA@mail.gmail.com>
Message-ID: <56A72BAB.5050301@redhat.com>

So let's see what an implementation of #4 would entail:


A mini-subsystem per cache-store which can parse the following:

<subsystem xmlns="urn:infinispan:server:cachestore:cassandra:8.2">
   <cassandra-store name="mycassandrastore"
                    auto-create-keyspace="true" keyspace="TestKeyspace"
                    entry-table="TestEntryTable"
                    consistency-level="LOCAL_ONE"
                    serial-consistency-level="SERIAL">
     <cassandra-server host="127.0.0.1" port="9042" />
     <cassandra-server host="127.0.0.1" port="9041" />
     <connection-pool heartbeat-interval-seconds="30"
                      idle-timeout-seconds="120"
                      pool-timeout-millis="5" />
   </cassandra-store>
</subsystem>

The subsystem would be responsible for parsing the configuration and 
registering an appropriate StoreConfigurationBuilder under a named 
Service within the server. We need to be careful about class loader 
visibility, but the datasource subsystem does something similar, so it 
should be possible.

The main Infinispan subsystem would need to be extended to be able to 
parse the following (simplified):

<subsystem xmlns="urn:infinispan:server:core:8.2">
   <cache-container name="clustered">
     <distributed-cache name="default">
       <store ref="infinispan/cachestore/cassandra/mycassandrastore"
              passivation="true" fetch-state="true" preload="true"
              purge="false" />
     </distributed-cache>
   </cache-container>
</subsystem>

It would also not be difficult, for symmetry, to support a compatible 
schema for the embedded use-case.

The cachestores would be distributed both as a simple jar for embedded 
use-cases and as a zip containing the necessary modules for server.
Note that this would not leverage the deployable cachestores machinery 
as subsystems need to be installed as modules.

Tristan


On 25/01/2016 16:01, Sebastian Laskawiec wrote:
> Is it possible to have #3 and use a dedicated configuration schema per
> Cache Store? Otherwise the only way to configure a Cache Store it to use
> properties (key/value pairs).
>
> If it's not possible to have a custom configuration schema - I would
> vote for #4.
>
> On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>> wrote:
>
>     Yes, that would be nice.
>
>     I found another "cons" for #4: an embedded config would not translate
>     1:1 to server. Well, it doesn't translate directly now either, but at
>     least it's "closer".
>
>     Tristan
>
>     On 25/01/2016 15:39, Radim Vansa wrote:
>      > Would the deployable cache stores benefit from 4) as well? It
>     seems to
>      > me as the only 'right' option.
>      >
>      > R.
>      >
>      > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
>      >> Hi all,
>      >>
>      >> Jakub has recently revived the Cassandra Cache Store (CCS from
>     now on)
>      >> which, as you all will remember, was pushed to an external
>     repository
>      >> where it lay in abandonment ever since.
>      >>
>      >> We now need to add support for this store to Infinispan Server, but
>      >> unfortunately, because of the "monolithic schema" approach that
>     WildFly
>      >> imposes on subsystems, this has to be done within the Infinispan
>      >> subsystem itself.
>      >> This creates a conundrum, since the CCS depends on Infinispan core,
>      >> server would depend on the CCS but server is part of the
>     Infinispan build.
>      >>
>      >> Possible solutions:
>      >> 1) move the CCS back into the main repo
>      >>       - pros: no more conundrum, built by default, easier to
>     maintain
>      >>       - cons: makes the repo even bigger, binds the lifecycle of
>     the CCS
>      >> to Infinispan's
>      >> 2) extend the server to be able to interpret the CCS schema but not
>      >> actually depend on its code and provide the code to instantiate
>     the CCS
>      >> as an overlay module which can be installed on server
>      >>       - pros: keeps the lifecycle of the CCS independent
>      >>       - cons: additional complexity to handle the split, forces
>     us to
>      >> still keep server aligned with schema changes in the CCS itself.
>      >> 3) make the CCS a deployable cache store
>      >>       - pros: easiest
>      >>       - cons: not really ootb experience, no nice schema
>      >> 4) create a dedicated subsystem for the CCS and "invent" a way to
>      >> reference it from the main Infinispan subsystem using a naming
>      >> convention, similar to how datasources are currently implemented.
>      >>       - pros: keeps the two projects independent, reusable for other
>      >> Cachestores
>      >>       - cons: writing a subsystem from scratch is complex
>     (although bits
>      >> of it could be made reusable for multiple cachestores).
>      >>
>      >> Your thoughts please.
>      >>
>      >> Tristan
>      >
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto: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
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From anistor at redhat.com  Tue Jan 26 07:56:21 2016
From: anistor at redhat.com (Adrian Nistor)
Date: Tue, 26 Jan 2016 14:56:21 +0200
Subject: [infinispan-dev] Weekly IRC meeting logs 2016-01-25
In-Reply-To: <56A644A8.1010309@redhat.com>
References: <56A644A8.1010309@redhat.com>
Message-ID: <56A76CF5.4020300@redhat.com>

Hi All,

Here's my update. Last week I worked on query related docs; first PR is 
here [1]. This one is just about aggregations but there is more coming 
on continuous query and dsl based event filters. I felt blogging about 
it is completely inappropriate at this stage since docs are very scarce.

Another thing I'm working on is fixing some small design errors in the 
query DSL (org.infinispan.query.dsl.*) to have better type safety and 
ensure some aspects of query correctness right from construction time, 
PR coming soon. These need to be fixed in 8.2, one of them is [2], 
please have a look.

This week I'm planning to fill all the blanks in the query user guide 
and then write a short blog about the new additions.

Cheers!

[1] https://github.com/infinispan/infinispan/pull/3954
[2] https://github.com/infinispan/infinispan/pull/3936

On 01/25/2016 05:52 PM, Tristan Tarrant wrote:
> Hi all,
>
> get the meeting logs from here:
>
> http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-25-15.02.log.html
>
> Cheers
>
> Tristan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160126/9e4d6ea5/attachment.html 

From sanne at infinispan.org  Tue Jan 26 10:31:41 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 26 Jan 2016 15:31:41 +0000
Subject: [infinispan-dev] Weekly IRC meeting logs 2016-01-25
In-Reply-To: <56A76CF5.4020300@redhat.com>
References: <56A644A8.1010309@redhat.com> <56A76CF5.4020300@redhat.com>
Message-ID: <CAFm4XO2xD+768pS5KTGiPkBDOL16KaxgcKN-6VwFsQ35-VeGUQ@mail.gmail.com>

Very nice improvements!

Thanks,
Sanne

On 26 January 2016 at 12:56, Adrian Nistor <anistor at redhat.com> wrote:
> Hi All,
>
> Here's my update. Last week I worked on query related docs; first PR is here
> [1]. This one is just about aggregations but there is more coming on
> continuous query and dsl based event filters. I felt blogging about it is
> completely inappropriate at this stage since docs are very scarce.
>
> Another thing I'm working on is fixing some small design errors in the query
> DSL (org.infinispan.query.dsl.*) to have better type safety and ensure some
> aspects of query correctness right from construction time, PR coming soon.
> These need to be fixed in 8.2, one of them is [2], please have a look.
>
> This week I'm planning to fill all the blanks in the query user guide and
> then write a short blog about the new additions.
>
> Cheers!
>
> [1] https://github.com/infinispan/infinispan/pull/3954
> [2] https://github.com/infinispan/infinispan/pull/3936
>
> On 01/25/2016 05:52 PM, Tristan Tarrant wrote:
>
> Hi all,
>
> get the meeting logs from here:
>
> http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-25-15.02.log.html
>
> Cheers
>
> Tristan
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From slaskawi at redhat.com  Tue Jan 26 10:46:18 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 26 Jan 2016 16:46:18 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <56A72BAB.5050301@redhat.com>
References: <56A6232A.4060402@redhat.com> <56A6339D.2030502@redhat.com>
	<56A6344C.3080400@redhat.com>
	<CAA9R9O5ZUTyXdDgdXCbiAc0sYbgDL-GEnomZpjvn3O9dxV9-aA@mail.gmail.com>
	<56A72BAB.5050301@redhat.com>
Message-ID: <CAA9R9O4tKFr8YTW4n7Ne2NFqrL08Bv=LVnJyd5HtVNaPc=3jRw@mail.gmail.com>

Thanks for the explanation Tristan! Great example!

Following our discussion on IRC - would it make sense to make this
refactoring a bit broader and take Marshallers/Filter/Converters into
consideration (we don't need to implement everything in a single step...
just get the big pictures how all those pieces combine together)?

On Tue, Jan 26, 2016 at 9:17 AM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> So let's see what an implementation of #4 would entail:
>
>
> A mini-subsystem per cache-store which can parse the following:
>
> <subsystem xmlns="urn:infinispan:server:cachestore:cassandra:8.2">
>    <cassandra-store name="mycassandrastore"
>                     auto-create-keyspace="true" keyspace="TestKeyspace"
>                     entry-table="TestEntryTable"
>                     consistency-level="LOCAL_ONE"
>                     serial-consistency-level="SERIAL">
>      <cassandra-server host="127.0.0.1" port="9042" />
>      <cassandra-server host="127.0.0.1" port="9041" />
>      <connection-pool heartbeat-interval-seconds="30"
>                       idle-timeout-seconds="120"
>                       pool-timeout-millis="5" />
>    </cassandra-store>
> </subsystem>
>
> The subsystem would be responsible for parsing the configuration and
> registering an appropriate StoreConfigurationBuilder under a named
> Service within the server. We need to be careful about class loader
> visibility, but the datasource subsystem does something similar, so it
> should be possible.
>
> The main Infinispan subsystem would need to be extended to be able to
> parse the following (simplified):
>
> <subsystem xmlns="urn:infinispan:server:core:8.2">
>    <cache-container name="clustered">
>      <distributed-cache name="default">
>        <store ref="infinispan/cachestore/cassandra/mycassandrastore"
>               passivation="true" fetch-state="true" preload="true"
>               purge="false" />
>      </distributed-cache>
>    </cache-container>
> </subsystem>
>
> It would also not be difficult, for symmetry, to support a compatible
> schema for the embedded use-case.
>
> The cachestores would be distributed both as a simple jar for embedded
> use-cases and as a zip containing the necessary modules for server.
> Note that this would not leverage the deployable cachestores machinery
> as subsystems need to be installed as modules.
>
> Tristan
>
>
> On 25/01/2016 16:01, Sebastian Laskawiec wrote:
> > Is it possible to have #3 and use a dedicated configuration schema per
> > Cache Store? Otherwise the only way to configure a Cache Store it to use
> > properties (key/value pairs).
> >
> > If it's not possible to have a custom configuration schema - I would
> > vote for #4.
> >
> > On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com
> > <mailto:ttarrant at redhat.com>> wrote:
> >
> >     Yes, that would be nice.
> >
> >     I found another "cons" for #4: an embedded config would not translate
> >     1:1 to server. Well, it doesn't translate directly now either, but at
> >     least it's "closer".
> >
> >     Tristan
> >
> >     On 25/01/2016 15:39, Radim Vansa wrote:
> >      > Would the deployable cache stores benefit from 4) as well? It
> >     seems to
> >      > me as the only 'right' option.
> >      >
> >      > R.
> >      >
> >      > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> >      >> Hi all,
> >      >>
> >      >> Jakub has recently revived the Cassandra Cache Store (CCS from
> >     now on)
> >      >> which, as you all will remember, was pushed to an external
> >     repository
> >      >> where it lay in abandonment ever since.
> >      >>
> >      >> We now need to add support for this store to Infinispan Server,
> but
> >      >> unfortunately, because of the "monolithic schema" approach that
> >     WildFly
> >      >> imposes on subsystems, this has to be done within the Infinispan
> >      >> subsystem itself.
> >      >> This creates a conundrum, since the CCS depends on Infinispan
> core,
> >      >> server would depend on the CCS but server is part of the
> >     Infinispan build.
> >      >>
> >      >> Possible solutions:
> >      >> 1) move the CCS back into the main repo
> >      >>       - pros: no more conundrum, built by default, easier to
> >     maintain
> >      >>       - cons: makes the repo even bigger, binds the lifecycle of
> >     the CCS
> >      >> to Infinispan's
> >      >> 2) extend the server to be able to interpret the CCS schema but
> not
> >      >> actually depend on its code and provide the code to instantiate
> >     the CCS
> >      >> as an overlay module which can be installed on server
> >      >>       - pros: keeps the lifecycle of the CCS independent
> >      >>       - cons: additional complexity to handle the split, forces
> >     us to
> >      >> still keep server aligned with schema changes in the CCS itself.
> >      >> 3) make the CCS a deployable cache store
> >      >>       - pros: easiest
> >      >>       - cons: not really ootb experience, no nice schema
> >      >> 4) create a dedicated subsystem for the CCS and "invent" a way to
> >      >> reference it from the main Infinispan subsystem using a naming
> >      >> convention, similar to how datasources are currently implemented.
> >      >>       - pros: keeps the two projects independent, reusable for
> other
> >      >> Cachestores
> >      >>       - cons: writing a subsystem from scratch is complex
> >     (although bits
> >      >> of it could be made reusable for multiple cachestores).
> >      >>
> >      >> Your thoughts please.
> >      >>
> >      >> Tristan
> >      >
> >      >
> >
> >     --
> >     Tristan Tarrant
> >     Infinispan Lead
> >     JBoss, a division of Red Hat
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> 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
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160126/f6cc7585/attachment.html 

From ttarrant at redhat.com  Tue Jan 26 10:50:30 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 26 Jan 2016 16:50:30 +0100
Subject: [infinispan-dev] (Not-so-)optional cachestores
In-Reply-To: <CAA9R9O4tKFr8YTW4n7Ne2NFqrL08Bv=LVnJyd5HtVNaPc=3jRw@mail.gmail.com>
References: <56A6232A.4060402@redhat.com> <56A6339D.2030502@redhat.com>
	<56A6344C.3080400@redhat.com>
	<CAA9R9O5ZUTyXdDgdXCbiAc0sYbgDL-GEnomZpjvn3O9dxV9-aA@mail.gmail.com>
	<56A72BAB.5050301@redhat.com>
	<CAA9R9O4tKFr8YTW4n7Ne2NFqrL08Bv=LVnJyd5HtVNaPc=3jRw@mail.gmail.com>
Message-ID: <56A795C6.9030008@redhat.com>

Actually, after our IRC dicussions, I've come to think that 
marshallers/filters/converters are different from a cachestore because 
they don't need to be configured, so not sure how far we should take it.

Tristan

On 26/01/2016 16:46, Sebastian Laskawiec wrote:
> Thanks for the explanation Tristan! Great example!
>
> Following our discussion on IRC - would it make sense to make this
> refactoring a bit broader and take Marshallers/Filter/Converters into
> consideration (we don't need to implement everything in a single step...
> just get the big pictures how all those pieces combine together)?
>
> On Tue, Jan 26, 2016 at 9:17 AM, Tristan Tarrant <ttarrant at redhat.com
> <mailto:ttarrant at redhat.com>> wrote:
>
>     So let's see what an implementation of #4 would entail:
>
>
>     A mini-subsystem per cache-store which can parse the following:
>
>     <subsystem xmlns="urn:infinispan:server:cachestore:cassandra:8.2">
>         <cassandra-store name="mycassandrastore"
>                          auto-create-keyspace="true" keyspace="TestKeyspace"
>                          entry-table="TestEntryTable"
>                          consistency-level="LOCAL_ONE"
>                          serial-consistency-level="SERIAL">
>           <cassandra-server host="127.0.0.1" port="9042" />
>           <cassandra-server host="127.0.0.1" port="9041" />
>           <connection-pool heartbeat-interval-seconds="30"
>                            idle-timeout-seconds="120"
>                            pool-timeout-millis="5" />
>         </cassandra-store>
>     </subsystem>
>
>     The subsystem would be responsible for parsing the configuration and
>     registering an appropriate StoreConfigurationBuilder under a named
>     Service within the server. We need to be careful about class loader
>     visibility, but the datasource subsystem does something similar, so it
>     should be possible.
>
>     The main Infinispan subsystem would need to be extended to be able to
>     parse the following (simplified):
>
>     <subsystem xmlns="urn:infinispan:server:core:8.2">
>         <cache-container name="clustered">
>           <distributed-cache name="default">
>             <store ref="infinispan/cachestore/cassandra/mycassandrastore"
>                    passivation="true" fetch-state="true" preload="true"
>                    purge="false" />
>           </distributed-cache>
>         </cache-container>
>     </subsystem>
>
>     It would also not be difficult, for symmetry, to support a compatible
>     schema for the embedded use-case.
>
>     The cachestores would be distributed both as a simple jar for embedded
>     use-cases and as a zip containing the necessary modules for server.
>     Note that this would not leverage the deployable cachestores machinery
>     as subsystems need to be installed as modules.
>
>     Tristan
>
>
>     On 25/01/2016 16:01, Sebastian Laskawiec wrote:
>     > Is it possible to have #3 and use a dedicated configuration schema per
>     > Cache Store? Otherwise the only way to configure a Cache Store it to use
>     > properties (key/value pairs).
>     >
>     > If it's not possible to have a custom configuration schema - I would
>     > vote for #4.
>     >
>     > On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com <mailto:ttarrant at redhat.com>
>      > <mailto:ttarrant at redhat.com <mailto:ttarrant at redhat.com>>> wrote:
>      >
>      >     Yes, that would be nice.
>      >
>      >     I found another "cons" for #4: an embedded config would not
>     translate
>      >     1:1 to server. Well, it doesn't translate directly now
>     either, but at
>      >     least it's "closer".
>      >
>      >     Tristan
>      >
>      >     On 25/01/2016 15:39, Radim Vansa wrote:
>      >      > Would the deployable cache stores benefit from 4) as well? It
>      >     seems to
>      >      > me as the only 'right' option.
>      >      >
>      >      > R.
>      >      >
>      >      > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
>      >      >> Hi all,
>      >      >>
>      >      >> Jakub has recently revived the Cassandra Cache Store (CCS
>     from
>      >     now on)
>      >      >> which, as you all will remember, was pushed to an external
>      >     repository
>      >      >> where it lay in abandonment ever since.
>      >      >>
>      >      >> We now need to add support for this store to Infinispan
>     Server, but
>      >      >> unfortunately, because of the "monolithic schema"
>     approach that
>      >     WildFly
>      >      >> imposes on subsystems, this has to be done within the
>     Infinispan
>      >      >> subsystem itself.
>      >      >> This creates a conundrum, since the CCS depends on
>     Infinispan core,
>      >      >> server would depend on the CCS but server is part of the
>      >     Infinispan build.
>      >      >>
>      >      >> Possible solutions:
>      >      >> 1) move the CCS back into the main repo
>      >      >>       - pros: no more conundrum, built by default, easier to
>      >     maintain
>      >      >>       - cons: makes the repo even bigger, binds the
>     lifecycle of
>      >     the CCS
>      >      >> to Infinispan's
>      >      >> 2) extend the server to be able to interpret the CCS
>     schema but not
>      >      >> actually depend on its code and provide the code to
>     instantiate
>      >     the CCS
>      >      >> as an overlay module which can be installed on server
>      >      >>       - pros: keeps the lifecycle of the CCS independent
>      >      >>       - cons: additional complexity to handle the split,
>     forces
>      >     us to
>      >      >> still keep server aligned with schema changes in the CCS
>     itself.
>      >      >> 3) make the CCS a deployable cache store
>      >      >>       - pros: easiest
>      >      >>       - cons: not really ootb experience, no nice schema
>      >      >> 4) create a dedicated subsystem for the CCS and "invent"
>     a way to
>      >      >> reference it from the main Infinispan subsystem using a
>     naming
>      >      >> convention, similar to how datasources are currently
>     implemented.
>      >      >>       - pros: keeps the two projects independent,
>     reusable for other
>      >      >> Cachestores
>      >      >>       - cons: writing a subsystem from scratch is complex
>      >     (although bits
>      >      >> of it could be made reusable for multiple cachestores).
>      >      >>
>      >      >> Your thoughts please.
>      >      >>
>      >      >> Tristan
>      >      >
>      >      >
>      >
>      >     --
>      >     Tristan Tarrant
>      >     Infinispan Lead
>      >     JBoss, a division of Red Hat
>      >     _______________________________________________
>      >     infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     <mailto:infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto: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
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From sanne at infinispan.org  Wed Jan 27 11:41:25 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 27 Jan 2016 16:41:25 +0000
Subject: [infinispan-dev] Runtime.onSpinWait()
Message-ID: <CAFm4XO0fcKiCKxK+FJRn_+spV3Mq0_HmkpB1mDK4_Yu34houFg@mail.gmail.com>

Hello all,
I've been following the discussion about onSpinWait(), it seems JDK9
might get it.

That looks quite interesting, especially after having noticed that
sometimes we "burn CPU" while we could hint that the thread should
rather be descheduled.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038361.html

Thanks,
Sanne

From dan.berindei at gmail.com  Wed Jan 27 14:50:52 2016
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 27 Jan 2016 21:50:52 +0200
Subject: [infinispan-dev] Runtime.onSpinWait()
In-Reply-To: <CAFm4XO0fcKiCKxK+FJRn_+spV3Mq0_HmkpB1mDK4_Yu34houFg@mail.gmail.com>
References: <CAFm4XO0fcKiCKxK+FJRn_+spV3Mq0_HmkpB1mDK4_Yu34houFg@mail.gmail.com>
Message-ID: <CA+nfvwRPVLPTNPqBnwESbdtE77zc4Ug8cz+PFeb3vFz8xF_hVg@mail.gmail.com>

Any idea how HotSpot would optimize spin-waiting? The patch contains
just the method definition...

Cheers
Dan


On Wed, Jan 27, 2016 at 6:41 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> Hello all,
> I've been following the discussion about onSpinWait(), it seems JDK9
> might get it.
>
> That looks quite interesting, especially after having noticed that
> sometimes we "burn CPU" while we could hint that the thread should
> rather be descheduled.
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038361.html
>
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From lthon at redhat.com  Thu Jan 28 02:04:49 2016
From: lthon at redhat.com (Ladislav Thon)
Date: Thu, 28 Jan 2016 08:04:49 +0100
Subject: [infinispan-dev] Runtime.onSpinWait()
In-Reply-To: <CA+nfvwRPVLPTNPqBnwESbdtE77zc4Ug8cz+PFeb3vFz8xF_hVg@mail.gmail.com>
References: <CAFm4XO0fcKiCKxK+FJRn_+spV3Mq0_HmkpB1mDK4_Yu34houFg@mail.gmail.com>
	<CA+nfvwRPVLPTNPqBnwESbdtE77zc4Ug8cz+PFeb3vFz8xF_hVg@mail.gmail.com>
Message-ID: <56A9BD91.2@redhat.com>

> Any idea how HotSpot would optimize spin-waiting? The patch contains
> just the method definition...

IIUC, it's supposed to emit the PAUSE instruction on x86; can be a noop
(or any other architecture-specific insn) on other architectures.

LT

> 
> Cheers
> Dan
> 
> 
> On Wed, Jan 27, 2016 at 6:41 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> Hello all,
>> I've been following the discussion about onSpinWait(), it seems JDK9
>> might get it.
>>
>> That looks quite interesting, especially after having noticed that
>> sometimes we "burn CPU" while we could hint that the thread should
>> rather be descheduled.
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038361.html
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> 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
> 


From sanne at infinispan.org  Thu Jan 28 05:47:26 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 28 Jan 2016 10:47:26 +0000
Subject: [infinispan-dev] Runtime.onSpinWait()
In-Reply-To: <56A9BD91.2@redhat.com>
References: <CAFm4XO0fcKiCKxK+FJRn_+spV3Mq0_HmkpB1mDK4_Yu34houFg@mail.gmail.com>
	<CA+nfvwRPVLPTNPqBnwESbdtE77zc4Ug8cz+PFeb3vFz8xF_hVg@mail.gmail.com>
	<56A9BD91.2@redhat.com>
Message-ID: <CAFm4XO2VQw+N1heDyuEsVTkYs8VOfUphGi3xGQAozXUgajO=AQ@mail.gmail.com>

Right, it's a PAUSE; you can follow the mailing list thread I linked
to to learn about the background.
Also Gil Tene shared a very nice project so we can all experiment with it:
 - https://github.com/giltene/GilExamples/tree/master/SpinWaitTest

The Readme file contains links to experimental OpenJDK builds
including the patch.

On 28 January 2016 at 07:04, Ladislav Thon <lthon at redhat.com> wrote:
>> Any idea how HotSpot would optimize spin-waiting? The patch contains
>> just the method definition...
>
> IIUC, it's supposed to emit the PAUSE instruction on x86; can be a noop
> (or any other architecture-specific insn) on other architectures.
>
> LT
>
>>
>> Cheers
>> Dan
>>
>>
>> On Wed, Jan 27, 2016 at 6:41 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>>> Hello all,
>>> I've been following the discussion about onSpinWait(), it seems JDK9
>>> might get it.
>>>
>>> That looks quite interesting, especially after having noticed that
>>> sometimes we "burn CPU" while we could hint that the thread should
>>> rather be descheduled.
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038361.html
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev