On 19 Feb 2014, at 12:03, Sanne Grinovero sa...@infinispan.org wrote:
On 19 February 2014 07:12, Galder Zamarreño gal...@redhat.com wrote:
On 03 Feb 2014, at 19:01, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa rva...@redhat.com wrote:
For
Hi Faseela,
Can you create a unit test demonstrating this (including the config.xml file)?
There are plenty of examples in [1].
Cheers,
[1]
https://github.com/infinispan/infinispan/tree/master/core/src/test/java/org/infinispan/configuration
On 20 Feb 2014, at 10:11, Faseela K
On 19 Feb 2014, at 17:44, Dennis Reed der...@redhat.com wrote:
On 02/19/2014 12:57 AM, Galder Zamarreño wrote:
On 31 Jan 2014, at 08:32, Dennis Reed der...@redhat.com wrote:
It would be a loss of functionality.
As a common example, the AS web session replication cache is configured
for
On Wed, Feb 26, 2014 at 8:56 AM, Galder Zamarreño gal...@redhat.com wrote:
On 19 Feb 2014, at 12:03, Sanne Grinovero sa...@infinispan.org wrote:
On 19 February 2014 07:12, Galder Zamarreño gal...@redhat.com wrote:
On 03 Feb 2014, at 19:01, Dan Berindei dan.berin...@gmail.com wrote:
Great work Radim!!! Awesome job and very interesting roadmap :)
On 20 Feb 2014, at 15:40, Radim Vansa rva...@redhat.com wrote:
Hi all,
it has been a long time since last release of RadarGun. We have been
using it intensively and developed many new features - 1.0.0 had 7,340
lines of Java
Great job, Radim! Looking forward to Radargun 2.0!
On Wed, Feb 26, 2014 at 12:47 PM, Galder Zamarreño gal...@redhat.comwrote:
Great work Radim!!! Awesome job and very interesting roadmap :)
On 20 Feb 2014, at 15:40, Radim Vansa rva...@redhat.com wrote:
Hi all,
it has been a long time
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
There also is the opposite problem to be considered, as Emmanuel
suggested on 11/04/2012:
you can't forbid the user to store the same object (same type and same
id) in two different caches, where each Cache might be
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear distinction between public and private API/SPI. I would
like to clearly mark which of our classes/interfaces are public API.
Should we:
- add some decoration / visual cue to such elements to
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
There also is the opposite problem to be considered, as Emmanuel
suggested on 11/04/2012:
you can't forbid the user to store the same object
On Feb 26, 2014, at 2:13 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
There also is the opposite problem to be considered, as Emmanuel
On Feb 26, 2014, at 1:05 PM, Tristan Tarrant ttarr...@redhat.com wrote:
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear distinction between public and private API/SPI. I would
like to clearly mark which of our classes/interfaces are public API.
On 26/02/2014 15:02, Mircea Markus wrote:
On Feb 26, 2014, at 1:05 PM, Tristan Tarrant ttarr...@redhat.com wrote:
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear distinction between public and private API/SPI. I would
like to clearly mark which
On 02/26/2014 04:20 PM, Mircea Markus wrote:
On Feb 26, 2014, at 2:13 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
There also is the opposite
On Wed, Feb 26, 2014 at 4:24 PM, Tristan Tarrant ttarr...@redhat.comwrote:
On 26/02/2014 15:02, Mircea Markus wrote:
On Feb 26, 2014, at 1:05 PM, Tristan Tarrant ttarr...@redhat.com
wrote:
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear
I agree, sounds like a sensible thing to do. But this needs to be
planned carefully and when exactly is the good time to do it, soon and
have it ready for 7.0.0.Final?
On 2/26/2014, 10:29 AM, Dan Berindei wrote:
If we move all internal classes to .impl sub-packages, it will be
quite easy
On Feb 26, 2014, at 2:33 PM, Adrian Nistor anis...@redhat.com wrote:
On 02/26/2014 04:20 PM, Mircea Markus wrote:
On Feb 26, 2014, at 2:13 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 5:08
On 25 Feb 2014, at 16:08, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard emman...@hibernate.org wrote:
On 24 févr. 2014, at 17:39, Mircea Markus mmar...@redhat.com wrote:
On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard emman...@hibernate.org
Hey,
There is an interesting request from community to include an Address along with
a Future returned for a subtask being executed [1].
I think it makes sense what this user wants. We might create Future sub
interface that has getAddress method and we can return an object implementing
that
I'm a bit skeptical.
It might sound a sensible request currently, but if you do so you
inherently promise that tasks are going to be executed on a specific
server; AFAIK we promise execution on data locality, but maintaining a
good level of flexibility you can evolve your system to smarter load
To clarify some points rised on the thread Design change in
Infinispan Query, which I don't wish to derail further:
The Query engine can actually apply per-entry user restriction access
in an efficient way which doesn't involve (necessarily) to check each
result; currently this needs specific
20 matches
Mail list logo
