We Keep Coding

How does SpringBoot decrease boiler plate code?

I understand how SpringBoot saves time in other respects such as having an embedded server and starter dependencies, but how does SpringBoot reduce boiler plate code needed for an application?
Thanks

Spring Boot brings a ton of autoconfiguration classes, which create beans with default configurations, that would have been created by the developer themselves previously. An example would be beans for database access. You would have created a datasource, maybe a JdbcTemplate, connection pool etc. Now those beans are created with autoconfiguration (example: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jdbc/DataSourceAutoConfiguration.java), and configuration can be customized through application.properties files.

Spring boot comes with starters and through maven you can search for the required dependency and add it to your project it supports rapid development and below are some key features of spring boot
Removes boilerplate code of application setup by having embedded web
server(Tomcat) and in memory db.
Auto configuration of application context.
Automatic servlet mappings.
Embedded database support(h2)
Automatic controller mapping

You can look at Spring Boot as an opinionated distribution of Spring. It comes with sane defaults and machanisms to hide the boilerplate while still making changes to those defaults possible.

When you use annotations #SpringBootApplication, Spring boot takes care of creating all the beans required for running WebServer and injecting it using its Dependency Injection feature.
#SpringBootApplication is alone equivalent to below three annotations.
#Configuration : You can define your own configuration class to register your beans in application context.
2.#EnableAutoConfiguration : Spring automatically creates beans available on your classs path using this feature.More details are available here.
#ComponentScan : Scans the current and base package where your application class lies.
It Creates ApplicationContext which contains all the necessary beans, ServletWebServerApplicationContext is one such bean created which takes care of initializing and running a WebServer by looking for ServletWebServerFactory bean(provides the webServer) within the ApplicationContext.
There is lot more going on behind the scene. Here is a video which explains it in details.
https://youtu.be/uCE3x4-GQ0k
https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/web/servlet/context/ServletWebServerApplicationContext.html

Workaround to using #ImportResource for XML config files

I am developing an application that runs on Spring Boot configured via XML. For modularity, I didn't want to use #ImportResource as it requires me to go into the source code when in XML configuration I can just configure the XML files to change dependencies.
The problem is that I'm using Spring Boot to run my Spring MVC Controllers (#Controller) and for me to make use of the dependencies I configured in my XML files, I need to declare #ImportResource, which I don't want to use.
Is there any workaround to not use #ImportResource while still using XML config files to inject the dependencies in my Spring MVC Controllers?

If you are using spring boot and you are ok with mentioning the config location in application properties, you can do this in application.properties
config:
location: file:///config.xml
And the you can use this property in your #ImportResource
#ImportResource("${config.location}")
This way you can avoid changes to the source code, while still using xml configuration.

spring boot parent for jar file

I want to create a jar file that I can add to a classpath and will basically "plug-in" to an existing spring boot application. I need it to be able to have annotations of Component, ConfigurationProperties, and all the fun things that spring boot gives you, but I want it "thin" and it will be a jar file used as part of a full spring boot web application.
I need the jar file to be externally configurable. Property files will be different for different deployments. So having a working #Configuration annotation is critical.
I look at spring-boot-starter-parent, and that has jetty, tomcat, hibernate stuff and is a huge jar file. I don't want that.
Is there a "thin" parent?
Is spring boot simply not what I want here? And I should just use a regular spring project and set my "Main" spring boot web app to do component scans to configure the jar file?

It sounds like you are trying to define your own Spring Boot Starter. That's the real power that Spring Boot gives you, the ability to include a dependency and have it auto-configure itself.
By packaging your jar the right way, Spring Boot will detect that there are configurations, components, and property files automatically. I've used this in the past for the case where I want all of my applications to log a specific way, or enforce a certain format for my REST endpoints.
The documentation gives a very thorough overview of the steps you'll need to take. But essentially, you are going to package your jar like any other (with your #Bean, #Component, #Service, and #Configuration classes in it), and provide a property file pointing to the configurations:
// Example spring.factories file
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.mycorp.libx.autoconfigure.LibXAutoConfiguration,\
com.mycorp.libx.autoconfigure.LibXWebAutoConfiguration
Also check out the set of #ConditionalOn... annotations, they can really help with controlling what beans become active based on properties being defined, profiles being active, or dependencies being loaded.

Ease of rolling back from Spring Boot to regular Spring and viewing hybrid of Spring Context and configurations while using Spring Boot

I am assessing whether spring-boot and how I could migrate to using it.
One question I have is whether a project that uses spring boot can be converted easily back to a regular spring project which uses the traditional spring configuration files if that is required. This would be useful in my mind for a few reasons.
1) merging with legacy projects, because as I have read moving from legacy spring to spring-boot is somewhat tedious.
2) Obtaining a view of the spring application context file and webapp configuration files to understand what the actual configurations being used are.
Another question I have is regarding the lack of application-context file, is there a way to have some kind of hybrid where there is still an application-context file that can be seen? Part of my concern is that spring-boot auto configures components without us knowing and learning how they are configured and work together.

Spring Boot provides auto-configuration.
When #SpringBootApplication is encountered, it triggers a search of the CLASSPATH for a file called META-INF/spring.factories which is just a regular text file that enumerates a list of Java configuration classes. Java configuration was introduced in 2006 and then merged into Spring 3 in 2009. So it's been around for a long time. These Java configuration classes define beans in the same way that XML does. Each class is annotated with #Configuration and therein you find beans defined using methods (factory methods, or provider methods) whose return value is managed and exposed via Spring. Each such provider method is annotated with #Bean. This tells Spring to consider the method and its return value the definition of the bean.
Spring Boot tries to launch all the Java configurations it sees enumerated in that text file. It tries to launch RabbitAutoConfiguration.class, which in turn provides beans for connecting to RabbitMQ and so on. Of course, you don't want those beans in certain cases, so Spring Boot takes advantage of Spring framework 4's #Conditional mechanism to conditionally register those beans only if certain conditions are met: is a type on the CLASSPATH, is a property exposed through the environment, has there been another bean of the same type defined by the user, etc. Spring boot uses these to only create the RabbitMQ-specific beans if, for example, the dependencies that you would get from org.springframework.boot:spring-boot-starter-amqp are on the CLASSPATH. It also considers that the user may have provided a different implementation of RabbitTemplate in some othe rbean definition (be it XML or Java configuration) so it uses that if it's there.
These java configuration classes are the same sort of Java configuration classes you would write without Spring Boot. BUT... WHY? 80% of the time, the auto-configuration that Spring Boot provides is going to be as good or better than the configuration you would write yourself. There are only so many ways to configure Spring MVC, Spring Data, Spring Batch, etc., and the wager you take using Spring Boot is that the leaders and engineers on those various projects can provide the most sensible 80%-case configuration that you probably don't care to write, anyway.
So, yes you could use Spring Boot with existing applications, but you'd have to move those existing applications to Spring 4 (which is easy to do if you're using the spring-boot-starter-* dependencies) to take advantage of #Conditional. Spring Boot prefers: NO configuration, Java configuration, XML configuration, in that order.
If you have an existing application, I'd do the following:
find out what dependencies you can remove from your Gradle/Maven build and just have taken care of for you with the various spring-boot-starter- dependencies.
add #SpringBootApplication to a root component class. Eg, if your package is a.b.c, put a class Application in a.Application and annotate that with #SpringBootApplication
You can run it as a Servlet 3 application or in an embedded servlet container. It might be easier to just run in a standard servlet container as you take baby steps. Go to http://start.spring.io and make sure to choose war in the packaging drop down. Copy the ServletInitializer class and the specification from the pom.xml to ensure that your application is a .war, not a .jar. Then, once everything works on Spring Boot, rm -rf the Initializer and then revert the Maven build to a simpler .jar using the Spring Boot plugin for extra win.
If your application has lots of existing configuration, import it using #Import(OldConfig.class) or #ImportResource("old-config.xml") on the a.Application configuration class. The auto-configuration will kick in but it will see, for example, that you may have already defined a DataSource so it'll plug that in in the right places. What I like to do now is just start the application up, see if everything's OK, then start removing code in my old Java or XML configuration. Don't remove your business code, but remove things related to turning on parts of Spring. Anything that looks like #Enable..* or ..:annotation-driven/>. Restart and verify things still work. The goal is to let Spring Boot do as much of the heavy lifting as possible. Viewing the source is very handy here so you can see what Spring Boot will try to do for you. Spring Boot will log information on what #Conditional conditions evaluated to true for you. Simply provide --Ddebug=true wen you start the application to see the output. You could also export DEBUG=true then restart your IDE to run it as long as the environment variable is ivsible in your shell.

Grails app using services from spring-mvc backend

We have a fairly involved web application written using spring-mvc with a maven build system and would like to harness all the power of Grails for the front end.
So the Grails app will essentially call into the spring-mvc app's service layer to access its business logic and data.
I need some guidance with my architectural approach to this integration at a high level.
From my understanding, I will need to;
- add my spring-mvc app as a compile dependency in my BuildConfig.groovy.
- Expose the service layer objects as service beans in my conf/spring/resources.groovy and inject them into my controllers
Questions:
My spring-mvc app has lots of dependencies of its own (which it obviously has to have) which are causing lots of dependency errors. Should I be setting "transitive=false" in my config and calling all of these in my Grails app?
How should the datasource get configured? I guess I have to integrate the applicationContext of my spring-mvc app by calling it from my Grails applicationContext and hope it all bootstraps nicely?

So the Grails app will essentially call into the spring-mvc app's service layer to access its business logic and data
Can you be a bit more specific about which components of the Spring MVC you want to use from Grails, is it just the services and datasource?
I will need to add my spring-mvc app as a compile dependency in my BuildConfig.groovy
yes
Expose the service layer objects as service beans in my conf/spring/resources.groovy
Although you could make the Spring beans known to your Grails app by defining them individually in resources.groovy, this is unnecessary because you've already defined them in an Spring XML file (presumably) in the Spring MVC project.
Instead you can use the importBeans method of the BeanBuilder to import the Spring beans defined in this XML file into the Grails app. Once you've added the Spring MVC project as a dependency of your Grails app, the Spring XML file should be on your classpath, so all you need to do is add the following to resources.groovy
beans = {
importBeans('classpath:/path/to/file/applicationContext-services.xml')
}
How should the datasource get configured?
A Spring bean named dataSource defines the datasource that a Grails app uses. In a standard Grails app, this bean is created based on the configuration in DataSource.groovy. If your Spring MVC app defines a bean with this name, then this should be used instead after making the changes above. To be sure that Grails is using the datasource from your Spring MVC app rather than whatever is in DataSource.groovy, I guess you could delete the contents of the latter.