A few questions about the NoSQL MongoDB client subsystem configuration...

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
[1] is an example of the MongoDB subsystem configuration (work in
progress), that specifies three different connection profiles
(mongodbtestprofile_ack, mongodbtestprofile_unack,
mongodbtestprofile_custom).  It should be easy for users to specify one
of the MongoDB constants for the write-concern setting, for each of the
MongoDB profiles.  Specifying a custom write-concern is also possible
(see mongodbtestprofile_custom and underlying MongoDB java driver api [2]).

In [1], I prefer the first configuration example that names the custom
write-concern element "custom-write-concern", as I thought it might be
confusing if users used the same "write-concern" name in two different
places, however, using "write-concern" for both, could be more consistent.

Should we use "custom-write-concern" or "write-concern" for the custom
configuration element?

It comes down to a choice between:

<mongo ...>
   ...
   <custom-write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>

OR

<mongo ...>
   ...
   <write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>

For those not reading [1], we also can support one of the predefined
write-concern constants via:

<mongo ... write-concern="ACKNOWLEDGED">
   ...
</mongo>

Also, is the 'name="default"' setting required for addressing specific
elements with the CLI tool?  I assume this is the case but don't
remember for sure.

Thanks for the input/discussion!  :-)

Scott

[1] https://gist.github.com/scottmarlow/6895f15219ca16a5bc95fc19ef5b397e

[2]
https://api.mongodb.com/java/3.1/com/mongodb/WriteConcern.html#WriteConcern-int-int-boolean-boolean-
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Jesper Pedersen-2
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.

Best regards,
  Jesper


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Brian Stansberry
In reply to this post by Scott Marlow
On 6/8/16 9:39 AM, Scott Marlow wrote:

> [1] is an example of the MongoDB subsystem configuration (work in
> progress), that specifies three different connection profiles
> (mongodbtestprofile_ack, mongodbtestprofile_unack,
> mongodbtestprofile_custom).  It should be easy for users to specify one
> of the MongoDB constants for the write-concern setting, for each of the
> MongoDB profiles.  Specifying a custom write-concern is also possible
> (see mongodbtestprofile_custom and underlying MongoDB java driver api [2]).
>
> In [1], I prefer the first configuration example that names the custom
> write-concern element "custom-write-concern", as I thought it might be
> confusing if users used the same "write-concern" name in two different
> places, however, using "write-concern" for both, could be more consistent.
>
> Should we use "custom-write-concern" or "write-concern" for the custom
> configuration element?
>
> It comes down to a choice between:
>
> <mongo ...>
>    ...
>    <custom-write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
> </mongo>
>
> OR
>
> <mongo ...>
>    ...
>    <write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
> </mongo>
>
> For those not reading [1], we also can support one of the predefined
> write-concern constants via:
>
> <mongo ... write-concern="ACKNOWLEDGED">
>    ...
> </mongo>
>

I think it's confusing to have both an attribute and an element named
"write-concern".

Also, in the management model you are going to need to have two
attributes, one an enum for ACKNOWLEGED etc and then another for the
custom write concern. (The attributes would be declared as alternatives
to each other so the user can only configure one or the other. CUSTOM
would not be a value for the enum.)

Since you'll have two attributes in the model, probably "write-concern"
and "custom-write-concern", it will be even more confusing to call them
both "write-concern" in the xml.

> Also, is the 'name="default"' setting required for addressing specific
> elements with the CLI tool?  I assume this is the case but don't
> remember for sure.
>

Can there be more than 1 custom-write-concern per profile?

If not I doubt that the config of the custom write concern should be
done via a resource. It's a complex attribute of the profile resource,
and any "name" is superfluous.

Even if you model it via a resource, if there is only one the value part
of the final type=value element of its address can be statically
defined; it doesn't need to be user configurable or stored in xml.


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Brian Stansberry
In reply to this post by Jesper Pedersen-2
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Gunnar Morling
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>
            <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>

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.

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.

--Gunnar




2016-06-08 22:18 GMT+02:00 Brian Stansberry <[hidden email]>:
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Jesper Pedersen-2
Hi,

On 06/09/2016 06:27 AM, Gunnar Morling wrote:
> 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.
>

Yes, that is def something to take into account, as there is no common
functionality across all the stores.

> 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.
>

The problem I see with that approach is that some stores doesn't have a
URL concept, so that part will be foreign to those users.

Also the parameters may need to be applied to various "levels" in the
setup. It would be better to scope those as close to component in
question, like we have the pooling configuration under <pool> in
:datasources:.

Parsing the URL w/ configuration could also lead to more configuration
errors in general.

> 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>
>              <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>
>

Yes, I agree that this would be easier to support over time. And the
<properties> element could be scoped under the NoSQL components that
needs it.

That is how <connection-property> works for :datasources:, as we can't
change the subsystem configuration for each patch release of a JDBC driver.

> 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.
>
> 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.

True, but I think that properties that needs a set- are likely important
enough to expose directly in the configuration as an element/attribute.

And that comes down to what each store supports - for JCA we just got a
'supportsDynamic' concept in JCA 1.6, but that doesn't necessarily
translate to JDBC drivers and their DataSource deployments...

Best regards,
  Jesper

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
In reply to this post by Gunnar Morling


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 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
In reply to this post by Jesper Pedersen-2


On 06/09/2016 11:34 AM, Jesper Pedersen wrote:

> Hi,
>
> On 06/09/2016 06:27 AM, Gunnar Morling wrote:
>> 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.
>>
>
> Yes, that is def something to take into account, as there is no common
> functionality across all the stores.
>
>> 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.
>>
>
> The problem I see with that approach is that some stores doesn't have a
> URL concept, so that part will be foreign to those users.
>
> Also the parameters may need to be applied to various "levels" in the
> setup. It would be better to scope those as close to component in
> question, like we have the pooling configuration under <pool> in
> :datasources:.
>
> Parsing the URL w/ configuration could also lead to more configuration
> errors in general.
>
>> 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>
>>              <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>
>>
>
> Yes, I agree that this would be easier to support over time. And the
> <properties> element could be scoped under the NoSQL components that
> needs it.

+1, easier to support over time, helps us.

>
> That is how <connection-property> works for :datasources:, as we can't
> change the subsystem configuration for each patch release of a JDBC driver.
>
>> 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.
>>
>> 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.
>
> True, but I think that properties that needs a set- are likely important
> enough to expose directly in the configuration as an element/attribute.
>
> And that comes down to what each store supports - for JCA we just got a
> 'supportsDynamic' concept in JCA 1.6, but that doesn't necessarily
> translate to JDBC drivers and their DataSource deployments...
>
> Best regards,
>  Jesper
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Gunnar Morling
In reply to this post by Scott Marlow
> 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 <[hidden email]>:


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 <[hidden email]
<mailto:[hidden email]>>:

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


    --
    Brian Stansberry
    Senior Principal Software Engineer
    JBoss by Red Hat
    _______________________________________________
    wildfly-dev mailing list
    [hidden email] <mailto:[hidden email]>
    https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Darran Lofthouse
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 <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>             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
>             > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             >
>
>
>             --
>             Brian Stansberry
>             Senior Principal Software Engineer
>             JBoss by Red Hat
>             _______________________________________________
>             wildfly-dev mailing list
>             [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
In reply to this post by Gunnar Morling


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 <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>             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
>             > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             >
>
>
>             --
>             Brian Stansberry
>             Senior Principal Software Engineer
>             JBoss by Red Hat
>             _______________________________________________
>             wildfly-dev mailing list
>             [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
In reply to this post by Gunnar Morling


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?
>
> 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?

I'm not sure yet, that should be independent of the hostname/port#,
being in a separate part of the WildFly configuration file.

>
>
> 2016-06-09 22:23 GMT+02:00 Scott Marlow <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>             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
>             > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>             >
>
>
>             --
>             Brian Stansberry
>             Senior Principal Software Engineer
>             JBoss by Red Hat
>             _______________________________________________
>             wildfly-dev mailing list
>             [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Scott Marlow
In reply to this post by Darran Lofthouse
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 <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>
>>
>>     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
>>         <[hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>>:
>>
>>             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
>>             > [hidden email]
>>         <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>             > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>             >
>>
>>
>>             --
>>             Brian Stansberry
>>             Senior Principal Software Engineer
>>             JBoss by Red Hat
>>             _______________________________________________
>>             wildfly-dev mailing list
>>             [hidden email]
>>         <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: A few questions about the NoSQL MongoDB client subsystem configuration...

Darran Lofthouse
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 <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>
>>>
>>>     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
>>>         <[hidden email]
>>> <mailto:[hidden email]>
>>>         <mailto:[hidden email]
>>>         <mailto:[hidden email]>>>:
>>>
>>>             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
>>>             > [hidden email]
>>>         <mailto:[hidden email]>
>>>         <mailto:[hidden email]
>>>         <mailto:[hidden email]>>
>>>             > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>             >
>>>
>>>
>>>             --
>>>             Brian Stansberry
>>>             Senior Principal Software Engineer
>>>             JBoss by Red Hat
>>>             _______________________________________________
>>>             wildfly-dev mailing list
>>>             [hidden email]
>>>         <mailto:[hidden email]>
>>>         <mailto:[hidden email]
>>>         <mailto:[hidden email]>>
>>>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev