[wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration...

[Gunnar Morling]

> We cannot include hostname + port numbers directly, instead we reference
host names/port pairs defined in the outbound-socket-binding section of
standalone.xml.

Why is that? Some general principle in WF config?

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?


2016-06-09 22:23 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

>
>
> On 06/09/2016 06:27 AM, Gunnar Morling wrote:
>
>> Hi,
>>
>> 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.
>>
>> 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:
>>
>>     <subsystem xmlns="urn:jboss:domain:nosql:1.0">
>>         <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test">
>>
>>
>> <connection-url>nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&...</connection-url>
>>             <security>
>>                 <user-name>bob</user-name>
>>                 <password>secret</password>
>>             </security>
>>         </datasource>
>>     </subsystem>
>>
>> Here, the connection-url would be analyzed to load the right driver and
>> pass any configured settings to it.
>>
>> 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):
>>
>>     <subsystem xmlns="urn:jboss:domain:nosql:1.0">
>>         <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test">
>>             <driver>mongodb</driver>
>>             <end-points>localhost:27017,otherhost:27017</end-points>
>>
>
> We cannot include hostname + port numbers directly, instead we reference
> host names/port pairs defined in the outbound-socket-binding section of
> standalone.xml.
>
>             <database>somedatabase</database>
>>             <security>
>>                 <user-name>bob</user-name>
>>                 <password>secret</password>
>>             </security>
>>             <properties>
>>                 <property name="writeConcern">ACKNOWLEDGED</property>
>>                 <property name="readPreference">MAJORITY</property>
>>             </properties>
>>         </datasource>
>>     </subsystem>
>>
>>
> +1 for the separate properties idea!
>
> 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.
>>
>
> 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.
>
>
>> 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.
>>
>
> 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.
>
> Thanks,
> Scott
>
>
>> --Gunnar
>>
>>
>>
>>
>> 2016-06-08 22:18 GMT+02:00 Brian Stansberry <brian.stansberry at redhat.com
>> <mailto:brian.stansberry at redhat.com>>:
>>
>>     On 6/8/16 9:44 AM, Jesper Pedersen wrote:
>>     > On 06/08/2016 10:39 AM, Scott Marlow wrote:
>>     >> For those not reading [1], we also can support one of the
>> predefined
>>     >> write-concern constants via:
>>     >>
>>     >> <mongo ... write-concern="ACKNOWLEDGED">
>>     >>     ...
>>     >> </mongo>
>>     >>
>>     >
>>     > I would choose this approach, and support the predefined constants.
>>     >
>>     > Exposing MongoDB internal API details in the configuration seems to
>> be
>>     > overkill, and put extra effort on your part when they change the
>> API.
>>     >
>>
>>     This is good input. If this ends up in WildFly or EAP, we have
>> stringent
>>     compatibility guarantees, so be cautious about exposing things in
>>     your API.
>>
>>     >
>>     > _______________________________________________
>>     > wildfly-dev mailing list
>>     > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>     >
>>
>>
>>     --
>>     Brian Stansberry
>>     Senior Principal Software Engineer
>>     JBoss by Red Hat
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/17a318d0/attachment.html