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>
This change adds a README file containing information about using the project
and the properties that are set automatically.
[resolves#2]
Signed-off-by: Ben Hale <bhale@vmware.com>
Previously, the Boot-specific processors were in the same package as the core
types. This minimzed the visibility of some constructors used for testing,
but as the list of processors has grown (and will continue to grow), the core
types were being overwhelmed.
This change moves the Boot-specific processors out to an additional package
where they can be easily identified.
Signed-off-by: Ben Hale <bhale@vmware.com>
