Previously, if a property name had successive capital letters, the
generated meta-data would clean it in such a way it is defined as a
regular word. For instance a `myFOO` property would be written as
`my-foo` in the meta-data.
It turns out this decision is wrong as the binder has no way to compute
back the name of the property and therefore `my-foo` wouldn't bind to
`setMyFOO` as it should.
This commit updates the meta-data name generation algorithm to properly
identify such cases: `myFOO` now translates to `my-f-o-o`. While the
generated name is a bit ugly, it now provides a consistent binding
experience.
Closes gh-5330
This commit detects case where the same set of keys are exposed several
times and prevents the compilation to complete. Previously, duplicate
keys were silently added to the meta-data.
Closes gh-5939
Update TypeUtils to guard against the use of older Java versions.
Both `Collection` and `Map` type lookups now fallback to generic free
versions of the classes.
Prior to this commit using `xmlbeans-maven-plugin` in combination with
Spring Boot's annotation processor could result in
`IllegalArgumentException: Incorrect number of type arguments`.
Fixes gh-6122
Previously, if a void method with a single argument was named "set", the
annotation processor wrongly considered it was a setter candidate. This
commit updates the condition to ignore it.
Closes gh-5826
Previously, the meta-data annotation processor was taking the first
setter that match the property name it has to handle. Contrary to
getters that are enforced by a return type (no argument), multiple
setter candidates may exist.
If a property's type got narrowed over time, the original setter may
have been marked as Deprecated. As the annotation processor takes the
first setter that matches based on the name only, it may pick up the
deprecated one and therefore mark the property as being (wrongly)
deprecatede in the meta-data.
It turns out that checking for the actual type of the setter parameter
brought a side effect: some primitive properties may use the primitive
or the Wrapper counter part. This commit not only look at the proper
setter based on the type but also fallback on the wrapper (or) primitive
if necessary.
Closes gh-4338
Previously, manual meta-data were added to the existing set of entries
which could lead to duplicates if a manual entry is meant to complement
a property that is detected via the processor.
We now match the name and type of the item against the auto-detected
entries. If no match is found, we add the extra entry as we did before.
If a match is found we override the description, default value and
deprecation information.
Closes gh-3562
The annotation processor detects `@ConfigurationProperties` bean or
method definition and merges manual meta-data. The former step will fail
with a NPE if the annotation is not present on the classpath. This could
happen if the annotation processor is added to a module that is not
actually using Spring Boot.
We now have a defensive check that skips that steps but still attempts to
merge manual meta-data if present.
Closes gh-3720
Add a new @DeprecatedConfigurationProperties annotation which can be
used by the `ConfigurationMetadataAnnotationProcessor` to generating
meta-data deprecated blocks.
Fixes gh-3543
Previously, an item could only have a 'deprecated' boolean flag to
indicate that the property is deprecated. It is desirable to provide an
additional description for the deprecation as well as the name of the
property to use instead.
The `deprecated` boolean flag is now supported. Instead, a `deprecated`
object can be specified with two optional attributes: `reason` to provide
an explanation for the deprecation and `replacement` to refer to the
property that should be used instead. If none of them is present, an
empty deprecation object should be set.
For backward compatibility, the `deprecated` field is still set.
Deprecation information can only set via manual meta-data.
Closes gh-3449
Phillip Webb
Stephane Nicoll
Johnny Lim
Andy Wilkinson
arghya88