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

Scott Marlow smarlow at redhat.com
Fri Jun 10 10:56:41 EDT 2016



On 06/10/2016 01:46 AM, Gunnar Morling wrote:
>> 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?

Yes, users define the host/port pairs as a group.  An example Ne04J 
subsystem config using "neo4jtesthost" to separately define the 
host/port, might be:

<subsystem xmlns="urn:jboss:domain:neo4j:1.0">
   <neo4j name="default" id="neo4jtesttprofile" 
jndi-name="java:jboss/neo4jdriver/test">
      <host name="default" outbound-socket-binding-ref="neo4jtesthost"/>
   </neo4j>
</subsystem>

<socket-binding-group name="standard-sockets" default-interface="public" 
port-offset="${jboss.socket.binding.port-offset:0}">
...
  <outbound-socket-binding name="neo4jtesthost">
   <remote-destination host="localhost" port="7687"/>
  </outbound-socket-binding>
</socket-binding-group>

We are using this everywhere but datasources, which still include 
host/port (I assume for backward compatibility reasons).

>
> 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
> <mailto: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>
>         <mailto: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>
>         <mailto: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>
>         <mailto:wildfly-dev at lists.jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>


More information about the wildfly-dev mailing list