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

[Dan Berindei]

100% agree, most users will have to interact with AdvancedCache at some
point - if only because of lock() and withFlags().

That doesn't mean everyone uses AdvancedCache.getComponentRegistry(), but
it does mean that a cache store implementation can use any component it
wants to.


On Mon, May 13, 2013 at 1:16 PM, Sanne Grinovero <sanne at infinispan.org>wrote:

> AdvancedCache is the API we use the most. I'd rather say I don't care for
> Cache: all I use it for us to get an AdvancedCache.
>
> On 13 May 2013 10:12, "Manik Surtani" <msurtani at redhat.com> wrote:
> >
> >
> > On 10 May 2013, at 12:32, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> >>
> >> 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?
> >
> >
> > It is.  But at least AdvancedCache isn't a critical, core interface that
> every Infinispan user will at some point interact with.
> >
> > --
> > Manik Surtani
> > manik at jboss.org
> > twitter.com/maniksurtani
> >
> > Platform Architect, JBoss Data Grid
> > http://red.ht/data-grid
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130513/a249e575/attachment-0001.html