Spring Boot 2.1.0.release Source Code Analysis

Spring Boot Actuator provides three primary capabilities for production-ready applications:

• Endpoints: Built-in or custom endpoints that allow you to monitor and interact with your application. For example, the health endpoint is available at /actuator/health by default.
• Metrics: Dimensional metrics gathering through integration with Micrometer.
• Audit: A flexible framework that publishes events to an AuditEventRepository. If Spring Security is present, it automatically publishes authentication events, which can be used for reporting or implementing lockout policies.

This sample demonstrates how Spring Boot provides auto-configuration support for various caching libraries through its caching abstraction. By default, if no caching library is present, the application uses a simple ConcurrentHashMap-based cache.

Supported providers include:

• JSR-107 (JCache) compliant providers
• EhCache
• Hazelcast
• Infinispan
• Couchbase
• Redis
• Caffeine
• Generic providers based on org.springframework.Cache bean definitions.

The sample includes a CountryService that caches countries by ISO code. You can monitor cache statistics via the /metrics endpoint if the chosen provider supports it.

The Spring Boot Gradle Plugin integrates Spring Boot support into Gradle. It enables three primary capabilities:

1. Packaging: Create executable JAR or WAR archives.
2. Running: Run Spring Boot applications directly from Gradle.
3. Dependency Management: Use the dependency management provided by spring-boot-dependencies to simplify version management.

Requirements

• Gradle: Version 4.4 or later is required.
• Kotlin DSL: If using the Kotlin DSL, Gradle 4.10 or later is required.

This sample project demonstrates how Spring Boot provides auto-configuration support for Spring Session. Spring Session allows you to manage user sessions using various external session stores instead of the standard HTTP session. Supported session store types include:

• Redis
• JDBC
• Hazelcast
• MongoDB

Spring Boot Starters are convenient dependency descriptors that act as a "one-stop-shop" for specific technologies. Instead of manually searching for and copying multiple dependency descriptors (versions, compatible libraries, etc.), you include a single starter dependency to automatically pull in all the necessary Spring and related technology components for your application.

For example, to use Spring and JPA for database access, you only need to include the spring-boot-starter-data-jpa dependency in your project.

Spring Boot uses 'Entity Scanning' instead of a persistence.xml file. By default, it searches all packages below your main configuration class (annotated with @SpringBootApplication or @EnableAutoConfiguration). It identifies classes annotated with @Entity, @Embeddable, or @MappedSuperclass.

You can customize the scanning locations by using the @EntityScan annotation on a configuration class.

@Entity
public class City implements Serializable {
    @Id
    @GeneratedValue
    private Long id;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String state;

    protected City() {
        // no-args constructor required by JPA spec
    }
}

Starters are convenient dependency descriptors that provide a 'one-stop shop' for specific technologies.

• Official Starters: Follow the pattern spring-boot-starter-* (e.g., spring-boot-starter-data-jpa).
• Third-party Starters: Should not start with spring-boot. They typically follow the pattern [project-name]-spring-boot-starter (e.g., thirdpartyproject-spring-boot-starter).

Using starters ensures a consistent, supported set of managed transitive dependencies.

Spring Boot DevTools uses two classloaders: a restart classloader for files that change and a base classloader for static dependencies. In multi-module projects or complex IDE setups, you may need to move specific JARs between these classloaders.

Create a META-INF/spring-devtools.properties file on your classpath. Use regex patterns to define which items belong to which classloader:

• restart.include.<name>: Pulls the matching items into the restart classloader.
• restart.exclude.<name>: Pushes the matching items down into the base classloader.

All property keys must be unique.

# Example: Exclude common libraries from restart, include specific project libs
restart.exclude.companycommonlibs=/mycorp-common-[\w-]+\.jar
restart.include.projectcommon=/mycorp-myproj-[\w-]+\.jar

The response from the mappings endpoint is organized by application contexts. The specific fields available under contexts.*.mappings depend on your web application type:

Servlet-based Applications (Spring MVC)

• Dispatcher Servlets: Details of DispatcherServlet request mappings are found under contexts.*.mappings.dispatcherServlets.
• Servlets: Details of any Servlet mappings are found under contexts.*.mappings.servlets.
• Servlet Filters: Details of any Filter mappings are found under contexts.*.mappings.servletFilters.

Reactive Applications (Spring WebFlux)

• Dispatcher Handlers: Details of DispatcherHandler request mappings are found under contexts.*.mappings.dispatcherHandlers.

Spring Boot jars include metadata files located at META-INF/spring-configuration-metadata.json. These files provide details about all supported configuration properties, enabling IDEs to offer contextual help and code completion for application.properties or application.yml files.

Metadata is primarily generated automatically at compile time by processing classes annotated with @ConfigurationProperties. It consists of three main categories:

1. Groups: Higher-level items that provide contextual grouping for properties (e.g., the server group contains server.port).
2. Properties: Individual configuration items that users specify with values (e.g., server.port).
3. Hints: Additional information used to assist users, such as providing a list of valid auto-completion values for a specific property.