Xke spring boot

By : Jaspereet Juneja & Sourabh Aggarwal
Date : 30 July 2015
SPRING BOOT

What is Spring Boot?
● Spring Boot is a approach to develop Spring based application
with very less or no configuration.
● It leverages existing Spring projects as well as Third party
projects to develop production ready applications.
● It provides a set of Starter Pom’s, gradle etc.. build files which
one can use to add required dependencies and also facilitate
auto configuration. Depending on the libraries on its classpath,
Spring Boot automatically configures required classes.
● For example to interact with DB, if there is Spring Data libraries
on class path then it automatically sets up connection to DB
along with the Data Source class.

Why to use spring boot?
➔ Create stand-alone Spring applications
➔ Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
➔ Provide opinionated 'starter' POMs to simplify your Maven configuration
➔ Automatically configure Spring whenever possible
➔ Provide production-ready features such as metrics, health checks and
externalized configuration
➔ Absolutely no code generation and no requirement for XML configuration.

Spring Boot Modules?
Boot
Autoconfigure
Starters
CLI
Actuator
Tools
Samples

Spring Boot Modules?
● Spring Boot - main library supporting the other parts of Spring Boot
● Spring Boot Autoconfigure - single @EnableAutoConfiguration annotation
creates a whole Spring context
● Spring Boot Starters - a set of convenient dependency descriptors that
you can include in your application.
● Spring Boot CLI - compiles and runs Groovy source as a Spring
application
● Spring Boot Actuator - common non-functional features that make an app
instantly deployable and supportable in production
● Spring Boot Tools - for building and executing self-contained JAR and
WAR archives
● Spring Boot Samples - a wide range of sample apps

Spring Boot Actuator?
● It’s a Spring Boot module that immediately gives your Spring-based web applications basic health
check and monitoring interfaces. To use it just add Maven dependency spring-boot-starter-actuator.
● If you now recompile and restart your service, you’ll notice that a lot more endpoints are being
mapped (this is printed to the log during startup). Some of these are:
– /health – returns “ok” as text/plain content which is useful for simple service monitoring
– /env – check environment configuration, property file and command line argument overrides, active profiles
– /metrics – basic statistics on your service endpoints (e.g. hit count, error count)
– /dump – thread dump
– /trace – the latest HTTP request/response pairs
● You can access/modify (or change completely if you wish) the behavior for most of these. For
example, if you want to add a custom metric, just inject a MetricRepository in your business beans,
and start using it, it’ll get exposed via the Actuator /metrics interface.

Spring Boot over Spring
● Opinionated Convention Over Configuration
● Automatic Configuration
● Starter + Example Builds
● Standalone Apps
● No XML!
● Embedded Containers
● Metrics (Actuator)
● Groovy

Hello World(Java)
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.web.bind.annotation.*;
@RestController
@EnableAutoConfiguration
public class MyApplication {
@RequestMapping("/hello")
public String sayHello() {
return "Hello World!";
}
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}

● Attempts to auto-configure your application
● Backs off as you define your own beans
@Configuration
public class MyApplication {
}

Starter POMs
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
● Standard Maven POMs
● Define dependencies that we recommend
● Parent optional
● Available for web, batch, integration, data, amqp, aop, jdbc, ...
● e.g. data = hibernate + spring-data + JSR 303

Packaging For Production
Maven plugin (using spring-boot-starter-parent):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
$ mvn package

Annotations
We are relying on Spring’s annotation and package-scan based
approach to configure our controller
● @EnableAutoConfiguration is specific to Spring Boot and declaring it
will result in a lot of pre-defined configuration pulled to our Spring
Application Context (like the embedded Tomcat container)
● SpringApplication is another Boot-specific component, it’s the default
entry point for most of the Spring Boot applications and will take care of
the Spring Application Context for us.
● And that is all you actually need. At this point you should be able to start
this application from your favourite IDE, launching class
HelloConfiguration. Then visit http://localhost:8080/hello which should
result in “Hello World!” being displayed in your browser.

Problems?
Although most features that Spring Boot gives you are extremely useful and work very well
immediately, we encountered a few cases where a bit of caution is recommended:
– Spring Boot will import and use Logback and SLF4J as default loggers. If you want to use something else (e.g.
Log4J) or one of your dependencies transitively imports it, you need to be careful and use the appropriate logger
bridges. Some combinations may result in your applications not starting at all. Maven exclusions for transitive
dependencies will come handy.
– The Spring Boot Maven Builder packages executable jar files in a specific way, effectively adding multiple levels of
nested jar files. This is a problem if your libraries want to extract contents from the nested jar files as Java won’t be
able to resolve that resource path. Consider using a different packaging mechanism like Shade or AppAssembler
in such cases. Spring Boot Maven Parent comes with a basic configuration for Shade, but the preferred choice
should be the Boot-builder.
– We advise some level of caution if you want to use embedded application servers and JSPs with Spring Boot,
there may be some limitations.

Overriding default configuration
● Using property files?
● Overriding with command line arguments?
● Support for Spring profiles?
● Overriding default beans?

Using property files?
●
By default Spring Boot will look for a property file in the package root directory called
application.properties, this is a good place to customize your application. By Maven
conventions, place this file into the src/main/resources directory so your build artefacts will be
generated correctly. For example let’s set the contents to:
server.port=11000
● This will cause the embedded Tomcat to listen on port 11000 instead of 8080. If you now
restart your service, you should use http://localhost:11000/hello to get access.
●
Finding out what is given by default and what you can override is probably the biggest
problem with Spring Boot at the moment. There is no comprehensive documentation about all
the options, but the code in org.springframework.boot.autoconfigure.* packages is a good
starting point. (e.g. server.port is bound to a field in
org.springframework.boot.autoconfigure.web.ServerProperties as of Boot 1.0.0.RC3).

Overriding with command line
arguments?
● If you need more execution-specific parameter use, you can do
it. The usual convention of the property overriding chain: defaults
< property files < Java VM arguments is still valid, but Spring
Boot will also give you Spring’s command-line argument
property source: with double dashes (“–”) arguments when
executing your application, you can specify property overrides:
$ java -jar spring-boot-example-0.0.1-SNAPSHOT.jar
--server.port=12000
● As you probably have already figured out, this will result in your
webserver listening on port 12000 and your application available
on http://localhost:12000/hello

Support for Spring profiles?
● Spring Boot actively supports the usage of Spring Profiles.
First, to activate a profile, you can use the double-dash
command line argument syntax: –spring.profiles.active and
list those that you want activated. Additionally, you can name
your property files in the following way:
application-{profile}.properties
● And only those that match one of the active profiles will get
loaded.
● Regarding your Spring beans, you can rely on the @Profile
annotation to work as expected.

Overriding default beans
● When pulling a spring-boot-starter project as a dependency,
Boot will declare the most commonly needed beans. For
example, in case of a web project, you will get a
DispatcherServlet without having to do anything (usually, you
can configure these default beans with externalized
properties).
● In the majority of the cases this will be sufficient. However, if
you want to have more control over these beans, just declare
them as you normally would and your beans will override the
ones given by Boot (in fact, Boot won’t even instantiate any of
its default beans if you have an overriding bean).

Xke spring boot

Recommended

More Related Content

What's hot (20)

Similar to Xke spring boot (20)

More from sourabh aggarwal (6)

Recently uploaded (20)

Xke spring boot