Spring Boot 2.0.0参考手册_中英文对照_Part III_19-22

博客:noahsnail.com  |  CSDN  |  简书

19. Running your application

One of the biggest advantages of packaging your application as jar and using an embedded HTTP server is that you can run your application as you would any other. Debugging Spring Boot applications is also easy; you don’t need any special IDE plugins or extensions.

将应用打包成jar并使用内嵌HTTP服务器的一个最大优势是你可以在任何地方运行你的程序。调试Spring Boot应用也很容易;你不必指定任何特定的IDE插件或扩展。

This section only covers jar based packaging, If you choose to package your application as a war file you should refer to your server and IDE documentation.



19.1 Running from an IDE

You can run a Spring Boot application from your IDE as a simple Java application, however, first you will need to import your project. Import steps will vary depending on your IDE and build system. Most IDEs can import Maven projects directly, for example Eclipse users can select Import…​Existing Maven Projects from the File menu.

你可以在你的IDE中运行一个Spring Boot应用将像运行一个简单的Java应用一样,然而,首先你需要导入你的工程。导入步骤根据你的IDE和构建系统会有所变化。大多数IDE可以直接导入Maven工程,例如Eclipse用户可以选择从File菜单选择Import…​Existing Maven Projects

If you can’t directly import your project into your IDE, you may be able to generate IDE metadata using a build plugin. Maven includes plugins for Eclipse and IDEA; Gradle offers plugins for various IDEs.


If you accidentally run a web application twice you will see a “Port already in use” error. STS users can use the Relaunch button rather than Run to ensure that any existing instance is closed.


如果你偶然的运行一个web应用两次,你会看到一个Port already in use错误。为了确保任何现有的实例被关闭,STS用户可以使用Relaunch按钮而不是Run按钮。

19.2 Running as a packaged application

If you use the Spring Boot Maven or Gradle plugins to create an executable jar you can run your application using java -jar. For example:

如果你使用Spring Boot的Maven或Gradle插件来创建一个可执行的jar包,你可以通过使用java -jar来运行你的应用。例如:

$ java -jar target/myproject-0.0.1-SNAPSHOT.jar

It is also possible to run a packaged application with remote debugging support enabled. This allows you to attach a debugger to your packaged application:


$ java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n -jar target/myproject-0.0.1-SNAPSHOT.jar

19.3 Using the Maven plugin

The Spring Boot Maven plugin includes a run goal which can be used to quickly compile and run your application. Applications run in an exploded form just like in your IDE.

Spring Boot Maven插件包含一个run目标,可以用来快速编译并运行你的应用。应用以exploded形式运行,就像在IDE中运行一样。

$ mvn spring-boot:run

You might also want to use the useful operating system environment variable:


$ export MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128M

19.4 Using the Gradle plugin

The Spring Boot Gradle plugin also includes a bootRun task which can be used to run your application in an exploded form. The bootRun task is added whenever you import the spring-boot-gradle-plugin:

Spring Boot Gradle插件也包含一个bootRun任务,它可以以exploded方式运行你的应用。当你导入spring-boot-gradle-plugin时,可以添加bootRun任务:

$ gradle bootRun

You might also want to use this useful operating system environment variable:


$ export JAVA_OPTS=-Xmx1024m -XX:MaxPermSize=128M

19.5 Hot swapping

Since Spring Boot applications are just plain Java applications, JVM hot-swapping should work out of the box. JVM hot swapping is somewhat limited with the bytecode that it can replace, for a more complete solution JRebel or the Spring Loaded project can be used. The spring-boot-devtools module also includes support for quick application restarts.

由于Spring Boot应用只是普通的Java应用,JVM热交换应该是开箱即用的。JVM热交换可以替换的字节码有限制,一个更全面的解决方案是JRebel或Spring Loaded工程。spring-boot-devtools模块也支持快速的应用重启。

See the Chapter 20, Developer tools section below and the Hot swapping “How-to” for details.


20. Developer tools

Spring Boot includes an additional set of tools that can make the application development experience a little more pleasant. The spring-boot-devtools module can be included in any project to provide additional development-time features. To include devtools support, simply add the module dependency to your build:

Spring Boot包含额外的工具集合,可以使应用开发的过程更方便一点。spring-boot-devtools模块可以包含进任何工程,用来提供额外的程序调试特性。为了添加工具支持,简单的添加模块依赖到你的构建系统中:




