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

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&gt;: