I have a web project, and I depoly it on tomcat easily. Infact I have a WebAppInitializer class that implements WebApplicationInitializer (this class it's really fat), as you know every application server that supports servlet 3.0, it can easily detect it and try to boot it. Now I wonder that it could be possible to use spring boot starter and without any further configuration, I pass my WebAppInitializer to it and spring boot based on my WebAppInitializer boots my project?
I just want to use the approach of spring-boot to deploy application on Tomcat and I don't want to use other spring-boot's facilities.
Yes, it's an old question. But I do not see an accepted answer and the one closest to a working one only has a link to an external resource. So here it is.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-embedded-container-context-initializer
28.4.2 Servlet Context Initialization
Embedded servlet containers do not directly execute the Servlet 3.0+
javax.servlet.ServletContainerInitializer interface or Spring’s
org.springframework.web.WebApplicationInitializer interface. This is
an intentional design decision intended to reduce the risk that third
party libraries designed to run inside a war may break Spring Boot
applications.
If you need to perform servlet context initialization in a Spring Boot
application, you should register a bean that implements the
org.springframework.boot.web.servlet.ServletContextInitializer
interface. The single onStartup method provides access to the
ServletContext and, if necessary, can easily be used as an adapter to
an existing WebApplicationInitializer.
Scanning for Servlets, Filters, and listeners
When using an embedded
container, automatic registration of classes annotated with
#WebServlet, #WebFilter, and #WebListener can be enabled by using
#ServletComponentScan.
[Tip] #ServletComponentScan has no effect in a standalone container,
where the container’s built-in discovery mechanisms are used instead.
I've tried it. It works
In my use case I have project containing a few dozens of webapps, designed to run on Tomcat as WAR. Lots of logics was neatly crafted into WebApplicationInitializers and it seemed there should be an easier way to reuse all this. Adding implements ServletContextInitializer to those initializers and exposing them as beans through #Configuration classes lit my webservers up with SpringBoot's embedded Tomcat.
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-create-a-deployable-war-file describes precisely how to do it
From the Spring Boot docs:
Servlet 3.0+ applications might translate pretty easily if they already use the Spring Servlet 3.0+ initializer support classes. Normally all the code from an existing WebApplicationInitializer can be moved into a SpringBootServletInitializer. If your existing application has more than one ApplicationContext (e.g. if it uses AbstractDispatcherServletInitializer) then you might be able to squash all your context sources into a single SpringApplication. The main complication you might encounter is if that doesn’t work and you need to maintain the context hierarchy. See the entry on building a hierarchy for examples. An existing parent context that contains web-specific features will usually need to be broken up so that all the ServletContextAware components are in the child context.
So yes, it's possible but you need to convert it to SpringBootServletInitializer, which seems to be quite similar.
Related
And most important, what's the reason behind the "Auto" prefix? Classes annotated with #Configuration rather than #AutoConfiguration are less automatic or something?
#Configuration is a spring framework annotation and not strictly bound to spring-boot. It was introduced when spring started to allow programmatic creation of spring-beans as to move forward from xml definitions of beans.
#AutoConfiguration is a spring-boot specific annotation not commonly available in spring framework. The reason it exists, is for external providers that cooperate with spring-boot to be able to mark some classes in some libraries they provide with this annotation as to inform spring-boot that those classes could be parsed and make some initializations during start up of spring application automatically.
So if some regular programmer that develops some application happens to have kafka in dependencies then some beans will automatically be created and added in application context and will be ready for the programmer to use, although he has not defined any configuration for them. Spring-boot already knows this as the kafka provider has already informed by marking some class in the jar they provide with the annotation #AutoConfiguration.
For this reason #AutoConfiguration has some more powerful configurations available as before, after, beforeName, afterName as to allow the provider to specify when the configuration is applied during application startup if some order is necessary.
So this annotation is not to be used from some regular programmer that develops an application using spring-boot. It is for someone that develops a library that other users might use with spring-boot. One such example is kafka library.
For this to work in a spring-boot project #EnableAutoConfiguration is needed as well, to enable auto configuration.
From spring documentation
Spring Boot auto-configuration attempts to automatically configure
your Spring application based on the jar dependencies that you have
added. For example, if HSQLDB is on your classpath, and you have not
manually configured any database connection beans, then Spring Boot
auto-configures an in-memory database.
#Configuration instead is to be used from some regular programmer that develops an application using spring-boot or spring-framework as to inform the framework for which beans should be created and how.
#AutoConfiguration was introduced in 2.7 with the idea to mark all auto-configurations with its dedicated annotation and move away from spring.factories for auto-configuration imports in 3.0 as described in Github issue.
According to Spring documentation:
[#AutoConfiguration] indicates that a class provides configuration that can be
automatically applied by Spring Boot. Auto-configuration classes are
regular #Configuration with the exception that
Configuration#proxyBeanMethods() proxyBeanMethods is always false.
Usually, #AutoConfiguration classes automatically configure an application based on the dependencies that are present on the classpath. Those classes are generally marked as #ConditionalOnClass and #ConditionalOnMissingBean annotations that detect the presence or absence of specific classes.
Additionally, if a configuration needs to be applied in a specific order, you can use the before, beforeName, after, and afterName attributes on the #AutoConfiguration, unlike #Configuration which doesn't provide those attributes.
I'm totally new to Kafka and terribly confused by this:
https://docs.spring.io/spring-kafka/reference/html/#with-java-configuration-no-spring-boot
I don't understand what that even means. What does "no spring boot mean" because that example sure as hell uses spring boot. I'm so confused....
EDIT
if I'm using SpringBoot and spring-kafka, should I have to manually create #Bean ConcurrentKafkaListenerContainerFactory as shown here. Most of the examples in the docs for setting up filtering / config / etc seem to use the "manual" configuration using #Bean. Is that "normal"? The docs are very confusing to me...especially this warning:
Spring for Apache Kafka is designed to be used in a Spring Application Context. For example, if you create the listener container yourself outside of a Spring context, not all functions will work unless you satisfy all of the …Aware interfaces that the container implements.
It's referring to the autowired configuration, as compared to putting each property in the config via HashMap/Properties in-code.
Also, it does not use #SpringBootApplication or SpringApplication.run, it just calls a regular main method using a hard-coded Config class.
Spring boot contains the functionality of AutoConfiguration
What this means is that spring boot when discovers some specific jar dependencies it knows, in the project, it automatically configures them to work on a basic level. This does not exist in simple Spring project where even if you add the dependency you have to also provide the configuration as to how it should work in your application.
This is also happening here with dependencies of Kafka. Therefore the documentation explains what more you have to configure if you don't have spring-boot with auto-configuration to make kafka work in a spring project.
Another question asked in comment is what happens in case you want some complex custom configuration instead of the automatic configuration provided while you are in a spring-boot app.
As documented
Auto-configuration tries to be as intelligent as possible and will
back-away as you define more of your own configuration. You can always
manually exclude() any configuration that you never want to apply (use
excludeName() if you don't have access to them). You can also exclude
them via the spring.autoconfigure.exclude property.
So if you want to have some complex configuration which is not automatically provided by spring-boot through some other mechanism like a spring-boot specific application property, then you can make your own configuration with your custom bean and then either automatic configuration from spring-boot for that class will back of as spring does several intelligent checks during application context set up or you will have to exclude the class from auto configuration manually.
In that case you could probably take as an example reference of how to register manually your complex configurations in spring boot what is documented on how to be done in non spring boot app. doc
I'm currently trying to shift my existing dynamic web project to Spring boot project and it uses web.xml for servlet mapping. I understand that spring would ignore the web.xml file, what should be the correct approach for spring to use the existing web.xml? And yes, I still need to stick to using web.xml for this project.
I'm kinda new to this, please guide me through! Thanks!
I suppose that you need to stick with a web.xml because your container uses an older version of Servlet than 3.0.
Spring Boot is built on Servlet 3.0. You have to update your main class to extend SpringBootServletInitializer and override configure method, which tells spring to use its Servlet 3.0 support. Embedded containers like Tomcat need Servlet 3.0, so if you want to start your project during the development process (including JUnit tests) in embedded containers, I think, from what I know, the only way is to rewrite your web.xml to Servlet 3.0 java config. But if you really want to deploy you app in an older container, you still can by using spring-boot-legacy module. It allows you to use web.xml for older containers; only thing you have to do is to add
org.springframework.boot.legacy.context.web.SpringBootContextLoaderListener in your web.xml.
For more information about deploying war in an old container, take a look at Spring Boot's official documentation.
Spring Boot uses Servlet 3.0 APIs to initialize the ServletContext
(register Servlets etc.) so you can’t use the same application out of
the box in a Servlet 2.5 container. It is however possible to run a
Spring Boot application on an older container with some special tools.
If you include org.springframework.boot:spring-boot-legacy as a
dependency (maintained separately to the core of Spring Boot and
currently available at 1.0.2.RELEASE), all you should need to do is
create a web.xml and declare a context listener to create the
application context and your filters and servlets.
This is a very old question, but I'm currently on the same situation and I will share my experience.
I extended the SpringBootServletInitializer class to create my #SpringBootApplication, and it will INCLUDE your web.xml configuration by default. I'm still able to declare or edit existing servlet mapping, and it will be taken in account.
I'd like to write a unit (component) test for a REST resource of my web application. This test should target the exposed REST interface and test its behaviour by issuing requests and checking the responses.
The web application is configured without the use of web.xml and applicationContext.xml by making use of Spring's WebApplicationInitializer. This works fine when I just run the application on my (Tomcat) server.
When starting my Arquillian test, the ShrinkWrap archive is deployed on the embedded Tomcat server. As the embedded server runs with the classpath of my web application, it also finds my WebApplicationInitializer class. This is problematic, as it loads lots of dependencies, and should just be activated for the test.
How can I deactivate my WebApplicationInitializer (and provide an alternative implementation) in the test?
When using XML configuration files this corresponds to hiding the real configuration files and using a specific (empty?) configuration which is used in the test.
I worked around this issue by just disabling my WebApplicationInitializer instance using a static field which I set in Arquillian's #Deployment method.
You might also want to look into metadata-complete which causes Tomcat to not invoke the Spring part which delegates to the WebApplicationInitializer instance.
There are many people who advised me to use Spring Boot instead of Spring to develop REST web services.
I want to know what exactly the difference between the two is?
In short
Spring Boot reduces the need to write a lot of configuration and boilerplate code.
It has an opinionated view on Spring Platform and third-party libraries so you can get started with minimum effort.
Easy to create standalone applications with embedded Tomcat/Jetty/Undertow.
Provides metrics, health checks, and externalized configuration.
You can read more here http://projects.spring.io/spring-boot/
Unfortunately and I mean this out of personal frustration with Spring boot, I have yet to see any real quantified list, where the differences are explicitly outlined.
There is only qualifications such as the rubbish sentence "...opinionated view..." which are bandied about.
What is clear, is that SpringBoot has wrapped up groups of Spring annotations into its own set of annotations, implicitly.
Further obfuscating, and making the need for anyone starting out in SpringBoot to have to commit to memory what a particular SpringBoot annotation represents.
My reply therefore is of no quantifiable benefit to the original question, which is analogous to that of the SpringBoot authors.
Those behind Spring IMO deliberately set-out to obfuscate, which reflects the obtuseness of their JavaDoc and API's (see SpringBatch API's as an example, if you think I am flaming) that makes one wonder the value of their open-source ethos.
My quest for figuring out SpringBoot continues.
Update. 22-08-2022
Read this (https://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.auto-configuration) and you will figure out for yourself what "opinionated" means.
There are over 140 Config classes that Springboot can use for this opinionated view, depending on what is on your classpath.
yes, on your classpath.
Finally and bizzarely, the annotation #SpringBootApplication is a configuration annotation as it includes it.
Go figure :=)
Basically, Spring Boot is an opinionated instance of a Spring application.
Spring Boot is a rapid application development platform. It uses various components of Spring, but has additional niceties like the ability to package your application as a runnable jar, which includes an embedded tomcat (or jetty) server. Additionally, Spring Boot contains a LOT of auto-configuration for you (the opinionated part), where it will pick and choose what to create based on what classes/beans are available or missing.
I would echo their sentiment that if you are going to use Spring I can't think of any reasons to do it without Spring Boot.
Spring Boot is opinionated view of Spring Framework projects.Let's analyse it through one program taken from Spring Boot Documentation.
#RestController
#EnableAutoConfiguration
public class Example {
#RequestMapping("/")
String home() {
return "Hello World!";
}
public static void main(String[] args) throws Exception {
SpringApplication.run(Example.class, args);
}
}
It's a very basic REST API and you need to add Spring-boot-starter-web in your POM.xml for the same. Since you have added starter-web dependency, the annotation
#EnableAutoConfiguration guesses that you want to develop a web application and sets up Spring accordingly.
Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added. For example, if HSQLDB is on your classpath, and you have not manually configured any database connection beans, then Spring Boot auto-configures an in-memory database.
It's opinionated like maven. Maven creates a project structure for you which it thinks is the general pattern of projects like it adds src/main/java folder or resource folder for you.
Spring boot helps in faster development. It has many starter projects that helps you get going quite faster. It also includes many non functional features like: embedded servers, security, metrics, health checks etc. In short, it makes, spring based application development easier with minimally invading code(Less configuration files, less no of annotations).
Reference: https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-documentation-about
For developing common Spring applications or starting to learn Spring, I think using Spring Boot would be recommended. It considerably eases the job, is production ready and is rapidly being widely adopted.
Spring Boot is supposedly opinionated, i.e. it heavily advocates a certain style of rapid development, but it is designed well enough to accommodate exceptions to the rule, if you will. In short, it is a convention over configuration methodology that is willing to understand your need to break convention when warranted
For Spring Framework, you need to configure your project using XML configuration or Java configuration.
But for Spring Boot, these are preconfigured according to Spring team's view for rapid development. That is why Spring Boot is said to be an "opinionated view" of Spring Framework. It follows Convention over Configuration design paradigm.
Note: These configurations include view resolvers for MVC, transaction managers, way of locating container managed beans (Spring beans) and many more. And of course you can override any of these preconfigurations according to your need.
Spring Boot supports embedded servlet containers like Tomcat, Jetty or Undertow to create standalone applications, which Spring Framework doesn't.
Spring eliminate boilerplate code.
Spring-boot eliminates boilerplate configurations.
more