<div dir="ltr">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).<div><br></div><div>If it's not possible to have a custom configuration schema - I would vote for #4.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 3:42 PM, Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, that would be nice.<br>
<br>
I found another "cons" for #4: an embedded config would not translate<br>
1:1 to server. Well, it doesn't translate directly now either, but at<br>
least it's "closer".<br>
<span class="HOEnZb"><font color="#888888"><br>
Tristan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 25/01/2016 15:39, Radim Vansa wrote:<br>
> Would the deployable cache stores benefit from 4) as well? It seems to<br>
> me as the only 'right' option.<br>
><br>
> R.<br>
><br>
> On 01/25/2016 02:29 PM, Tristan Tarrant wrote:<br>
>> Hi all,<br>
>><br>
>> Jakub has recently revived the Cassandra Cache Store (CCS from now on)<br>
>> which, as you all will remember, was pushed to an external repository<br>
>> where it lay in abandonment ever since.<br>
>><br>
>> We now need to add support for this store to Infinispan Server, but<br>
>> unfortunately, because of the "monolithic schema" approach that WildFly<br>
>> imposes on subsystems, this has to be done within the Infinispan<br>
>> subsystem itself.<br>
>> This creates a conundrum, since the CCS depends on Infinispan core,<br>
>> server would depend on the CCS but server is part of the Infinispan build.<br>
>><br>
>> Possible solutions:<br>
>> 1) move the CCS back into the main repo<br>
>> - pros: no more conundrum, built by default, easier to maintain<br>
>> - cons: makes the repo even bigger, binds the lifecycle of the CCS<br>
>> to Infinispan's<br>
>> 2) extend the server to be able to interpret the CCS schema but not<br>
>> actually depend on its code and provide the code to instantiate the CCS<br>
>> as an overlay module which can be installed on server<br>
>> - pros: keeps the lifecycle of the CCS independent<br>
>> - cons: additional complexity to handle the split, forces us to<br>
>> still keep server aligned with schema changes in the CCS itself.<br>
>> 3) make the CCS a deployable cache store<br>
>> - pros: easiest<br>
>> - cons: not really ootb experience, no nice schema<br>
>> 4) create a dedicated subsystem for the CCS and "invent" a way to<br>
>> reference it from the main Infinispan subsystem using a naming<br>
>> convention, similar to how datasources are currently implemented.<br>
>> - pros: keeps the two projects independent, reusable for other<br>
>> Cachestores<br>
>> - cons: writing a subsystem from scratch is complex (although bits<br>
>> of it could be made reusable for multiple cachestores).<br>
>><br>
>> Your thoughts please.<br>
>><br>
>> Tristan<br>
><br>
><br>
<br>
--<br>
</div></div><span class="im HOEnZb">Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>