Previously Spring Cloud Bindings always composed spring.datasource.url from the host port and database properties. This is limiting in that it does not provide a mechanism for users to specify jdbc properties (e.g. sslMode). The PR retains the original behavior but also respects jdbc-url and r2dbc-url keys in all RDBS bindings. The explicit jdbc-url and r2dbc-url keys take precedence over the composed value.
Signed-off-by: Emily Casey <ecasey@vmware.com>
Spring Boot properties for MongoDB auto-configuration should have the
prefix `spring.data.mongodb` instead of `spring.mongodb`.
Signed-off-by: Scott Frederick <sfrederick@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>
Previously the code looked for SERVICE_BINDING_ROOT. Given that the
specification states it should be SERVICE_BINDINGS_ROOT, this was wrong. This
change fixes it.
Signed-off-by: Ben Hale <bhale@vmware.com>
This changes makes a bunch documentation improvements, case normalizations,
and general improvements left over from the previous addition of the
Kubernetes Service Binding support.
Signed-off-by: Ben Hale <bhale@vmware.com>
When key names are potentially ambiguous (does this server-id refer to the vault server?) prefer longer more explicit key names. When there is no ambiguity stick with the existing shorter names.
Signed-off-by: Emily Casey <ecasey@vmware.com>
Autoconfigures spring.security.oauth2.* application properties. The name of the binding will become the name of the client. The name of the provider will be taken from metadata/provider.
Resolves#35
Signed-off-by: Emily Casey <ecasey@pivotal.io>
When a binding is provided as a mounted ConfigMap/Secret pair (containing
metadata and secret values respectively) the files within the metadata and
secret directories will be symlinks to files in a colocated hidden directory
that contains the content. In order to handle bindings presented in this
format a Binding object will ignore hidden files and directories when it is
contructed using a path. This prevents errors that previously occured
when the Binding assumed all metadata and secret entries were regular files, and
attempted to read the content of those directories directly.
Resolves#40
Signed-off-by: Emily Casey <ecasey@pivotal.io>
Adds r2dbc properties for mysql, postgres, sqlserver, oracle, and db2
bindings. This allow bindings to be used with reactive drivers.
Signed-off-by: Emily Casey <ecasey@pivotal.io>
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 the logging put out by the library happened synchronously with the
code executing. Because this library typically runs so early in the Spring
Boot lifecycle that logging isn't yet configured, it needs to defer that
logging until later.
This change converts the library to use Boot's DeferredLogger and listen for
an ApplicationPrepared event before logging out its messages.
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously the PutIfPresent API was a clunky way of only setting a property in
the PropertySource if the corresponding entry from the binding existed. It
was pointed out in #31 that there are better APIs for doing this same thing.
Unfortunately the suggestion in that issue wasn't suitable (it was built for
beans not maps), but it did inspire a better API that was suited to maps.
This change implements that new API.
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>
This was missed during the implementation. The broader integration test that
should have caught this will come in #33.
[resolves#32]
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, whenever the library was included on a classpath it would attempt
to auto-configure Spring Boot. Since part of the API can be used as a
straight library, and in that usage, auto-configuration would not be
desirable, the auto-configuration needed a global off switch. This change
adds a global guard, disabled by default, in the
org.springframework.cloud.bindings.boot.enable System Property.
[resolves#25]
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>
