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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
