CassandraAutoconfiguration leads to ignored parameters in db-config.conf

[nilsvillwock]

We are using the cassandra driver specific configuration file db-config.conf via the property:

spring:
  data:
    cassandra:
      config: file:/db-config.conf

The problem now is that even when I do not define further spring-boot CassandraProperties in the yaml, there are default values already set and these properties are ignored in the db-config.conf. file. The reason seem to be, because the db-config.conf properties are loaded as fallback after the default spring boot CassandraProperties. Spring Boot CassandraProperties should win, but only if they are actively set.

The following Cassandra properties always initialized and so always ignored in db-config.conf

[snicoll]

@philwebb I can see you've flagged this as a bug but the current behavior is the expected behavior, see https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#data.nosql.cassandra.connecting. Perhaps the documentation should be more explicit that a default value counts as a value being present.

@nilsvillwock the purpose of the config property is to let define properties that the Spring Boot namespace does not support.

[nilsvillwock]

OK, please adjust the documentation from:

If a property is both present in spring.data.cassandra.* and the configuration file, the value in spring.data.cassandra.* takes precedence.

to:

If a property is both present (even it is only by default) in spring.data.cassandra.* and the configuration file, the value in spring.data.cassandra.* takes precedence.

[snicoll]

We've discussed this at the team meeting and we come to realize that it was supposed to work as expected (see #24065). The problem is that some properties were overlooked, typically the ones that have a primitive type (and a default value of 0).

@nilsvillwock it would be good to list the properties that you tried to define in db-config.conf that did not work.

[nilsvillwock]

@snicoll
The properties which are ignored in the db-config file are the ones you can see at the screenshot in my initial post

[ittays]

I looked into the issue, and started to write a solution. My general approach is here: ittays@f09e2b3

As I wrote there on the commit message, there are two changes required: one is removing primitives from CassandraProperties in favor of nullable-values.
The second is splitting the spring.data.cassandra.* from the hard-coded values, as the latter has lower precedence.

It is still not complete, as introducing the nullable CassandraProperties fields requires adding null-handling flows (especially for port and ssl).

In addition, I'm not sure about where to locate the separated values. I defined a defaults() static method on CassandraProperties, but his doesn't feel right.

---

Last but not least, I found a significant flow which requires an additional thought: when contact-points values are configured without a port, but an actual port is defined on a different config layer. What is the expected behavior?

Consider both cases when, say, system properties define the port and cassandra.config defines the host, and vice versa. What should we expect to happen? Should the port from one config layer be considered along with the port from the other (higher/lower) layer?

Today the host:port construction happens on the layer-level. I think a better approach is do defer the construction to the point where all layers are combined already.

[ittays]

Can you please look into my PR?
Eventually, to simplify the port configuration, I preferred not to defer the contact-points config, and not to cross-use a host from one config layer and a port from another.

[snicoll]

@ittays there's no need to ask us to do that. The whole team already received a notification when you created the PR.

[philwebb]

Closing in favor of PR #31238. Thanks @ittays!