datastax
[JAVA-2697] Map other basic settings in Quarkus settings mechanism
Imported from [JAVA-2697](https://datastax-oss.atlassian.net/browse/JAVA-2697), originally reported by @tomekl007 on Thu, 19 Mar 2020 09:09:44 GMT.
[https://datastax-oss.atlassian.net/browse/JAVA-2682](https://datastax-oss.atlassian.net/browse/JAVA-2682) implemented mechanism for propagating settings from quarkus to java-driver.
In this ticket. we should go through all the required settings and map them in a similar way.
We should map only important settings like SSL, cloud. The user still can use application.conf to configure all underlying java-driver settings.
See docs about including resources:
[https://quarkus.io/guides/writing-native-applications-tips](https://quarkus.io/guides/writing-native-applications-tips)
We should decide which settings can be moved to deployment (they will be static once constructed so cannot be reload on the runtime)
┆Issue is synchronized with this Jira Task by Unito
Imported from JAVA-2697, originally commented by @tomekl007 on Thu, 26 Mar 2020 07:52:59 GMT.
There is a discussion about settings:
https://github.com/quarkusio/quarkus/issues/7876#issuecomment-603773398
So look at the runtime configs you have and think whether you could prepare the driver at build time and load less class at runtime time if you could freeze the config to build time immutable. And then look how loud people complain. Shake it and make your choice
We tend to put stuff aggressively at build time and backup as needed.I don't know the extend of the Cassandra config but:
- IP, url, username, password and definitely runtime
- loadbanancer policy, cypher suite, etc (involving a piece of code switch in the driver) could be made build time
We can go over them specifically.
Speaking of properties, we have done the following in a few frameworks:
- change some defaults to better match usage in Quarkus
- exposed less properties than typical drivers offer also focusing on the main usages
@olim7t here we can discuss and propose which settings (if any?) can be moved to deployment.
The good solution may be to move all settings that have:
# Overridable in a profile: no
in the reference.conf to deployment module (and CassandraClientBuildTimeConfig)
Imported from JAVA-2697, originally commented by @adutra on Thu, 2 Apr 2020 13:59:10 GMT.
Now that we have https://datastax-oss.atlassian.net/browse/JAVA-2600 we could investigate if we shouldn’t get rid of TypeSafe Config completely.
Imported from JAVA-2697, originally commented by @absurdfarce on Wed, 22 Apr 2020 16:42:29 GMT.
Worth noting: the Quarkus docs around writing your own extension suggest moving as much as possible to application.properties and avoiding additional configs if possible. This from https://quarkus.io/guides/writing-extensions:
“To make the simple experience easiest, unify the configuration in application.properties via MicroProfile Config. Avoid library specific configuration files, or at least make them optional: e.g. persistence.xml for Hibernate ORM is optional.”
Imported from JAVA-2697, originally commented by @tomekl007 on Thu, 23 Apr 2020 06:37:10 GMT.
Yes, we were discussing that already, and I think that the best approach is to keep the hybrid approach: The main settings are in the main application.properties and the application.conf is only an optional mechanism for setting every property. From our experience of working with dsbulk and Kafka connector, we started with exposing only a subset of the most important settings and it was not enough. We needed to add the mechanism afterward so I think we should stick to it for our extension.
I think only SSL is missing now, plain text auth has been added in #73 and cloud in #94.