10:39 a.m.
[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#WriteConce...
10:44 a.m.
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
4:18 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:27 a.m.
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 <brian.stansberry(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:34 a.m.
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
4:29 p.m.
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
4:23 p.m.
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(a)redhat.com
<mailto:brian.stansberry@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:46 a.m.
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(a)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(a)redhat.com
>> <mailto:brian.stansberry@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(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
5:46 a.m.
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(a)redhat.com
<mailto:smarlow@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(a)redhat.com <mailto:brian.stansberry@redhat.com>
<mailto:brian.stansberry@redhat.com
<mailto:brian.stansberry@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:07 a.m.
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(a)redhat.com
> <mailto:smarlow@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(a)redhat.com <mailto:brian.stansberry@redhat.com>
> <mailto:brian.stansberry@redhat.com
> <mailto:brian.stansberry@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> <mailto:wildfly-dev@lists.jboss.org
> <mailto:wildfly-dev@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> <mailto:wildfly-dev@lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:59 a.m.
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(a)redhat.com
>> <mailto:smarlow@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(a)redhat.com
>> <mailto:brian.stansberry@redhat.com>
>> <mailto:brian.stansberry@redhat.com
>> <mailto:brian.stansberry@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(a)lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>
>> <mailto:wildfly-dev@lists.jboss.org
>> <mailto:wildfly-dev@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(a)lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>
>> <mailto:wildfly-dev@lists.jboss.org
>> <mailto:wildfly-dev@lists.jboss.org>>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
10:56 a.m.
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(a)redhat.com
<mailto:smarlow@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(a)redhat.com <mailto:brian.stansberry@redhat.com>
<mailto:brian.stansberry@redhat.com
<mailto:brian.stansberry@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:06 a.m.
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 <smarlow(a)redhat.com
<mailto:smarlow@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(a)redhat.com <mailto:brian.stansberry@redhat.com>
<mailto:brian.stansberry@redhat.com
<mailto:brian.stansberry@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
<mailto:wildfly-dev@lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:12 p.m.
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.
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#WriteConce...
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
2873
days inactive
2877
days old
13 comments
5 participants
participants (5)
-
Brian Stansberry -
Darran Lofthouse -
Gunnar Morling -
Jesper Pedersen -
Scott Marlow