Re: [infinispan-dev] TimeService (ISPN-3069): CacheLoader API break

+1 On 14 May 2013, at 10:47, Pedro Ruivo <pedro(a)infinispan.org&gt; wrote: > OK! if everybody agrees, I'm going to remove from AdvancedCache and from > the GlobalConfiguration(Builder). Also, I'm going to remove the "final" > modifier from ComponentRegistry to mock it for cache store test suite. > > On 05/14/2013 10:44 AM, Dan Berindei wrote: >> >> >> >> On Tue, May 14, 2013 at 12:38 PM, Pedro Ruivo <pedro(a)infinispan.org >> <mailto:pedro@infinispan.org>> wrote: >> >> >> >> On 05/14/2013 10:31 AM, Dan Berindei wrote: >>> >>> >>> >>> On Tue, May 14, 2013 at 11:51 AM, Pedro Ruivo >> <pedro(a)infinispan.org <mailto:pedro@infinispan.org> >>> <mailto:pedro@infinispan.org <mailto:pedro@infinispan.org>>> wrote: >>> >>> >>> >>> On 05/14/2013 09:44 AM, Dan Berindei wrote: >>>> >>>> >>>> >>>> On Tue, May 14, 2013 at 11:37 AM, Manik Surtani >>> <msurtani(a)redhat.com <mailto:msurtani@redhat.com> >> <mailto:msurtani@redhat.com <mailto:msurtani@redhat.com>> >>>> <mailto:msurtani@redhat.com <mailto:msurtani@redhat.com> >> <mailto:msurtani@redhat.com <mailto:msurtani@redhat.com>>>> wrote: >>>> >>>> >>>> On 14 May 2013, at 08:33, Dan Berindei >>> <dan.berindei(a)gmail.com <mailto:dan.berindei@gmail.com> >> <mailto:dan.berindei@gmail.com <mailto:dan.berindei@gmail.com>> >>>> <mailto:dan.berindei@gmail.com >> <mailto:dan.berindei@gmail.com> >>> <mailto:dan.berindei@gmail.com >> <mailto:dan.berindei@gmail.com>>>> wrote: >>>> >>>>> If we want to keep it hidden, then I think it would >> be best to >>>>> leave the getTimeService() method only in >>>>> ComponentRegistry/GlobalComponentRegistry and remove >> it from the >>>>> AdvancedCache interface. >>>> >>>> +1. >>> >>> first I have two situations here: >>> >>> in production: it's indifferent for me have it in the >> AdvancedCache or >>> in the ComponentRegistry, in the cache loader/store and in >> the Extended >>> Stats I have access to the cache and I can pick from everywhere. >>> >>> in the test suite: I first try to have it only in the >> ComponentRegistry >>> and I was not be able to mock it because the class is final >> (I believe >>> that is final for some reason). In addition, all the cache >> store tests >>> mocks the Cache interface. That's why I put it in the >> AdvancedCache. >>> >>> >>> Yeah, being able to inject the TimeService directly in the cache >> store >>> would have been nice :) >>> I think we can remove the final modifier from the ComponentRegistry >>> class, though. >>> >>>> >>>>> We might want to remove it from the configuration, too. >>>> >>>> It is definitely *not* configurable and *not* a part >> of the >>>> configuration. See an earlier thread on this subject: >>>> http://bit.ly/102aQ9R >>> >>> This is another issue I have. I need to have the TimeService >> in the >>> Extended Stats and this are a CustomInterceptor. My first try >> was to >>> replace and rewire the GlobalComponent but this does not work >> because I >>> don't have any @Inject method in the CustomInterceptor where >> I can >>> replace for TimeService implementation in the test suite. >> That's why it >>> is in the GlobalConfiguration. >>> >>> >>> cache.getAdvancedCache().getComponentRegistry().getTimeService() >> should >>> work in a custom interceptor. >>> You just have to mock the cache and the component registry... >> >> I cannot mock the cache in the test suite otherwise I'm not able to test >> the statistics. Even if I register and rewire the ComponentRegistry, >> does not work because I'm setting the TimeService when the start() is >> invoked. >> >> >> Ok, I think I understand the problem now, and the simplest solution >> would be to use TestingUtil.replaceField to replace the TimeService in >> your interceptor with a mock. >> >> >> >> >> >> _______________________________________________ >> 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 -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev