[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