Spring/spring-data-geode
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

DATAGEODE-140 - Correct Pool references in 'Runtime configuration using Properties' documentation.

Browse Source
This commit is contained in:
John Blum
2018-08-17 22:25:22 -07:00
parent b2f10c5368
commit 535b9d4be0
1 changed files with 12 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
src/main/asciidoc/reference/bootstrap-annotations.adoc
View File

@@ -357,9 +357,9 @@ However, `Configurers` are not the only option.
[[bootstrap-annotation-config-properties]]
== Runtime configuration using `Properties`
In addition to `Configurers`, each annotation attribute in the annotation-based configuration model is associated
with a corresponding configuration property (prefixed with `spring.data.gemfire.`), which can be declared in a
Spring Boot `application.properties` file.
In addition to `Configurers`, each annotation attribute in the annotation-based configuration model is associated with
a corresponding configuration property (prefixed with `spring.data.gemfire.`), which can be declared in a Spring Boot
`application.properties` file.
Building on the earlier examples, the client's `application.properties` file would define the following
set of properties:
@@ -424,9 +424,9 @@ class ServerApplication { .. }
----
The preceding example shows why it is important to "name" your annotation-based beans (other than because it is required
in certain cases). Doing so makes it possible to reference the bean in a Spring context from XML, properties,
and Java. It is even possible to inject annotation-defined beans into an application class,
for whatever purpose, as the following example demonstrates:
in certain cases). Doing so makes it possible to reference the bean in the Spring container from XML, properties,
and Java. It is even possible to inject annotation-defined beans into an application class, for whatever purpose,
as the following example demonstrates:
[source, java]
----
@@ -456,19 +456,18 @@ spring.data.gemfire.cache.server.Saturn...
spring.data.gemfire.cache.server.Neptune...
----
While there are three named `CacheServers` above, there is one unnamed `CacheServer` property providing the default
value for any unspecified value for that property, even for "named" `CacheServers`. So, while "Venus" sets
and overrides its own `bind-address`, "Saturn" and "Neptune" inherit from the "unnamed"
While there are three named `CacheServers` above, there is also one unnamed `CacheServer` property providing
the default value for any unspecified value of that property, even for "named" `CacheServers`. So, while "Venus"
sets and overrides its own `bind-address`, "Saturn" and "Neptune" inherit from the "unnamed"
`spring.data.gemfire.cache.server.bind-address` property.
See an annotation's Javadoc for which annotation attributes support property-based configuration and whether
they support "named" properties over default, "unnamed" properties.
See an annotation's Javadoc for which annotation attributes support property-based configuration
and whether they support "named" properties over default, "unnamed" properties.
[[bootstrap-annotation-config-properties-of-properties]]
=== `Properties` of `Properties`
In the usual Spring fashion, you can even express `Properties` in terms of other `Properties`, whether that is
by using a Spring Boot `application.properties` file or by using the `@Value` annotation in your Java configuration class.
In the usual Spring fashion, you can even express `Properties` in terms of other `Properties`, whether that is by
The following example shows a nested property being set in an `application.properties` file:
.Properties of Properties