<div dir="ltr">Hi,<div><br></div><div>My concern with the current proposal and its usage of dedicated elements/attributes for specific options such as write concern is that it easily leads into a catch-up game with datastore vendors as they keep adding new options. That might create a constant effort for maintaining this subsystem.</div><br>How about having a more generic approach which only has typed elements for common properties/settings such as user, password, database name and then allows to set custom things as part of the connection URL:<br><br> <subsystem xmlns="urn:jboss:domain:nosql:1.0"><br> <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test"><br> <connection-url>nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&...</connection-url><br> <security><br> <user-name>bob</user-name><br> <password>secret</password><br> </security><br> </datasource><br> </subsystem><br><br>Here, the connection-url would be analyzed to load the right driver and pass any configured settings to it.<div><br></div><div>While compact, that URL syntax might be confused with existing URI schemes of specific stores, so an alternative might be this (a bit more verbose, though):<br><br> <subsystem xmlns="urn:jboss:domain:nosql:1.0"><br> <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test"><br> <driver>mongodb</driver><br> <end-points>localhost:27017,otherhost:27017</end-points><br> <database>somedatabase</database><br> <security><br> <user-name>bob</user-name><br> <password>secret</password><br> </security><br> <properties><br> <property name="writeConcern">ACKNOWLEDGED</property><br> <property name="readPreference">MAJORITY</property><br> </properties><br> </datasource><br> </subsystem></div><div><br></div><div>Both alternatives don't address custom write concerns, but I think you foresee CDI producer methods for more advanced customizations, so that might be fine. That'd also be needed for some other non-primitive options (dbDecoderFactory, codecRegistry etc.), unless you provide a way to configure classes here and have them instantiated.</div><div><br></div><div>These more generic approaches will make it more robust towards new options being added, but of course you also loose type-safety and I suppose usability in the console which might provide dedicated editors for real types such as boolean etc.</div><div><br></div><div>--Gunnar</div><div><br></div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-08 22:18 GMT+02:00 Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/8/16 9:44 AM, Jesper Pedersen wrote:<br>
> On 06/08/2016 10:39 AM, Scott Marlow wrote:<br>
>> For those not reading [1], we also can support one of the predefined<br>
>> write-concern constants via:<br>
>><br>
>> <mongo ... write-concern="ACKNOWLEDGED"><br>
>> ...<br>
>> </mongo><br>
>><br>
><br>
> I would choose this approach, and support the predefined constants.<br>
><br>
> Exposing MongoDB internal API details in the configuration seems to be<br>
> overkill, and put extra effort on your part when they change the API.<br>
><br>
<br>
</span>This is good input. If this ends up in WildFly or EAP, we have stringent<br>
compatibility guarantees, so be cautious about exposing things in your API.<br>
<span class="im HOEnZb"><br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
<br>
<br>
</span><span class="im HOEnZb">--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>