[wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration...
Darran Lofthouse
darran.lofthouse at jboss.com
Sun Jun 12 09:59:35 EDT 2016
Elytron is targeted for WildFly 11 so assuming this is coming at the
same time probably makes sense to review how the default our of the box
security settings can be combined with Elytron.
On 10/06/16 16:07, Scott Marlow wrote:
> Darran,
>
> We didn't yet try to configure NoSQL authentication, should we try that
> after switching WildFly to Elytron, or before? We definitely want to
> support authentication. Perhaps we should consider requiring
> authentication by default and let developers disable it, as there are
> many unsecured NoSQL databases out there.
>
> Thanks,
> Scott
>
> On 06/10/2016 05:46 AM, Darran Lofthouse wrote:
>> Shortly we are going to be starting to transition subsystems to make use
>> of Elytron defined capabilities so things like custom trust manager
>> configuration should not need to live in individual subsystems any
>> more: -
>>
>> https://developer.jboss.org/docs/DOC-53383
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 10/06/16 06:46, 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?
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
More information about the wildfly-dev
mailing list