[infinispan-dev] (Not-so-)optional cachestores

[Sebastian Laskawiec]

Is it possible to have #3 and use a dedicated configuration schema per
Cache Store? Otherwise the only way to configure a Cache Store it to use
properties (key/value pairs).

If it's not possible to have a custom configuration schema - I would vote
for #4.

On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Yes, that would be nice.
>
> I found another "cons" for #4: an embedded config would not translate
> 1:1 to server. Well, it doesn't translate directly now either, but at
> least it's "closer".
>
> Tristan
>
> On 25/01/2016 15:39, Radim Vansa wrote:
> > Would the deployable cache stores benefit from 4) as well? It seems to
> > me as the only 'right' option.
> >
> > R.
> >
> > On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> >> Hi all,
> >>
> >> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
> >> which, as you all will remember, was pushed to an external repository
> >> where it lay in abandonment ever since.
> >>
> >> We now need to add support for this store to Infinispan Server, but
> >> unfortunately, because of the "monolithic schema" approach that WildFly
> >> imposes on subsystems, this has to be done within the Infinispan
> >> subsystem itself.
> >> This creates a conundrum, since the CCS depends on Infinispan core,
> >> server would depend on the CCS but server is part of the Infinispan
> build.
> >>
> >> Possible solutions:
> >> 1) move the CCS back into the main repo
> >>       - pros: no more conundrum, built by default, easier to maintain
> >>       - cons: makes the repo even bigger, binds the lifecycle of the CCS
> >> to Infinispan's
> >> 2) extend the server to be able to interpret the CCS schema but not
> >> actually depend on its code and provide the code to instantiate the CCS
> >> as an overlay module which can be installed on server
> >>       - pros: keeps the lifecycle of the CCS independent
> >>       - cons: additional complexity to handle the split, forces us to
> >> still keep server aligned with schema changes in the CCS itself.
> >> 3) make the CCS a deployable cache store
> >>       - pros: easiest
> >>       - cons: not really ootb experience, no nice schema
> >> 4) create a dedicated subsystem for the CCS and "invent" a way to
> >> reference it from the main Infinispan subsystem using a naming
> >> convention, similar to how datasources are currently implemented.
> >>       - pros: keeps the two projects independent, reusable for other
> >> Cachestores
> >>       - cons: writing a subsystem from scratch is complex (although bits
> >> of it could be made reusable for multiple cachestores).
> >>
> >> Your thoughts please.
> >>
> >> Tristan
> >
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> 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/20160125/f5bcf7f6/attachment.html