<div dir="ltr">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.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, May 3, 2013 at 2:58 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For testing purposes it would be useful to inject a custom<br>
implementation. Doesn't have to be a public API, but some kind of<br>
extension point would be needed.<br>
<div class="HOEnZb"><div class="h5"><br>
On 3 May 2013 12:51, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
><br>
> On 3 May 2013, at 11:46, Galder Zamarreño wrote:<br>
><br>
>> On May 2, 2013, at 7:01 PM, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
>><br>
>>>>> When recovery is enabled, the recovery manager creates a second cache.<br>
>>>>> Someone may want to replace the Clock/TimeService for the "normal" cache<br>
>>>>> and left the default implementation in the "recovery" cache.<br>
>>>><br>
>>>> ^ Why would an end-user want to replace the Clock/TimeService?<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> I don't know. I'm being pessimist and assuming that someone in the world<br>
>>> as a dark use case and needs to replace the service.<br>
>><br>
>> ^ We already have quite a big configuration… we should think twice about adding more stuff… :)<br>
> +1. on top of that we can always add it to config if needed, harder to remove it.<br>
><br>
> Cheers,<br>
> --<br>
> Mircea Markus<br>
> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></div></div></blockquote></div><br></div>