dependencies {

Developer tools are automatically disabled when running a fully packaged application. If your application is launched using java -jar or if it’s started using a special classloader, then it is considered a “production application”. Flagging the dependency as optional is a best practice that prevents devtools from being transitively applied to other modules using your project. Gradle does not support optional dependencies out-of-the-box so you may want to have a look to the propdeps-plugin in the meantime.


当运行一个完整的打包应用时,开发者工具会自动失效。如果你的应用是通过java -jar启动的,或者是通过一个特定的类加载器启动的,那它会被当做一个『产品级应用』。将依赖标记为optional是阻止开发工具间接应用到使用你应用的其它模块的最佳实践。Gradle不支持optional依赖开箱即用,同时你可能想看看propdeps-plugin

repackaged archives do not contain devtools by default. If you want to use certain remote devtools feature, you’ll need to enable the excludeDevtools build property to include it. The property is supported with both the Maven and Gradle plugins.



20.2 Automatic restart

Applications that use spring-boot-devtools will automatically restart whenever files on the classpath change. This can be a useful feature when working in an IDE as it gives a very fast feedback loop for code changes. By default, any entry on the classpath that points to a folder will be monitored for changes. Note that certain resources such as static assets and view templates do not need to restart the application.


Triggering a restart

As DevTools monitors classpath resources, the only way to trigger a restart is to update the classpath. The way in which you cause the classpath to be updated depends on the IDE that you are using. In Eclipse, saving a modified file will cause the classpath to be updated and trigger a restart. In IntelliJ IDEA, building the project (Build → Make Project) will have the same effect.



作为DevTools监视器classpath中的资源,触发重启的唯一方式是更新classpath。引起classpath更新的方式取决于你使用的IDE。在Eclipse中,保存一个修改的文件将引起classpath更新并触发重启事件。在IntelliJ IDEA中,构建工程(Build → Make Project)将会有同样的效果。


You can also start your application via the supported build plugins (i.e. Maven and Gradle) as long as forking is enabled since DevTools need an isolated application classloader to operate properly. Gradle and Maven do that by default when they detect DevTools on the classpath.




Automatic restart works very well when used with LiveReload. See below for details. If you use JRebel automatic restarts will be disabled in favor of dynamic class reloading. Other devtools features (such as LiveReload and property overrides) can still be used.




DevTools relies on the application context’s shutdown hook to close it during a restart. It will not work correctly if you have disabled the shutdown hook ( SpringApplication.setRegisterShutdownHook(false)).




When deciding if an entry on the classpath should trigger a restart when it changes, DevTools automatically ignores projects named spring-boot, spring-boot-devtools, spring-boot-autoconfigure, spring-boot-actuator, and spring-boot-starter.




Restart vs Reload

The restart technology provided by Spring Boot works by using two classloaders. Classes that don’t change (for example, those from third-party jars) are loaded into a base classloader. Classes that you’re actively developing are loaded into a restart classloader. When the application is restarted, the restart classloader is thrown away and a new one is created. This approach means that application restarts are typically much faster than “cold starts” since the base classloader is already available and populated.

If you find that restarts aren’t quick enough for your applications, or you encounter classloading issues, you could consider reloading technologies such as JRebel from ZeroTurnaround. These work by rewriting classes as they are loaded to make them more amenable to reloading. Spring Loaded provides another option, however it doesn’t support as many frameworks and it isn’t commercially supported.



Spring Boot提供的重启技术是通过两个类加载器进行工作的。加载进基类加载器的类不能改变(例如,那些第三方jar包)。那些你正在开发的类加载进重启类加载器中。当应用重启时,丢弃旧的重启类加载器并创建一个新的。这种方法意味着应用重启时比『冷启动』更快,因为基类加载器已经存在并可用。


20.2.1 Excluding resources

Certain resources don’t necessarily need to trigger a restart when they are changed. For example, Thymeleaf templates can just be edited in-place. By default changing resources in /META-INF/maven, /META-INF/resources, /resources, /static, /public or /templates will not trigger a restart but will trigger a live reload. If you want to customize these exclusions you can use the spring.devtools.restart.exclude property. For example, to exclude only /static and /public you would set the following:



If you want to keep those defaults and add additional exclusions, use the spring.devtools.restart.additional-exclude property instead.



20.2.2 Watching additional paths

You may want your application to be restarted or reloaded when you make changes to files that are not on the classpath. To do so, use the spring.devtools.restart.additional-paths property to configure additional paths to watch for changes. You can use the spring.devtools.restart.exclude property described above to control whether changes beneath the additional paths will trigger a full restart or just a live reload.


20.2.3 Disabling restart

If you don’t want to use the restart feature you can disable it using the spring.devtools.restart.enabled property. In most cases you can set this in your application.properties (this will still initialize the restart classloader but it won’t watch for file changes).


If you need to completely disable restart support, for example, because it doesn’t work with a specific library, you need to set a System property before calling SpringApplication.run(…​). For example:


public static void main(String[] args) {
    System.setProperty("spring.devtools.restart.enabled", "false");
    SpringApplication.run(MyApp.class, args);

20.2.4 Using a trigger file

If you work with an IDE that continuously compiles changed files, you might prefer to trigger restarts only at specific times. To do this you can use a “trigger file”, which is a special file that must be modified when you want to actually trigger a restart check. Changing the file only triggers the check and the restart will only occur if Devtools has detected it has to do something. The trigger file could be updated manually, or via an IDE plugin.


To use a trigger file use the spring.devtools.restart.trigger-file property.


You might want to set spring.devtools.restart.trigger-file as a global setting so that all your projects behave in the same way.



20.2.5 Customizing the restart classloader

As described in the Restart vs Reload section above, restart functionality is implemented by using two classloaders. For most applications this approach works well, however, sometimes it can cause classloading issues.

像前面的的Restart vs Reload部分所讲的那样,重启功能是通过两个类加载器实现的。对于大多数应用来说这个方法能很好的工作,但是有时候它也会引起一些类加载问题。

By default, any open project in your IDE will be loaded using the “restart” classloader, and any regular .jar file will be loaded using the “base” classloader. If you work on a multi-module project, and not each module is imported into your IDE, you may need to customize things. To do this you can create a META-INF/spring-devtools.properties file.


The spring-devtools.properties file can contain restart.exclude. and restart.include. prefixed properties. The include elements are items that should be pulled up into the “restart” classloader, and the exclude elements are items that should be pushed down into the “base” classloader. The value of the property is a regex pattern that will be applied to the classpath.


For example:



All property keys must be unique. As long as a property starts with restart.include. or restart.exclude. it will be considered.



All META-INF/spring-devtools.properties from the classpath will be loaded. You can package files inside your project, or in the libraries that the project consumes.



20.2.6 Known limitations

Restart functionality does not work well with objects that are deserialized using a standard ObjectInputStream. If you need to deserialize data, you may need to use Spring’s ConfigurableObjectInputStream in combination with Thread.currentThread().getContextClassLoader().


Unfortunately, several third-party libraries deserialize without considering the context classloader. If you find such a problem, you will need to request a fix with the original authors.


20.3 LiveReload

The spring-boot-devtools module includes an embedded LiveReload server that can be used to trigger a browser refresh when a resource is changed. LiveReload browser extensions are freely available for Chrome, Firefox and Safari from livereload.com.


If you don’t want to start the LiveReload server when your application runs you can set the spring.devtools.livereload.enabled property to false.


You can only run one LiveReload server at a time. Before starting your application, ensure that no other LiveReload servers are running. If you start multiple applications from your IDE, only the first will have LiveReload support.



20.4 Global settings

You can configure global devtools settings by adding a file named .spring-boot-devtools.properties to your $HOME folder (note that the filename starts with “.”). Any properties added to this file will apply to all Spring Boot applications on your machine that use devtools. For example, to configure restart to always use a trigger file, you would add the following:

通过添加一个名为.spring-boot-devtools.properties的文件到你的$HOME文件夹中(注意文件名以.开头),你可以配置全局开发者工具设置。任何添加到这个文件的属性都将应用到你机器上所有使用开发者工具的Spring Boot应用中。例如,为了配置重启时总是使用一个触发器文件,你需要添加如下内容:



20.5 Remote applications

The Spring Boot developer tools are not just limited to local development. You can also use several features when running applications remotely. Remote support is opt-in, to enable it you need to make sure that devtools is included in the repackaged archive:

Spring Boot开发者工具是不受本地环境限制的,在运行远程应用时你也可以使用一些功能。远程支持是选择性加入的,为了使它起作用你需要确保devtools包含在再打包的文件中:


Then you need to set a spring.devtools.remote.secret property, for example:



Enabling spring-boot-devtools on a remote application is a security risk. You should never enable support on a production deployment.



Remote devtools support is provided in two parts; there is a server side endpoint that accepts connections, and a client application that you run in your IDE. The server component is automatically enabled when the spring.devtools.remote.secret property is set. The client component must be launched manually.


20.5.1 Running the remote client application

The remote client application is designed to be run from within you IDE. You need to run org.springframework.boot.devtools.RemoteSpringApplicationusing the same classpath as the remote project that you’re connecting to. The non-option argument passed to the application should be the remote URL that you are connecting to.


For example, if you are using Eclipse or STS, and you have a project named my-app that you’ve deployed to Cloud Foundry, you would do the following:

  • Select Run Configurations…​ from the Run menu.

  • Create a new Java Application “launch configuration”.

  • Browse for the my-app project.

  • Use org.springframework.boot.devtools.RemoteSpringApplication as the main class.

  • Add https://myapp.cfapps.io to the Program arguments (or whatever your remote URL is).


  • Run菜单中选择Run Configurations…​

  • 创建一个新的Java Application “launch configuration”。

  • 浏览my-app工程。

  • 使用org.springframework.boot.devtools.RemoteSpringApplication作为主类。

  • 添加https://myapp.cfapps.ioProgram arguments(或无论你的远程URL是什么)。

A running remote client will look like this:


  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___|/ / / /
 :: Spring Boot Remote :: 2.0.0.BUILD-SNAPSHOT

2015-06-10 18:25:06.632  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication on pwmbp with PID 14938 (/Users/pwebb/projects/spring-boot/code/spring-boot-devtools/target/classes started by pwebb in /Users/pwebb/projects/spring-boot/code/spring-boot-samples/spring-boot-sample-devtools)
2015-06-10 18:25:06.671  INFO 14938 --- [           main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@2a17b7b6: startup date [Wed Jun 10 18:25:06 PDT 2015]; root of context hierarchy
2015-06-10 18:25:07.043  WARN 14938 --- [           main] o.s.b.d.r.c.RemoteClientConfiguration    : The connection to http://localhost:8080 is insecure. You should use a URL starting with 'https://'.
2015-06-10 18:25:07.074  INFO 14938 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2015-06-10 18:25:07.130  INFO 14938 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 0.74 seconds (JVM running for 1.105)

Because the remote client is using the same classpath as the real application it can directly read application properties. This is how the spring.devtools.remote.secret property is read and passed to the server for authentication.




It’s always advisable to use https:// as the connection protocol so that traffic is encrypted and passwords cannot be intercepted.




If you need to use a proxy to access the remote application, configure the spring.devtools.remote.proxy.host and spring.devtools.remote.proxy.port properties.



20.5.2 Remote update

The remote client will monitor your application classpath for changes in the same way as the local restart. Any updated resource will be pushed to the remote application and (if required) trigger a restart. This can be quite helpful if you are iterating on a feature that uses a cloud service that you don’t have locally. Generally remote updates and restarts are much quicker than a full rebuild and deploy cycle.


Files are only monitored when the remote client is running. If you change a file before starting the remote client, it won’t be pushed to the remote server.



20.5.3 Remote debug tunnel

Java remote debugging is useful when diagnosing issues on a remote application. Unfortunately, it’s not always possible to enable remote debugging when your application is deployed outside of your data center. Remote debugging can also be tricky to setup if you are using a container based technology such as Docker.


To help work around these limitations, devtools supports tunneling of remote debug traffic over HTTP. The remote client provides a local server on port 8000 that you can attach a remote debugger to. Once a connection is established, debug traffic is sent over HTTP to the remote application. You can use the spring.devtools.remote.debug.local-port property if you want to use a different port.


You’ll need to ensure that your remote application is started with remote debugging enabled. Often this can be achieved by configuring JAVA_OPTS. For example, with Cloud Foundry you can add the following to your manifest.yml:


    JAVA_OPTS: "-Xdebug -Xrunjdwp:server=y,transport=dt_socket,suspend=n"

Notice that you don’t need to pass an address=NNNN option to -Xrunjdwp. If omitted Java will simply pick a random free port.




Debugging a remote service over the Internet can be slow and you might need to increase timeouts in your IDE. For example, in Eclipse you can select Java → Debug from Preferences…​ and change the Debugger timeout (ms) to a more suitable value (60000 works well in most situations).


在网上调试一个远程服务可能是非常慢的,你可能需要在你的IDE中添加timeouts。例如,在Eclipse中你可以从Preferences…​选择Java → Debug,并将Debugger timeout (ms)改成更合适的值(60000在大多数情况下都能很好工作)。

21. Packaging your application for production

Executable jars can be used for production deployment. As they are self-contained, they are also ideally suited for cloud-based deployment.


For additional “production ready” features, such as health, auditing and metric REST or JMX end-points; consider adding spring-boot-actuator. See Part V, “Spring Boot Actuator: Production-ready features” for details.

对于其它的“production ready”功能,例如健康,审计和度量REST或JMX端点;考虑添加spring-boot-actuator。更多细节请看第五部分,“Spring Boot Actuator: Production-ready features”。

22. What to read next

You should now have good understanding of how you can use Spring Boot along with some best practices that you should follow. You can now go on to learn about specific Spring Boot features in depth, or you could skip ahead and read about the “production ready” aspects of Spring Boot.

现在你应该对怎么使用Spring Boot以及应该循序的一些最佳实践有了很好的理解。你可以继续学习关于Spring Boot的一些深度功能,或者你可以跳过前面,直接阅读Spring Boot “production ready”方面的内容。