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

Dan Berindei dan.berindei at gmail.com
Fri May 10 07:32:35 EDT 2013


On Fri, May 10, 2013 at 1:31 PM, Manik Surtani <msurtani at redhat.com> wrote:

>
> On 10 May 2013, at 11:14, Dan Berindei <dan.berindei at gmail.com> wrote:
>
>
>
>
> On Fri, May 10, 2013 at 11:53 AM, Manik Surtani <msurtani at redhat.com>wrote:
>
>>
>> On 9 May 2013, at 20:56, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> Couldn't you change CacheLoaderManager to call
>> ComponentRegistry.wireDependencies(cacheStore)?
>>
>> That way, each cache store could have a separate @Inject method, and it
>> could depend on any cache-scoped or global-scoped component. It may require
>> an infinispan-module.properties file in each cache store module, but it
>> then it could be used for any other component.
>>
>>
>> -1.  That would expose the injection fwk to custom cache store impls.
>>  Unless you're assuming that custom impls would't use the TimeService
>> (since it isn't public API), and just call System.nanoTime() directly?
>>
>>
> Well, that was my point: to allow custom cache stores to use the injection
> framework.
>
> The custom cache stores can use the component registry right now, because
> they have access to the cache. And they can also use injection for their
> own custom components, by writing a
> org.infinispan.factories.components.ModuleMetadataFileFinder. Not allowing
> them to use injection in the cache store itself seems like an arbitrary
> limitation.
>
>
> It's not arbitrary at all.  It makes such internals an SPI with rules
> around compatibility.  I'd rather keep these internal and reserve the right
> to change/modify them without impact to extension points.
>
>
Isn't it already an SPI if the component registry can be accessed via
AdvancedCache and we allow any external module to inject its own components?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130510/d04d7643/attachment.html 


More information about the infinispan-dev mailing list