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@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@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev