Consistent use of tabs for sample code in the reference documentation
This commit is contained in:
@@ -309,23 +309,23 @@ Typically, such configuration will live in a ".groovy" file with a structure as
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
beans {
|
||||
dataSource(BasicDataSource) {
|
||||
driverClassName = "org.hsqldb.jdbcDriver"
|
||||
url = "jdbc:hsqldb:mem:grailsDB"
|
||||
username = "sa"
|
||||
password = ""
|
||||
settings = [mynew:"setting"]
|
||||
}
|
||||
sessionFactory(SessionFactory) {
|
||||
dataSource = dataSource
|
||||
}
|
||||
myService(MyService) {
|
||||
nestedBean = { AnotherBean bean ->
|
||||
dataSource = dataSource
|
||||
}
|
||||
}
|
||||
}
|
||||
beans {
|
||||
dataSource(BasicDataSource) {
|
||||
driverClassName = "org.hsqldb.jdbcDriver"
|
||||
url = "jdbc:hsqldb:mem:grailsDB"
|
||||
username = "sa"
|
||||
password = ""
|
||||
settings = [mynew:"setting"]
|
||||
}
|
||||
sessionFactory(SessionFactory) {
|
||||
dataSource = dataSource
|
||||
}
|
||||
myService(MyService) {
|
||||
nestedBean = { AnotherBean bean ->
|
||||
dataSource = dataSource
|
||||
}
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
This configuration style is largely equivalent to XML bean definitions and even
|
||||
@@ -373,7 +373,7 @@ delegates, e.g. with `XmlBeanDefinitionReader` for XML files:
|
||||
----
|
||||
GenericApplicationContext context = new GenericApplicationContext();
|
||||
new XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml");
|
||||
context.refresh();
|
||||
context.refresh();
|
||||
----
|
||||
|
||||
Or with `GroovyBeanDefinitionReader` for Groovy files:
|
||||
@@ -383,7 +383,7 @@ Or with `GroovyBeanDefinitionReader` for Groovy files:
|
||||
----
|
||||
GenericApplicationContext context = new GenericApplicationContext();
|
||||
new GroovyBeanDefinitionReader(context).loadBeanDefinitions("services.groovy", "daos.groovy");
|
||||
context.refresh();
|
||||
context.refresh();
|
||||
----
|
||||
|
||||
Such reader delegates can be mixed and matched on the same `ApplicationContext`,
|
||||
@@ -1685,7 +1685,7 @@ The preceding example is equivalent to the following Java code:
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
exampleBean.setEmail("")
|
||||
exampleBean.setEmail("")
|
||||
----
|
||||
|
||||
The `<null/>` element handles `null` values. For example:
|
||||
@@ -3822,7 +3822,6 @@ Find below the custom `BeanPostProcessor` implementation class definition:
|
||||
package scripting;
|
||||
|
||||
import org.springframework.beans.factory.config.BeanPostProcessor;
|
||||
import org.springframework.beans.BeansException;
|
||||
|
||||
public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {
|
||||
|
||||
@@ -5400,7 +5399,7 @@ comma/semicolon/space-separated list that includes the parent package of each cl
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example")
|
||||
public class AppConfig {
|
||||
...
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
@@ -5511,12 +5510,12 @@ and using "stub" repositories instead.
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example",
|
||||
includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Stub.*Repository"),
|
||||
excludeFilters = @Filter(Repository.class))
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
@ComponentScan(basePackages = "org.example",
|
||||
includeFilters = @Filter(type = FilterType.REGEX, pattern = ".*Stub.*Repository"),
|
||||
excludeFilters = @Filter(Repository.class))
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
and the equivalent using XML
|
||||
@@ -5746,10 +5745,10 @@ fully-qualified class name when configuring the scanner:
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example", nameGenerator = MyNameGenerator.class)
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
@ComponentScan(basePackages = "org.example", nameGenerator = MyNameGenerator.class)
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
[source,xml,indent=0]
|
||||
@@ -5803,8 +5802,8 @@ fully-qualified class name when configuring the scanner:
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example", scopeResolver = MyScopeResolver.class)
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
[source,xml,indent=0]
|
||||
@@ -5828,8 +5827,8 @@ the following configuration will result in standard JDK dynamic proxies:
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example", scopedProxy = ScopedProxyMode.INTERFACES)
|
||||
public class AppConfig {
|
||||
...
|
||||
}
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
[source,xml,indent=0]
|
||||
@@ -6144,7 +6143,7 @@ exact same way as when using Spring annotations:
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "org.example")
|
||||
public class AppConfig {
|
||||
...
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
@@ -6374,7 +6373,7 @@ To enable component scanning, just annotate your `@Configuration` class as follo
|
||||
@Configuration
|
||||
@ComponentScan(basePackages = "com.acme")
|
||||
public class AppConfig {
|
||||
...
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
@@ -6693,7 +6692,7 @@ method directly during construction:
|
||||
public Foo foo() {
|
||||
Foo foo = new Foo();
|
||||
foo.init();
|
||||
return foo;
|
||||
return foo;
|
||||
}
|
||||
|
||||
// ...
|
||||
@@ -7011,7 +7010,7 @@ another configuration class:
|
||||
@Configuration
|
||||
public class ConfigA {
|
||||
|
||||
@Bean
|
||||
@Bean
|
||||
public A a() {
|
||||
return new A();
|
||||
}
|
||||
@@ -8681,18 +8680,18 @@ environment provides:
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
public class EntityCreatedEvent<T>
|
||||
extends ApplicationEvent implements ResolvableTypeProvider {
|
||||
extends ApplicationEvent implements ResolvableTypeProvider {
|
||||
|
||||
public EntityCreatedEvent(T entity) {
|
||||
super(entity);
|
||||
}
|
||||
public EntityCreatedEvent(T entity) {
|
||||
super(entity);
|
||||
}
|
||||
|
||||
@Override
|
||||
public ResolvableType getResolvableType() {
|
||||
return ResolvableType.forClassWithGenerics(getClass(),
|
||||
ResolvableType.forInstance(getSource()));
|
||||
}
|
||||
}
|
||||
@Override
|
||||
public ResolvableType getResolvableType() {
|
||||
return ResolvableType.forClassWithGenerics(getClass(),
|
||||
ResolvableType.forInstance(getSource()));
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
[TIP]
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
[[databuffers]]
|
||||
= Data Buffers and Codecs
|
||||
|
||||
|
||||
|
||||
|
||||
== Introduction
|
||||
|
||||
The `DataBuffer` interface defines an abstraction over byte buffers.
|
||||
@@ -9,6 +12,9 @@ Netty does not use `ByteBuffer`, but instead offers `ByteBuf` as an alternative.
|
||||
Spring's `DataBuffer` is a simple abstraction over `ByteBuf` that can also be used on non-Netty
|
||||
platforms (i.e. Servlet 3.1+).
|
||||
|
||||
|
||||
|
||||
|
||||
== `DataBufferFactory`
|
||||
|
||||
The `DataBufferFactory` offers functionality to allocate new data buffers, as well as to wrap
|
||||
@@ -25,6 +31,9 @@ to be used on Netty platforms, such as Reactor Netty.
|
||||
The other implementation, the `DefaultDataBufferFactory`, is used on other platforms, such as
|
||||
Servlet 3.1+ servers.
|
||||
|
||||
|
||||
|
||||
|
||||
== The `DataBuffer` interface
|
||||
|
||||
The `DataBuffer` interface is similar to `ByteBuffer`, but offers a number of advantages.
|
||||
@@ -35,7 +44,7 @@ writing, and a separate `flip()` operation to switch between the two I/O operat
|
||||
In general, the following invariant holds for the read position, write position, and the capacity:
|
||||
|
||||
--
|
||||
`0` <= _read position_ <= _write position_ <= _capacity_
|
||||
`0` <= _read position_ <= _write position_ <= _capacity_
|
||||
--
|
||||
|
||||
When reading bytes from the `DataBuffer`, the read position is automatically updated in accordance with
|
||||
@@ -54,6 +63,8 @@ Netty platforms, such as Reactor Netty.
|
||||
The other implementation, the `DefaultDataBuffer`, is used on other platforms, such as Servlet 3.1+
|
||||
servers.
|
||||
|
||||
|
||||
|
||||
=== `PooledDataBuffer`
|
||||
|
||||
The `PooledDataBuffer` is an extension to `DataBuffer` that adds methods for reference counting.
|
||||
@@ -67,6 +78,7 @@ buffers.
|
||||
These methods take a plain `DataBuffer` as parameter, but only call `retain` or `release` if the
|
||||
passed data buffer is an instance of `PooledDataBuffer`.
|
||||
|
||||
|
||||
[[databuffer-reference-counting]]
|
||||
==== Reference Counting
|
||||
|
||||
@@ -95,23 +107,25 @@ throw exceptions:
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
DataBufferFactory factory = ...
|
||||
DataBuffer buffer = factory.allocateBuffer(); <1>
|
||||
boolean release = true; <2>
|
||||
try {
|
||||
writeDataToBuffer(buffer); <3>
|
||||
putBufferInHttpBody(buffer);
|
||||
release = false; <4>
|
||||
} finally {
|
||||
if (release) {
|
||||
DataBufferUtils.release(buffer); <5>
|
||||
}
|
||||
}
|
||||
DataBufferFactory factory = ...
|
||||
DataBuffer buffer = factory.allocateBuffer(); <1>
|
||||
boolean release = true; <2>
|
||||
try {
|
||||
writeDataToBuffer(buffer); <3>
|
||||
putBufferInHttpBody(buffer);
|
||||
release = false; <4>
|
||||
}
|
||||
finally {
|
||||
if (release) {
|
||||
DataBufferUtils.release(buffer); <5>
|
||||
}
|
||||
}
|
||||
|
||||
private void writeDataToBuffer(DataBuffer buffer) throws IOException { <3>
|
||||
...
|
||||
}
|
||||
private void writeDataToBuffer(DataBuffer buffer) throws IOException { <3>
|
||||
...
|
||||
}
|
||||
----
|
||||
|
||||
<1> A new buffer is allocated.
|
||||
<2> A boolean flag indicates whether the allocated buffer should be released.
|
||||
<3> This example method loads data into the buffer. Note that the method can throw an `IOException`,
|
||||
@@ -121,6 +135,8 @@ released as part of sending the HTTP body across the wire.
|
||||
<5> If an exception did occur, the flag is still set to `true`, and the buffer will be released
|
||||
here.
|
||||
|
||||
|
||||
|
||||
=== DataBufferUtils
|
||||
|
||||
`DataBufferUtils` contains various utility methods that operate on data buffers.
|
||||
@@ -129,6 +145,9 @@ It contains methods for reading a `Flux` of `DataBuffer` objects from an `InputS
|
||||
`DataBufferUtils` also exposes `retain` and `release` methods that operate on plain `DataBuffer`
|
||||
instances (so that casting to a `PooledDataBuffer` is not required).
|
||||
|
||||
|
||||
|
||||
|
||||
[codecs]
|
||||
== Codecs
|
||||
|
||||
|
||||
@@ -444,8 +444,8 @@ this:
|
||||
----
|
||||
com/
|
||||
foo/
|
||||
services.xml
|
||||
daos.xml
|
||||
services.xml
|
||||
daos.xml
|
||||
MessengerService.class
|
||||
----
|
||||
|
||||
|
||||
Reference in New Issue
Block a user