<div dir="ltr">> We cannot include hostname + port numbers directly, instead we reference host names/port pairs defined in the outbound-socket-binding section of standalone.xml.<div><br></div><div>Why is that? Some general principle in WF config?</div><div><br></div><div>In OGM, we recently had the feature request to support a custom socket factory (see MongoClientOptions#setSocketFactory()); The user wanted to set a SSLSocketFactory configured with a custom trust store. Would that still be possible?</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">2016-06-09 22:23 GMT+02:00 Scott Marlow <span dir="ltr"><<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
On 06/09/2016 06:27 AM, Gunnar Morling wrote:<br>
</span><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
My concern with the current proposal and its usage of dedicated<br>
elements/attributes for specific options such as write concern is that<br>
it easily leads into a catch-up game with datastore vendors as they keep<br>
adding new options. That might create a constant effort for maintaining<br>
this subsystem.<br>
<br>
How about having a more generic approach which only has typed elements<br>
for common properties/settings such as user, password, database name and<br>
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>
<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<br>
pass any configured settings to it.<br>
<br>
While compact, that URL syntax might be confused with existing URI<br>
schemes of specific stores, so an alternative might be this (a bit more<br>
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>
</blockquote>
<br></div></div>
We cannot include hostname + port numbers directly, instead we reference host names/port pairs defined in the outbound-socket-binding section of standalone.xml.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<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><br>
<br>
</blockquote>
<br></span>
+1 for the separate properties idea!<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Both alternatives don't address custom write concerns, but I think you<br>
foresee CDI producer methods for more advanced customizations, so that<br>
might be fine. That'd also be needed for some other non-primitive<br>
options (dbDecoderFactory, codecRegistry etc.), unless you provide a way<br>
to configure classes here and have them instantiated.<br>
</blockquote>
<br></span>
I'm still learning more about how to use advance customizations in the CDI producer but yes, we definitely want to do this, to simplify application program use of NoSQL.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
These more generic approaches will make it more robust towards new<br>
options being added, but of course you also loose type-safety and I<br>
suppose usability in the console which might provide dedicated editors<br>
for real types such as boolean etc.<br>
</blockquote>
<br></span>
I think that about summarizes the difference. Eventually, when the configuration options stabilize, it might be better to switch to dedicated editors, which would be a big one-off upgrade, I think. If we used dedicated editors now, we will have several big (NoSQL subsystem configuration) upgrades, as the NoSQL database options may change over time.<br>
<br>
Thanks,<br>
Scott<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
<br>
--Gunnar<br>
<br>
<br>
<br>
<br>
2016-06-08 22:18 GMT+02:00 Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a><br></span>
<mailto:<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>>>:<span><br>
<br>
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>
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<br>
your API.<br>
<br>
><br>
> _______________________________________________<br>
> wildfly-dev mailing list<br></span>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><span><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>
--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
_______________________________________________<br>
wildfly-dev mailing list<br></span>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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>
</blockquote>
</blockquote></div><br></div></div></div>