Consider renaming "spring.datasource.decorator" configuration namespace

[snicoll]

As explained in the documentation we'd like 3rd party starters not to use the configuration prefixes Spring Boot uses (spring.* being the most obvious one).

[gavlyukovskiy]

Hi, I have removed spring.* from my properties in e1b52b9.
Old ones will still be resolved with printing warning in the log.

[snicoll]

Sorry, but I am not sure that's better. Why have you removed the spring.datasource.tomcat and spring.datasource.hikari from your doc? Assuming you are using the auto-configuration of Spring Boot, these are perfectly valid properties, aren't they?

Chopping of spring is definitely not what I have in mind. The rationale behind the doc is as follows:

1. Do not name your modules with a spring-boot prefix as this influences the default name of the jar and we want to clearly separate core support from third party one. There is a similar initiative in Apache Maven for instnace
2. Do not use our configuration namespace as a future version of Spring Boot might use that name and break your things.

For point 2, the idea is that you need to find a name that is specific enough to what you're doing. I agree it's a bit though to find one for "datasource decorator". Perhaps you can find a code name for the project and use that as a prefix? "spring-boot-datasource-decorator" is very generic on its own actually.

datasource.* is very generic. I might expect an app to use that so I don't think it's a good candidate. Can you please reconsider this? Let me know if you have any question!

[gavlyukovskiy]

Sorry, but I am not sure that's better. Why have you removed the spring.datasource.tomcat and spring.datasource.hikari from your doc? Assuming you are using the auto-configuration of Spring Boot, these are perfectly valid properties, aren't they?

My mistake, I used replace by whole readme

Do not name your modules with a spring-boot prefix as this influences the default name of the jar and we want to clearly separate core support from third party one. There is a similar initiative in Apache Maven for instnace

All my modules doesn't have such prefix, only github repository, but this one I cannot easily change.

datasource.* is very generic. I might expect an app to use that so I don't think it's a good candidate. Can you please reconsider this?

I tried to follow spring convention here, spring.datasource.* means jdbc datasource I'm trying to keep same naming. Did you mean case when someone has @ConfigurationProperies(value = "datasource", ignoreUnknownProperties = false) for some bean? What do you suggest, maybe decorator.datasource? Decorator is not often used I think.

[snicoll]

All my modules doesn't have such prefix, only github repository, but this one I cannot easily change.

I know you don't, I was giving a full picture of the rationale behind that part of the doc.

Did you mean case when someone has @ConfigurationProperies(value = "datasource", ignoreUnknownProperties = false) for some bean?

Yes.

What do you suggest, maybe decorator.datasource? Decorator is not often used I think.

I already suggested something: "Perhaps you can find a code name for the project and use that as a prefix?". decorator.datasource is another idea. "Decorator" doesn't resonate much but I have nothing better to offer which is why I think a codename for the project would help.

Having said that, it's up to you really.

[gavlyukovskiy]

I can't сome up with project code name, so I changed prefix todecorator.datasource, it's not that popular I think. If someone will encounter an issue with that I will think how to fix it :)