root
/
spring-boot
mirror of https://github.com/spring-projects/spring-boot.git
1
0
Fork 0
Code Issues Actions 12 Packages Projects Releases Wiki Activity

Enhance some docs and add content to READMEs

This commit is contained in:
Dave Syer 2013-07-19 17:30:45 +01:00
parent 90c942387f
commit 944fd4f4b8
8 changed files with 512 additions and 322 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
spring-actuator/README.md
View File

@ -1,8 +1,9 @@
# Spring Zero Actuator # Spring Zero Actuator
Minimum fuss for getting applications up and running in production, The aim of this project is minimum fuss for getting applications up
and in other environments. There is a strong emphasis on implementing and running in production, and in other environments. There is a
RESTful web services but many features are more generic than that. strong emphasis on implementing RESTful web services but many features
are more generic than that.
|Feature |Implementation |Notes | |Feature |Implementation |Notes |
|---|---|---| |---|---|---|
@ -24,7 +25,7 @@ RESTful web services but many features are more generic than that.
For a quick introduction and to get started quickly with a new For a quick introduction and to get started quickly with a new
project, carry on reading. For more in depth coverage of the features project, carry on reading. For more in depth coverage of the features
of Spring Zero Actuator, go to the of Spring Zero Actuator, go to the
[Feature Guide](https://github.com/SpringSource/spring-bootstrap/tree/master/spring-zero-actuator/docs/Features.md). [Feature Guide](docs/Features.md).
# Getting Started # Getting Started
@ -48,24 +49,24 @@ If you are using Maven create a really simple `pom.xml` with 2 dependencies:
<packaging>jar</packaging> <packaging>jar</packaging>
<parent> <parent>
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>spring-zero-starter</artifactId> <artifactId>spring-starter-parent</artifactId>
<version>0.0.1-SNAPSHOT</version> <version>{{project.version}}</version>
</parent> </parent>
<dependencies> <dependencies>
<dependency> <dependency>
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>spring-zero-web-starter</artifactId> <artifactId>spring-starter-web</artifactId>
</dependency> </dependency>
<dependency> <dependency>
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>spring-zero-service</artifactId> <artifactId>spring-starter-actuator</artifactId>
</dependency> </dependency>
</dependencies> </dependencies>
<build> <build>
<plugins> <plugins>
<plugin> <plugin>
<groupId>org.apache.maven.plugins</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>maven-shade-plugin</artifactId> <artifactId>spring-package-maven-plugin</artifactId>
</plugin> </plugin>
</plugins> </plugins>
</build> </build>
@ -73,38 +74,11 @@ If you are using Maven create a really simple `pom.xml` with 2 dependencies:
If you like Gradle, that's fine, and you will know what to do with If you like Gradle, that's fine, and you will know what to do with
those dependencies. The first dependency adds Spring Zero auto those dependencies. The first dependency adds Spring Zero auto
configuration and the Jetty container to your application, and the configuration and the Tomcat container to your application, and the
second one adds some more opinionated stuff like the default second one adds some more opinionated stuff like the default
management endpoints. If you prefer Tomcat you can just add the management endpoints. If you prefer Jetty you can just add the
embedded Tomcat jars to your classpath instead of Jetty. embedded Jetty jars to your classpath instead of Tomcat (once you
exclude the `spring-starter-tomcat` dependency).
You should be able to run it already:
$ mvn package
$ java -jar target/myproject-1.0.0-SNAPSHOT.jar
Then in another terminal
$ curl localhost:8080/health
ok
$ curl localhost:8080/metrics
{"counter.status.200.health":1.0,"gauge.response.health":10.0,"mem":120768.0,"mem.free":105012.0,"processors":4.0}
`/health` is the default location for the health endpoint - it tells
you if the application is running and healthy. `/metrics` is the default
location for the metrics endpoint - it gives you basic counts and
response timing data by default but there are plenty of ways to
customize it. You can also try `/trace` and `/dump` to get some
interesting information about how and what your app is doing.
What about the home page?
$ curl localhost:8080/
{"status": 404, "error": "Not Found", "message": "Not Found"}
That's OK, we haven't added any business content yet. But it shows
that there are sensible defaults built in for rendering HTTP and
server-side errors.
## Adding a business endpoint ## Adding a business endpoint
@ -139,13 +113,28 @@ the fully qualified name of your `SampleController`, e.g.
<start-class>com.mycompany.sample.SampleController</start-class> <start-class>com.mycompany.sample.SampleController</start-class>
</properties> </properties>
and re-package: and package and run:
$ mvn package $ mvn package
$ java -jar target/myproject-1.0.0-SNAPSHOT.jar $ java -jar target/myproject-1.0.0-SNAPSHOT.jar
$ curl localhost:8080/ $ curl localhost:8080/
{"message": "Hello World"} {"message": "Hello World"}
There are also some endpoins that you didn't implement by came free
with the Actuator:
$ curl localhost:8080/health
ok
$ curl localhost:8080/metrics
{"counter.status.200.health":1.0,"gauge.response.health":10.0,"mem":120768.0,"mem.free":105012.0,"processors":4.0}
`/health` is the default location for the health endpoint - it tells
you if the application is running and healthy. `/metrics` is the default
location for the metrics endpoint - it gives you basic counts and
response timing data by default but there are plenty of ways to
customize it. You can also try `/trace` and `/dump` to get some
interesting information about how and what your app is doing.
## Running the application ## Running the application
You can package the app and run it as a jar (as above) and that's very You can package the app and run it as a jar (as above) and that's very

264
spring-actuator/docs/Features.md
View File

@ -6,229 +6,12 @@ recommend you first build a project with the Actuator (e.g. the
getting started project from the main README), and then try each getting started project from the main README), and then try each
feature in turn there. feature in turn there.
TODO: some of these are features of Spring Bootstrap (or Many useful features of
`SpringApplication`) not the Actuator. [Spring Bootstrap](../../spring-bootstrap/README.md) are all available
in an Actuator application.
TODO: group things together and break them out into separate files. TODO: group things together and break them out into separate files.
## Commandline Arguments
Commandline arguments are passed on to any `CommandLineRunner` beans
found in the application. Option arguments (starting with `--`,
e.g. `--server.port=9000`) are converted to a `PropertySource` and
added to the Spring `Environment` with first priority (they always
take precedence and override values from other sources). Properties
in the `Environment` (including System properties and OS environment
variables) can always be injected into Spring components using
`@Value` with placeholders, e.g.
@Component
public class MyService {
@Value("${app.message:Hello World}")
private String message;
...
}
The default value comes after the first colon (":").
## Externalized Configuration
In addition to command line option arguments, Spring Bootstrap will
pick up a file called `application.properties` in the root of your
classpath (if there is one) and add those properties to the Spring
`Environment`. The search path for `application.properties` is
actually, 1) root or classpath, 2) current directory, 3) `/config`
package in classpath, 4) `/config` subdir of current directory. The
list is ordered by decreasing precedence (so properties can be
overridden by others with the same name defined in later locations).
The values in `application.properties` are filtered through the
existing `Environment` when they are used so you can refer back to
previously defined values (e.g. from System properties), e.g.
app.name: MyApp
app.description: ${app.name} is a Cool New App
Spring Bootstrap also binds the properties to any bean in your
application context whose type is `@ConfigurationProperties`. The
Actuator provides some of those beans out of the box, so you can
easily customize server and management properties (ports etc.),
endpoint locations and logging. See below for more detail, or inspect
the `*Properties` types in the Actuator jar.
## Setting the Default Spring Profile
Spring Profiles are a way to segregate parts of the application
configuration and make it only available in certain environments. Any
`@Component` that is marked with `@Profile` will only be loaded in the
profile specified by the latter annotation.
Spring Bootstap takes it a stage further. If you include in your
`application.properties` a value for a property named
`spring.active.profiles` then those profiles will be active by
default. E.g.
spring.active.profiles: dev,hsqldb
## Profile-dependent configuration
Spring Bootstrap loads additional properties files if there are active
profiles using a naming convention `application-{profile}.properties`.
Property values from those files override trhe default ones.
## Custom Typesafe Externalized Configuration
If you want a strongly typed bean (or beans) to govern and validate
the configuration of your application beyond the built in properties,
all you need to do is create a `@ConfigurationProperties` class, e.g.
@ConfigurationProperties(name="my")
public class MyProperties {
}
and declare one either explicitly (with `@Bean`) or implicitly by
adding
@EnableConfigurationProperties(MyProperties.class)
to one of your `@Configuration` (or `@Component`) classes. Then you can
@Autowired
private MyProperties configuration = new MyProperties();
in any of your component classes to grab that configuration and use it.
Spring Bootstrap uses some relaxed rules for binding `Environment`
properties to `@ConfigurationProperties` beans, so there doesn't need
to be an exact match between the `Environment` property name and the
bean property name. Common examples where this is useful include
underscore separated (e.g. `context_path` binds to `contextPath`), and
capitalized (e.g. `PORT` binds to `port`) environment properties.
Spring will attempt to coerce the external application properties to
the right type when it binds to the `@ConfigurationProperties` beans.
If you need custom type conversion you can provide a
`ConversionService` bean (with bean id `conversionService`) or custom
property editors (via a `CustomEditorConfigurer` bean).
Spring will also validate the external configuration, by default using
JSR-303 if it is on the classpath. So you can add annotations from
that specification (or its implementations) to your custom properties,
e.g.
@ConfigurationProperties(name="my")
public class MyProperties {
@NotNull
private String name;
// .. getters and setters
}
You can also add a custom Spring `Validator` by creating a bean
definition called `configurationPropertiesValidator`.
## Using Project Lombok
You can safely use [Project Lombok](http://projectlombok.org) to
generate getters and setters for your `@ConfigurationProperties`.
Refer to the documentation on the Lombok for how to enable it in your
compiler or IDE.
## Using YAML instead of Properties
YAML is a superset of JSON, and as such is a very convenient format
for specifying hierarchical configuration data, such as that supported
by Spring Actuator. If you prefer to use
[YAML](http://yaml.org) instead of Properties files you just need to
include a file called `application.yml` in the root of your classpath
You can if you like add profile specific YAML files
(`application-${profile}.yml`), but a nicer alternative is to use YAML
documents inside `application.yml`, with profile-specific documents
containing a `spring.profiles` key. For example
server:
port: 8080
management:
port: 8080
address: 0.0.0.0
---
spring:
profiles: prod
management:
port: 8081
address: 10.2.68.12
## Customizing the location of the External Configuration
If you don't like `application.properties` or `application.yml` as the
configuration file location you can switch to another location by
specifying the `spring.config.name` (default `application`) or the
`spring.config.location` as environment properties, e.g. if launching
a jar which wraps `SpringApplication`:
$ java -jar myproject.jar --spring.config.name=myproject
## Providing Defaults for Externalized Configuration
For `@ConfigurationProperties` beans that are provided by the
framework itself you can always change the values that are bound to it
by changing `application.properties`. But it is sometimes also useful
to change the default values imperatively in Java, so get more control
over the process. You can do this by declaring a bean of the same
type in your application context, e.g. for the server properties:
@Bean
public ServerProperties serverProperties() {
ServerProperties server = new ServerProperties();
server.setPort(8888);
return server;
}
## Server Configuration
The `ServerProperties` are bound to application properties, and
can be used to specify
* The port that the application listens on for the its endpoints
(`server.port` defaults to 8080)
* The address that the application endpoints are available on
(`server.address` defaults to all local addresses, making it available to connections
from all clients).
* The context root of the application endpoints (`server.context_path`
defaults to "/")
## Tomcat Container Configuration
If you want to use Tomcat as an embedded container include at least
`org.apache.tomcat.embed:tomcat-embed-core` and one of the
`org.apache.tomcat.embed:tomcat-embed-logging-*` libraries (depending
on the logging system you are using). Then, in addition to the
generic `ServerProperties`, you can also bind `server.tomcat.*`
properties in the application properties (see
`ServerProperties.Tomcat`).
* To enable the Tomcat access log valve (very common in production environments)
More fine-grained control of the Tomcat container is available if you
need it. Instead of letting Spring Actuator create the container for
you, just create a bean of type
`TomcatEmbeddedServletContainerFactory` and override one of its
methods, or inject some customizations, e.g.
@Configuration
public class MyContainerConfiguration {
@Bean
public TomcatEmbeddedServletContainerFactory tomcatEmbeddedContainerFactory() {
TomcatEmbeddedServletContainerFactory factory = new TomcatEmbeddedServletContainerFactory();
factory.setConnector(new Connector("AJP/1.3"));
}
}
(the default connector uses the `Http11NioProtocol` so the example if
overriding that behaviour).
## Customizing Management Endpoints ## Customizing Management Endpoints
The `ManagementProperties` are bound to application properties, and The `ManagementProperties` are bound to application properties, and
@ -254,46 +37,11 @@ have picked a container implementation (by including either Tomcat or
Jetty on the classpath), but then the API is the same. TODO: finish Jetty on the classpath), but then the API is the same. TODO: finish
this. this.
## Customizing Logging ## Logging
Spring Actuator uses SLF4J for logging, but leaves the implementation Spring Actuator uses SLF4J for logging, but leaves the implementation
open. The Starter projects and the Actuator use JDK native logging by open. The Starter projects and the Actuator use logback logging by
default, purely because it is always available. A default default because it has the richest feature set.
configuration file is provided for JDK logging, and also for log4j and
logback. In each case there is console output and file output
(rotating, 10MB file size).
The various logging systems can be activated by including the right
libraries on the classpath, and further customized by providing a
native configuration file in the root of the classpath, or in a
location specified by the Spring `Environment` property
`logging.config`.
|Logger|Activation |Customization |
|---|---|---|
|JDK |slf4j-jdk14 | logging.properties |
|Logback |logback | logback.xml |
|Log4j |slfj4-log4j12, log4j | log4j.properties or log4j.xml |
To help with the customization some other properties are transferred
from the Spring `Environment` to System properties:
|Environment|System Property |Comments |
|---|---|---|
|logging.file |LOG_FILE | Used in default log configuration if defined |
|logging.path |LOG_PATH | Used in default log configuration if defined |
|PID |PID | The current process ID is discovered if possible and not already provided |
All the logging systems supported can consult System properties when
parsing their configuration files. See the default configurations in
`spring-bootstrap.jar` for examples.
## Application Context Initializers
To add additional application context initializers to the bootstrap
startup process, add a comma-delimited list of class names to the
`Environment` property `context.initializer.classes` (can be specified
via `application.properties`).
## Info Endpoint ## Info Endpoint

155
spring-bootstrap/README.md
View File

@ -1 +1,156 @@
# Spring Bootstrap # Spring Bootstrap
Spring Bootstrap provides features for the other parts of Spring
Zero. It is relatively unopinionated and therefore usable as a
standalone library for anyone whose tastes diverge from ours.
|Feature |Implementation |Notes |
|---|---|---|
|Launch Spring from Java main |SpringApplication | Plenty of convenience methods and customization opportunities |
|Server |Tomcat or Jetty | |
|Logging |Logback, Log4j or JDK | Sensible defaults configurations. |
|Externalized configuration | Properties or YAML | Support for Spring profiles. Bind automatically to @Bean. |
For a quick introduction and to get started quickly with a new
project, carry on reading. For more in depth coverage of the features
of Spring Zero Actuator, go to the [Feature Guide](docs/Features.md).
# Getting Started
You will need Java (6 at least) and a build tool (Maven is what we use
below, but you are more than welcome to use gradle). These can be
downloaded or installed easily in most operating systems. For Ubuntu:
$ sudo apt-get install openjdk-6-jdk maven
<!--FIXME: short instructions for Mac.-->
## A basic project
If you are using Maven create a really simple `pom.xml` with 2 dependencies:
`pom.xml`
```
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>myproject</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<start-class>com.mycompany.Application</start-class>
</properties>
<parent>
<groupId>org.springframework.zero</groupId>
<artifactId>spring-starter-parent</artifactId>
<version>{{project.version}}</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.zero</groupId>
<artifactId>spring-starter</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.zero</groupId>
<artifactId>spring-package-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
```
If you like Gradle, that's fine, and you will know what to do with
those dependencies. The one dependency adds Spring Zero auto
configuration and the Tomcat container to your application. If you
prefer Jetty you can just add the embedded Jetty jars to your
classpath instead of Tomcat.
Now write a simple main class
`Application.java`
```
package com.mycompany;
import org.springframework.bootstrap.SpringApplication;
import org.springframework.context.annotation.Configuration;
@Configuration
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
```
You should be able to run it already:
$ mvn package
$ java -jar target/myproject-1.0.0-SNAPSHOT.jar
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
Spring Bootstrap
2013-07-19 17:13:51.673 INFO 18937 --- [ main] com.mycompany.Application ...
... <logs showing application starting up>
It doesn't do anything yet, but that's because all we did is start a
Spring `ApplicationContext` and let it close when the JVM stopped.
To make it do something a little bit more interesting you could bind
some command line arguments to the application:
`Application.java`
```
@Configuration
@ConfigurationProperties
@EnableConfigurationProperties
public class Application {
private String message;
@Override
public void run(String... args) throws Exception {
System.err.println(message);
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
```
The `@ConfigurationProperties` annotation binds the Spring
`Environment` (including command line arguments) to the `Application`
instance, and `CommandLineRunner` is a marker interface for anything
you want to be executed after the content is started. So run it
again and you will see the message:
```
$ mvn package
$ java -jar target/myproject-1.0.0-SNAPSHOT.jar --message="Hello World"
...
Hello World
```
To add more features, add some `@Bean` definitions to your
`Application` class, and read more in the
[Feature Guide](docs/Features.md).

262
spring-bootstrap/docs/Features.md Normal file
View File

@ -0,0 +1,262 @@
# Spring Bootstrap Feature Guide
Here are some (most, hopefully all) the features of Spring Bootstrap
with some commentary to help you start using them.
## Commandline Arguments
Commandline arguments are passed on to any `CommandLineRunner` beans
found in the application. Option arguments (starting with `--`,
e.g. `--server.port=9000`) are converted to a `PropertySource` and
added to the Spring `Environment` with first priority (they always
take precedence and override values from other sources). Properties
in the `Environment` (including System properties and OS environment
variables) can always be injected into Spring components using
`@Value` with placeholders, e.g.
@Component
public class MyService {
@Value("${app.message:Hello World}")
private String message;
...
}
The default value comes after the first colon (":").
## Externalized Configuration
In addition to command line option arguments, Spring Bootstrap will
pick up a file called `application.properties` in the root of your
classpath (if there is one) and add those properties to the Spring
`Environment`. The search path for `application.properties` is
actually, 1) root or classpath, 2) current directory, 3) `/config`
package in classpath, 4) `/config` subdir of current directory. The
list is ordered by decreasing precedence (so properties can be
overridden by others with the same name defined in later locations).
The values in `application.properties` are filtered through the
existing `Environment` when they are used so you can refer back to
previously defined values (e.g. from System properties), e.g.
app.name: MyApp
app.description: ${app.name} is a Cool New App
Spring Bootstrap also binds the properties to any bean in your
application context whose type is `@ConfigurationProperties`. The
Actuator provides some of those beans out of the box, so you can
easily customize server and management properties (ports etc.),
endpoint locations and logging. See below for more detail, or inspect
the `*Properties` types in the Actuator jar.
## Setting the Default Spring Profile
Spring Profiles are a way to segregate parts of the application
configuration and make it only available in certain environments. Any
`@Component` that is marked with `@Profile` will only be loaded in the
profile specified by the latter annotation.
Spring Bootstap takes it a stage further. If you include in your
`application.properties` a value for a property named
`spring.active.profiles` then those profiles will be active by
default. E.g.
spring.active.profiles: dev,hsqldb
## Profile-dependent configuration
Spring Bootstrap loads additional properties files if there are active
profiles using a naming convention `application-{profile}.properties`.
Property values from those files override trhe default ones.
## Custom Typesafe Externalized Configuration
If you want a strongly typed bean (or beans) to govern and validate
the configuration of your application beyond the built in properties,
all you need to do is create a `@ConfigurationProperties` class, e.g.
@ConfigurationProperties(name="my")
public class MyProperties {
}
and declare one either explicitly (with `@Bean`) or implicitly by
adding
@EnableConfigurationProperties(MyProperties.class)
to one of your `@Configuration` (or `@Component`) classes. Then you can
@Autowired
private MyProperties configuration = new MyProperties();
in any of your component classes to grab that configuration and use it.
Spring Bootstrap uses some relaxed rules for binding `Environment`
properties to `@ConfigurationProperties` beans, so there doesn't need
to be an exact match between the `Environment` property name and the
bean property name. Common examples where this is useful include
underscore separated (e.g. `context_path` binds to `contextPath`), and
capitalized (e.g. `PORT` binds to `port`) environment properties.
Spring will attempt to coerce the external application properties to
the right type when it binds to the `@ConfigurationProperties` beans.
If you need custom type conversion you can provide a
`ConversionService` bean (with bean id `conversionService`) or custom
property editors (via a `CustomEditorConfigurer` bean).
Spring will also validate the external configuration, by default using
JSR-303 if it is on the classpath. So you can add annotations from
that specification (or its implementations) to your custom properties,
e.g.
@ConfigurationProperties(name="my")
public class MyProperties {
@NotNull
private String name;
// .. getters and setters
}
You can also add a custom Spring `Validator` by creating a bean
definition called `configurationPropertiesValidator`.
## Using Project Lombok
You can safely use [Project Lombok](http://projectlombok.org) to
generate getters and setters for your `@ConfigurationProperties`.
Refer to the documentation on the Lombok for how to enable it in your
compiler or IDE.
## Using YAML instead of Properties
YAML is a superset of JSON, and as such is a very convenient format
for specifying hierarchical configuration data, such as that supported
by Spring Actuator. If you prefer to use
[YAML](http://yaml.org) instead of Properties files you just need to
include a file called `application.yml` in the root of your classpath
You can if you like add profile specific YAML files
(`application-${profile}.yml`), but a nicer alternative is to use YAML
documents inside `application.yml`, with profile-specific documents
containing a `spring.profiles` key. For example
server:
port: 8080
management:
port: 8080
address: 0.0.0.0
---
spring:
profiles: prod
management:
port: 8081
address: 10.2.68.12
## Customizing the location of the External Configuration
If you don't like `application.properties` or `application.yml` as the
configuration file location you can switch to another location by
specifying the `spring.config.name` (default `application`) or the
`spring.config.location` as environment properties, e.g. if launching
a jar which wraps `SpringApplication`:
$ java -jar myproject.jar --spring.config.name=myproject
## Providing Defaults for Externalized Configuration
For `@ConfigurationProperties` beans that are provided by the
framework itself you can always change the values that are bound to it
by changing `application.properties`. But it is sometimes also useful
to change the default values imperatively in Java, so get more control
over the process. You can do this by declaring a bean of the same
type in your application context, e.g. for the server properties:
@Bean
public ServerProperties serverProperties() {
ServerProperties server = new ServerProperties();
server.setPort(8888);
return server;
}
## Server Configuration
The `ServerProperties` are bound to application properties, and
can be used to specify
* The port that the application listens on for the its endpoints
(`server.port` defaults to 8080)
* The address that the application endpoints are available on
(`server.address` defaults to all local addresses, making it available to connections
from all clients).
* The context root of the application endpoints (`server.context_path`
defaults to "/")
## Tomcat Container Configuration
If you want to use Tomcat as an embedded container include at least
`org.apache.tomcat.embed:tomcat-embed-core` and one of the
`org.apache.tomcat.embed:tomcat-embed-logging-*` libraries (depending
on the logging system you are using). Then, in addition to the
generic `ServerProperties`, you can also bind `server.tomcat.*`
properties in the application properties (see
`ServerProperties.Tomcat`).
* To enable the Tomcat access log valve (very common in production environments)
More fine-grained control of the Tomcat container is available if you
need it. Instead of letting Spring Actuator create the container for
you, just create a bean of type
`TomcatEmbeddedServletContainerFactory` and override one of its
methods, or inject some customizations, e.g.
@Configuration
public class MyContainerConfiguration {
@Bean
public TomcatEmbeddedServletContainerFactory tomcatEmbeddedContainerFactory() {
TomcatEmbeddedServletContainerFactory factory = new TomcatEmbeddedServletContainerFactory();
factory.setConnector(new Connector("AJP/1.3"));
}
}
(the default connector uses the `Http11NioProtocol` so the example if
overriding that behaviour).
## Customizing Logging
Spring Bootstrap uses Commons Logging for logging, but leaves the
implementation open. A default configuration file is provided for
logback, and also for log4j and JDK logging. In each case there is
console output and file output (rotating, 10MB file size).
The various logging systems can be activated by including the right
libraries on the classpath, and further customized by providing a
native configuration file in the root of the classpath, or in a
location specified by the Spring `Environment` property
`logging.config`.
|Logger|Activation |Customization |
|---|---|---|
|JDK |slf4j-jdk14 | logging.properties |
|Logback |logback | logback.xml |
|Log4j |slfj4-log4j12, log4j | log4j.properties or log4j.xml |
To help with the customization some other properties are transferred
from the Spring `Environment` to System properties:
|Environment|System Property |Comments |
|---|---|---|
|logging.file |LOG_FILE | Used in default log configuration if defined |
|logging.path |LOG_PATH | Used in default log configuration if defined |
|PID |PID | The current process ID is discovered if possible and not already provided |
All the logging systems supported can consult System properties when
parsing their configuration files. See the default configurations in
`spring-bootstrap.jar` for examples.
## Application Context Initializers
To add additional application context initializers to the bootstrap
startup process, add a comma-delimited list of class names to the
`Environment` property `context.initializer.classes` (can be specified
via `application.properties`).

22
spring-package-maven-plugin/README.md
View File

@ -1,11 +1,12 @@
# Spring Package Maven Plugin # Spring Package Maven Plugin
A maven plugin for building executable JAR and WAR files. To use it A maven plugin for building executable JAR and WAR files. To use it,
configure your project to build a JAR or WAR (as appropriate) in the configure your project to build a JAR or WAR (as appropriate) in the
normal way, using the `maven-jar-plugin` or `maven-war-plugin`, and normal way, and then add the Spring plugin to your `<build><plugins>`
then add the Spring plugin to your `<build><plugins>` section section
`pom.xml` `pom.xml`
```xml ```xml
<plugin> <plugin>
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
@ -20,3 +21,18 @@ then add the Spring plugin to your `<build><plugins>` section
</executions> </executions>
</plugin> </plugin>
``` ```
The net effect of that is to enhance your existing archive with the
Spring Launcher during the Maven `package` phase. The main class will
be selected from the existing `MANIFEST.MF` if there is one, or else
the plugin will attempt to guess based on the contents of the local
`src/main/java` source tree.
So to build and run a project artifact you do something like this:
```
$ mvn package
$ java -jar target/*.jar
...
<application runs>
```

4
spring-package-maven-plugin/src/it/jar/pom.xml
View File

@ -26,8 +26,10 @@
<version>2.4</version> <version>2.4</version>
<configuration> <configuration>
<archive> <archive>
<manifest>
<mainClass>some.random.Main</mainClass>
</manifest>
<manifestEntries> <manifestEntries>
<Main-Class>some.random.Main</Main-Class>
<Not-Used>Foo</Not-Used> <Not-Used>Foo</Not-Used>
</manifestEntries> </manifestEntries>
</archive> </archive>

27
spring-starters/spring-starter-parent/pom.xml
View File

@ -14,6 +14,7 @@
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<spring.version>4.0.0.BUILD-SNAPSHOT</spring.version> <spring.version>4.0.0.BUILD-SNAPSHOT</spring.version>
<spring.zero.version>0.5.0.BUILD-SNAPSHOT</spring.zero.version> <spring.zero.version>0.5.0.BUILD-SNAPSHOT</spring.zero.version>
<start-class>org.springframework.bootstrap.SpringApplication</start-class>
</properties> </properties>
<prerequisites> <prerequisites>
<maven>3.0</maven> <maven>3.0</maven>
@ -188,6 +189,13 @@
<plugin> <plugin>
<artifactId>maven-jar-plugin</artifactId> <artifactId>maven-jar-plugin</artifactId>
<version>2.4</version> <version>2.4</version>
<configuration>
<archive>
<manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</archive>
</configuration>
</plugin> </plugin>
<plugin> <plugin>
<artifactId>maven-javadoc-plugin</artifactId> <artifactId>maven-javadoc-plugin</artifactId>
@ -213,7 +221,9 @@
<artifactId>exec-maven-plugin</artifactId> <artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version> <version>1.2.1</version>
<configuration> <configuration>
<mainClass>${start-class}</mainClass> <manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</configuration> </configuration>
</plugin> </plugin>
<plugin> <plugin>
@ -232,6 +242,13 @@
<plugin> <plugin>
<artifactId>maven-war-plugin</artifactId> <artifactId>maven-war-plugin</artifactId>
<version>2.3</version> <version>2.3</version>
<configuration>
<archive>
<manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</archive>
</configuration>
</plugin> </plugin>
<!-- Support the generally useful versions command --> <!-- Support the generally useful versions command -->
@ -266,14 +283,6 @@
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>spring-package-maven-plugin</artifactId> <artifactId>spring-package-maven-plugin</artifactId>
<version>${spring.zero.version}</version> <version>${spring.zero.version}</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
<executions> <executions>
<execution> <execution>
<goals> <goals>

27
spring-starters/src/main/parent/pom.xml
View File

@ -14,6 +14,7 @@
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<spring.version>4.0.0.BUILD-SNAPSHOT</spring.version> <spring.version>4.0.0.BUILD-SNAPSHOT</spring.version>
<spring.zero.version>@{project.version}</spring.zero.version> <spring.zero.version>@{project.version}</spring.zero.version>
<start-class>org.springframework.bootstrap.SpringApplication</start-class>
</properties> </properties>
<prerequisites> <prerequisites>
<maven>3.0</maven> <maven>3.0</maven>
@ -188,6 +189,13 @@
<plugin> <plugin>
<artifactId>maven-jar-plugin</artifactId> <artifactId>maven-jar-plugin</artifactId>
<version>2.4</version> <version>2.4</version>
<configuration>
<archive>
<manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</archive>
</configuration>
</plugin> </plugin>
<plugin> <plugin>
<artifactId>maven-javadoc-plugin</artifactId> <artifactId>maven-javadoc-plugin</artifactId>
@ -213,7 +221,9 @@
<artifactId>exec-maven-plugin</artifactId> <artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version> <version>1.2.1</version>
<configuration> <configuration>
<mainClass>${start-class}</mainClass> <manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</configuration> </configuration>
</plugin> </plugin>
<plugin> <plugin>
@ -232,6 +242,13 @@
<plugin> <plugin>
<artifactId>maven-war-plugin</artifactId> <artifactId>maven-war-plugin</artifactId>
<version>2.3</version> <version>2.3</version>
<configuration>
<archive>
<manifest>
<mainClass>${start-class}</mainClass>
</manifest>
</archive>
</configuration>
</plugin> </plugin>
<!-- Support the generally useful versions command --> <!-- Support the generally useful versions command -->
@ -266,14 +283,6 @@
<groupId>org.springframework.zero</groupId> <groupId>org.springframework.zero</groupId>
<artifactId>spring-package-maven-plugin</artifactId> <artifactId>spring-package-maven-plugin</artifactId>
<version>${spring.zero.version}</version> <version>${spring.zero.version}</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
<executions> <executions>
<execution> <execution>
<goals> <goals>