* use Maven modules to do so
* spring-cloud-bindings goes one level down
* addition of a spring-cloud-bindings parent
Inspired by @gregturn and spring-data-rest
* Adding logic to flex the MySQL jdbc and r2dbc connection sting based on classpath
This PR is related to issue #72.
Co-authored-by: gm2552 <meyerg@vmware.com>
Previously, the library utilized an API from Spring Boot that arrived in
2.1.0. Support for Spring Boot 2.0 compatibility was requested and we can
trivially add that support even though Boot 2.0 is EOL. This change updates
the use of the API to be Boot 2.0 compatible.
Signed-off-by: Ben Hale <bhale@vmware.com>
This change updates the name of the artifact so that it's more descriptive and
aligns with other Spring Cloud projects.
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously, the implementations of the EnvironmentPostProcessors added
ApplicationEventListener to their interface as well. These implementations
tested fine, but of course since there was no full integration test to ensure
that they were registered I forgot to add them to spring.factories.
This change adds their declarations as ApplicationEventListeners to the
spring.factories file and ensures that the logs are replayed when the
application is finished preparing.
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously all of the guard behavior was triggered by the contents of
environment variables. In a Spring Boot application, looking at the
environment isn't the only way to get configuration. This change updates the
guards to use the Environment for configuration retrieval.
[resolves#30]
Signed-off-by: Ben Hale <bhale@vmware.com>
Another common way to use bindings, even without auto-configuration is to
refer to them in a flattened form within other properties. An example would be
`spring.datasource.password=cnb.bindings.my-db.secret.password`. This change
adds an EnvironmentPostProcessor that contributes these flattened bindings in
a PropertySource.
[resolves#24]
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously, auto-configuration of all kinds of bindings were either enabled or
disabled en-mass. This level of granularity wasn't really appropriate in
practice as it many use-cases could be served with some bindings but not
others. This change updates each auto-configuration to watch for a particular
key to be disabled.
[resolves#29]
Signed-off-by: Ben Hale <bhale@vmware.com>
* Simplify name from CnbBindings (a convention that makes my eyes bleed) so
that you aren't stuttering. I'm still a bit undecided on the naming of the
modules themselves as well.
* Documentation, documentation, documentation!
* Lots of the final keyword. Prevents unanticipated modification via extension.
* Constructor/Method overloading allows you to isolate the behaviors that are
really hard to test. Note that I've isolated everything that needs to read
from the environment and feel confident that the methods that include it are
so trivial they're not worth testing. Some overloads are non-public to enable
testing but not later usage.
* Since this is a public API, I'm being really verbose with the nullability
annotations. Most of the time you wouldn't use them, by they do make IDE
users' lives better.
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously there was a lot of cruft in the POM file that related to previous
examples of this library. When in doubt, trust Boot's opinions and minimize
your POM's as much as possible. We can always add it back in the future.
Signed-off-by: Ben Hale <bhale@vmware.com>
