Because of the component registry, every component is a (non-public)
extension point by itself. So I don't see the need to do anything special,
if we're only going to use it in the test suite.
On Fri, May 3, 2013 at 2:58 PM, Sanne Grinovero <sanne(a)infinispan.org>wrote:
For testing purposes it would be useful to inject a custom
implementation. Doesn't have to be a public API, but some kind of
extension point would be needed.
On 3 May 2013 12:51, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On 3 May 2013, at 11:46, Galder Zamarreño wrote:
>
>> On May 2, 2013, at 7:01 PM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>
>>>>> When recovery is enabled, the recovery manager creates a second
cache.
>>>>> Someone may want to replace the Clock/TimeService for the
"normal"
cache
>>>>> and left the default implementation in the "recovery"
cache.
>>>>
>>>> ^ Why would an end-user want to replace the Clock/TimeService?
>>>>
>>>> Remember what I said in my previous email: I can see someone changing
the service implementation for testing reasons, and in that case, a global
clock/timer service that's swapable via system property would work just
fine IMO.
>>>
>>> I don't know. I'm being pessimist and assuming that someone in the
world
>>> as a dark use case and needs to replace the service.
>>
>> ^ We already have quite a big configuration… we should think twice
about adding more stuff… :)
> +1. on top of that we can always add it to config if needed, harder to
remove it.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (
www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev