Lots of questions here, but most of them boil down to the question of what kind of deployment options you have with Spring Boot and if you choose a conventional deployment option, then what benefit does Spring Boot provide...Okay...here goes...
If you're using the CLI, then you have two deployment options currently:
- Deploying to CloudFoundry by "cf push" from the project directory.
- Creating an executable JAR file with an embedded Tomcat or Jetty (with the "spring jar" command). This JAR can be pushed to CloudFoundry or with a Procfile, this can be deployed to other PaaS providers such as Heroku.
Of course, while you're developing the app, you can run the app with "spring run" and run tests with "spring test".
Stepping away from the CLI, you can build your app in a more conventional way using Maven or Gradle. The deployment options here are:
- Building an executable JAR file that is equivalent to what you'd get from the CLI with "spring jar". The same deployment options apply here.
- Building a WAR file that can be deployed to any
Servlet 3.0 container or Java-supporting PaaS providers like CloudFoundry. Optionally, you can make the WAR file executable so you get the best of both worlds...a deployable WAR and a command-line runnable distribution.
Let's say you go with the last option...the conventional WAR option. What are the benefits of Spring Boot in this case?
Well, autoconfiguration goes a *LONG* way here. Most apps will have some Spring configuration, but it is possible to write an app with little or no Spring configuration whatsoever. For an example see
https://github.com/habuma/spring-boot-examples/tree/master/contacts_war. This is a simple, but complete Spring application. The *ONLY* Spring configuration in this project are lines 7-9 in Application.java. Even then, one of those lines turns on autoconfiguration and another turns on component-scanning (a form of autoconfiguration that's been around since Spring 2.5). Note that there's no web.xml, no XML Spring configuration, and aside from those 3 lines in Application.java no Spring configuration at all. The main() method in Application.java is optional in this case, but I left it in to demonstrate how the WAR can be both deployable and executable. There is an application.yml file, but that's for application-level configuration, not Spring configuration.
In short: Spring Boot took a lot of boilerplate configuration off my hands so that I could focus on writing the code that implements the application functionality. *THAT* is the benefit of Spring Boot.
And, oh yeah, notice the build files mostly reference starter dependencies and no versions are specified (the starter parent defines those).
You also asked how the Actuator compares to JMX management. JMX offers the option for management of any bean in a Spring app. Actuator is more focused on what's going on Spring-wise. For example:
- What beans were created in the Spring container (whether auto-configured or explicitly configured)?
- What auto-configuration decisions were made?
- What environment and system properties are available to the app? What command-line parameters?
- What is the current state of the threads?
- What were some of the most recent requests? Did they succeed with HTTP 200? What were the headers on the requests and their responses?
- What is the health of my application components? (BTW, this one is pluggable, enabling you to provide your own health indicators.)
The best way to understand the benefits of Spring Boot is to try it out. Once you've written even a small app with Spring Boot, you'll hate having to go back to not using Spring Boot. There's just so much boilerplate you're responsible for if Spring Boot isn't in play.
Siegfried Heintze wrote:So if I build a new Spring MVC or Spring REST service that uses spring boot, what options do I have for deployment?
I was assuming deployent in production clouds like Microsoft Azure, Amazon AWS or Google App Engine basically mean dropping a WAR file into tomcat or jetty.
Is this still true with spring boot?
If so, how does spring boot help me (besides reducing configuation parameters)?
What new deployement options does spring boot give me?
What advantage is there to the CLI option for a production environent? I suppose it would save you the trouble of installing tomcat or jetty but I never found those to be particularly troublesome installations.
What is the difference between the features of the actuator and using MBeans and JConsole?
Are all these configuration parameters that spring boot saves me from in the web.xml and *context.xml files?
Thanks
siegfried