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

[Manik Surtani]

+1

On 14 May 2013, at 10:47, Pedro Ruivo <pedro at infinispan.org> 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 at infinispan.org
>> <mailto:pedro at 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 at infinispan.org <mailto:pedro at infinispan.org>
>>> <mailto:pedro at infinispan.org <mailto:pedro at 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 at redhat.com <mailto:msurtani at redhat.com>
>>    <mailto:msurtani at redhat.com <mailto:msurtani at redhat.com>>
>>>> <mailto:msurtani at redhat.com <mailto:msurtani at redhat.com>
>>    <mailto:msurtani at redhat.com <mailto:msurtani at redhat.com>>>> wrote:
>>>> 
>>>> 
>>>>    On 14 May 2013, at 08:33, Dan Berindei
>>>    <dan.berindei at gmail.com <mailto:dan.berindei at gmail.com>
>>    <mailto:dan.berindei at gmail.com <mailto:dan.berindei at gmail.com>>
>>>>    <mailto:dan.berindei at gmail.com
>>    <mailto:dan.berindei at gmail.com>
>>>    <mailto:dan.berindei at gmail.com
>>    <mailto:dan.berindei at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid