-
Notifications
You must be signed in to change notification settings - Fork 41.1k
spring.datasource.dbcp2.username and spring.datasource.dbcp2.password are incorrectly marked as deprecated #40076
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@wilkinsona Is the solution to this problem to modify these two configurations in
|
|
@quaff Sorry, it was my mistake. It is automatically generated. Is it possible to solve this issue by upgrading dbcp2 to 2.11.0? |
It's actually false positive reported by spring boot, nothing related to dbcp2. |
@quaff OK, I understand, thanks for your answer. |
We're going to look at a fix that focuses only on the DBCP2 properties for now at least. We don't think we can change to requiring the setter to be deprecated as it would be a breaking change. |
We bind
spring.datasource.dbcp2
to third-party code, namelyorg.apache.commons.dbcp2.BasicDataSource
.getUsername
andgetPassword
onBasicDataSource
have been marked as deprecated butsetUsername
andsetPassword
have not. For configuration property binding purposes this means that they are not deprecated – the binder only need to call the setters – but the generated metadata states that they are deprecated.I think there's a general problem here and this is a specific symptom of that problem. The problem is that a getter being deprecated is sufficient for a configuration property to be flagged as deprecated. For a scalar property, I think we should consider requiring the setter to be deprecated before flagging the property as deprecated. For maps, lists, and nested properties, a deprecated getter is probably sufficient signal as the binder needs to use the getter to retrieve any existing value.
Flagging for discussion in a team meeting to decide if and where we should fix this. Given that it's a more general problem, we may want to apply a fix in 3.1.x.
The text was updated successfully, but these errors were encountered: