<div dir="ltr">&gt; 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">&lt;<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>&gt;</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>
    &lt;subsystem xmlns=&quot;urn:jboss:domain:nosql:1.0&quot;&gt;<br>
        &lt;nosql-datasource jndi-name=&quot;java:jboss/nosql/mongodb_test&quot;&gt;<br>
<br>
&lt;connection-url&gt;nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&amp;readPreference=MAJORITY&amp;...&lt;/connection-url&gt;<br>
            &lt;security&gt;<br>
                &lt;user-name&gt;bob&lt;/user-name&gt;<br>
                &lt;password&gt;secret&lt;/password&gt;<br>
            &lt;/security&gt;<br>
        &lt;/datasource&gt;<br>
    &lt;/subsystem&gt;<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>
    &lt;subsystem xmlns=&quot;urn:jboss:domain:nosql:1.0&quot;&gt;<br>
        &lt;nosql-datasource jndi-name=&quot;java:jboss/nosql/mongodb_test&quot;&gt;<br>
            &lt;driver&gt;mongodb&lt;/driver&gt;<br>
            &lt;end-points&gt;localhost:27017,otherhost:27017&lt;/end-points&gt;<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">
            &lt;database&gt;somedatabase&lt;/database&gt;<br>
            &lt;security&gt;<br>
                &lt;user-name&gt;bob&lt;/user-name&gt;<br>
                &lt;password&gt;secret&lt;/password&gt;<br>
            &lt;/security&gt;<br>
            &lt;properties&gt;<br>
                &lt;property name=&quot;writeConcern&quot;&gt;ACKNOWLEDGED&lt;/property&gt;<br>
                &lt;property name=&quot;readPreference&quot;&gt;MAJORITY&lt;/property&gt;<br>
            &lt;/properties&gt;<br>
        &lt;/datasource&gt;<br>
    &lt;/subsystem&gt;<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&#39;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&#39;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&#39;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 &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a><br></span>
&lt;mailto:<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;&gt;:<span><br>
<br>
    On 6/8/16 9:44 AM, Jesper Pedersen wrote:<br>
    &gt; On 06/08/2016 10:39 AM, Scott Marlow wrote:<br>
    &gt;&gt; For those not reading [1], we also can support one of the predefined<br>
    &gt;&gt; write-concern constants via:<br>
    &gt;&gt;<br>
    &gt;&gt; &lt;mongo ... write-concern=&quot;ACKNOWLEDGED&quot;&gt;<br>
    &gt;&gt;     ...<br>
    &gt;&gt; &lt;/mongo&gt;<br>
    &gt;&gt;<br>
    &gt;<br>
    &gt; I would choose this approach, and support the predefined constants.<br>
    &gt;<br>
    &gt; Exposing MongoDB internal API details in the configuration seems to be<br>
    &gt; overkill, and put extra effort on your part when they change the API.<br>
    &gt;<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>
    &gt;<br>
    &gt; _______________________________________________<br>
    &gt; wildfly-dev mailing list<br></span>
    &gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>&gt;<span><br>
    &gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
    &gt;<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> &lt;mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>&gt;<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>