Thoughts?
Begin forwarded message:
From: Brian Oliver brian.oli...@oracle.com
Subject: Moving to Java 7?
Date: February 5, 2013 9:13:35 PM GMT+01:00
To: jsr...@googlegroups.com
Reply-To: jsr...@googlegroups.com
Currently we are targeting Java 7 for JSR-107.
Given that:
a). Java 6
I'm no transactions expert, but I did consider that and I highly doubt it's
that simple.
Even if it might probably just work, you'll never be able to guarantee that
such UserTransaction behaves just like You-Fav-JTATM-UserTransaction without
throrough testing.
Go to your IDE (dunno where
Voted. I love the Tactical Nuclear Penguin name :D
On Feb 7, 2013, at 12:00 PM, Manik Surtani msurt...@redhat.com wrote:
Okay, okay … enough nominations. Time to vote, people.
https://community.jboss.org/polls/1115
- M
On 7 Feb 2013, at 10:44, Tristan Tarrant ttarr...@redhat.com
I think we should definitely move to Java 7 for Infinispan 6.0.
Coincidentally, I've been packaging netty 3.6.x which needs java 7 to
build but generates Java 6-compatible bytecode using various maven
plugins to perform the magic, which could be used as an interim solution.
Tristan
On
The question is: what does 107 plan to gain from this? If that's
virtually nothing, then the move is not necessary.
Emmanuel
On Fri 2013-02-08 9:29, Galder Zamarreño wrote:
Thoughts?
Begin forwarded message:
From: Brian Oliver brian.oli...@oracle.com
Subject: Moving to Java 7?
Date:
On Feb 8, 2013, at 11:40 AM, Emmanuel Bernard emman...@hibernate.org wrote:
The question is: what does 107 plan to gain from this? If that's
virtually nothing, then the move is not necessary.
That was the overall agreement.
Emmanuel
On Fri 2013-02-08 9:29, Galder Zamarreño wrote:
On 7 Feb 2013, at 11:36, Manik Surtani wrote:
On 7 Feb 2013, at 11:29, Bela Ban b...@redhat.com wrote:
I meant to say that this is up to you guys to decide inwhich Infinispan
release this will be used, but it will be available in JGroups 3.3.
What's the strategy/schedule for 6 and 5.3
On 2/8/13 12:26 PM, Mircea Markus wrote:
On 7 Feb 2013, at 11:36, Manik Surtani wrote:
On 7 Feb 2013, at 11:29, Bela Ban b...@redhat.com
mailto:b...@redhat.com wrote:
I meant to say that this is up to you guys to decide inwhich Infinispan
release this will be used, but it will be
Hi all,
We've got a small class loading puzzle to solve in our JSR-107 implementation.
JSR-107 has a class called Caching which keeps a singleton enum reference
(AFAIK, has same semantics as static) to the systemt's CacheManagerFactory,
which in our case it would be
Hi Bela,
Alpha1 does not exist in GitHub. Instead you have 3.3.0.Alpha2 =)
So, can I start to use it?
Thanks
Pedro
On 2/8/13 2:31 PM, Bela Ban wrote:
On 2/8/13 3:23 PM, Mircea Markus wrote:
Hi Bela,
Do you think we can have this particular improvement in JGroups by 18
Feb? That week
On Fri, Feb 8, 2013 at 3:41 PM, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
We've got a small class loading puzzle to solve in our JSR-107
implementation.
JSR-107 has a class called Caching which keeps a singleton enum reference
(AFAIK, has same semantics as static) to the systemt's
On 8 Feb 2013, at 14:31, Bela Ban wrote:
On 2/8/13 3:23 PM, Mircea Markus wrote:
Hi Bela,
Do you think we can have this particular improvement in JGroups by 18
Feb? That week Pedro, Dan and I are going to start integrating TO
protocols in ISPN and this is a requirement for it.
It
Galder, the CacheManager.getUserTransaction() javadoc says the method
should return a UserTransaction. It doesn't mandate any connection with
any active TM, in fact based on this issue I think Ehcache will always
return their own UserTransaction object:
I've created a JIRA in the scope of Infinispan 5.3 to track the thread pool
improvements discussed in this email thread:
ISPN-2808 - Make Infinispan use its own thread pool for sending OOB messages in
order to avoid thread deadlocks
On 8 Feb 2013, at 14:44, Mircea Markus wrote:
On 8 Feb
yes, I mis-tagged it... :-(
On 2/8/13 3:33 PM, Pedro Ruivo wrote:
Hi Bela,
Alpha1 does not exist in GitHub. Instead you have 3.3.0.Alpha2 =)
So, can I start to use it?
Thanks
Pedro
On 2/8/13 2:31 PM, Bela Ban wrote:
On 2/8/13 3:23 PM, Mircea Markus wrote:
Hi Bela,
Do you think we can
excellent, and we'll update it with our findings from the London meeting
On 2/8/13 5:19 PM, Mircea Markus wrote:
I've created a JIRA in the scope of Infinispan 5.3 to track the thread
pool improvements discussed in this email thread:
ISPN-2808 - Make Infinispan use its own thread pool for
Hi,
Based on product and community requirements and team discussions here's the
roadmap for Infinispan 5.3.0. Please let me know any suggestions you might have:
1. stabilise the test suite: (32 intermittent failures http://goo.gl/M3pAu)
2. stabilise Infinispan (NBST, other known bugs)
3. new
17 matches
Mail list logo
