I have gone through some tutorials and learnt that ApplicationContext is responsible for managing all the beans created in the spring application. When the WAR is to be deployed to a servlet container, it is essential to extend SpringBootServletInitializer and from the documentation it says
An opinionated WebApplicationInitializer to run a SpringApplication from a traditional WAR deployment. Binds Servlet, Filter and ServletContextInitializer beans from the application context to the server.
Can someone help me understand what the above line means ? How ServletContext initializer is related to the SpringBootServletInitializer ? Why can't a servlet container create a ServletContext on it's own ? If this the case how can we get the hold of ServletContext reference of a SpringApplication programatically created by Tomcat after using SpringBootServletInitializer?
The web application uses the static main entry point when you run the embedded application server. The main entry point usually looks like this:
public static void main(final String[] args) {
SpringApplication.run(Application.class, args);
}
or this:
public static void main(final String[] args) {
SpringApplication springApplication = new SpringApplicationBuilder(Application.class)
.properties("spring.main.banner-mode=log")
.build();
springApplication.run(args);
}
Both use the SpringApplication.run method to scan, configure, and run the web application.
The static main doesn't mean anything to an application server. Instead we add a SpringBootServletInitializer implementation that implements in turn the WebApplicationInitializer interface.
Interface to be implemented in Servlet 3.0+ environments in order to configure the ServletContext programmatically -- as opposed to (or possibly in conjunction with) the traditional web.xml-based approach.
Implementations of this SPI will be detected automatically by SpringServletContainerInitializer, which itself is bootstrapped automatically by any Servlet 3.0 container. See its Javadoc for details on this bootstrapping mechanism.
The SpringServletContainerInitializer gets bootstrapped by the Servlet 3.0+ container and executes the WebApplicationInitializer.onStartup(ServletContext context) methods to configure the ServletContext.
We implement the SpringServletContainerInitializer to define the SpringApplication[s] to be run.
The application server can create a ServletContext on its own, it just can't configure the ServletContext on its own.
Why do you want access to the ServletContext? Spring will handle the configuration for you.
Related
I have multiple application servers on my classpath, namely Netty via spring-boot-starter-webflux and Tomcat through another dependency chain. How can I determine which application server to use in Spring Boot?
Currently, Tomcat is being started instead Netty.
Important note: I can't exclude any of them, Tomcat is used by CXF, Netty is used by WebClient.
Just use proper spring-boot-starter-package
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html
In your case it will be probably spring-boot-starter-reactor-netty
Also it would be wise to exclude multiple JEE embedded containers and remove those you don't need.
You can specify the application is reactive directly in you configuration at startup something like this
#Configuration
#EnableAutoConfiguration
public class Application {
public static void main(final String[] args) {
final SpringApplication springApplication = new SpringApplication(Application.class);
springApplication.setWebApplicationType(WebApplicationType.REACTIVE);
springApplication.run(args);
}
}
I have a Spring MVC application, using Hibernate for my entities persistence management. I am able to build, deploy and run it on some application server such as glashfish or tomcat, all is fine.
Now, I want to convert it into a Spring Boot application. I added the following class:
#SpringBootApplication
public class Application extends SpringBootServletInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Application.class);
}
public static void main(String[] args) {
ConfigurableApplicationContext context =
SpringApplication.run(Application.class, args);
}
}
and added the spring-boot, spring-boot-autoconfigure, and spring-boot-starter-tomcat dependencies to my pom.
Alas, when trying to run the application, I get the following error:
BeanCurrentlyInCreationException: Error creating bean with name
'MyClassDAO': Bean with name 'MyClassDAO' has been injected into
other beans [MyOtherClassDAO] in its raw version as part of a circular
reference, but has eventually been wrapped. This means that said other
beans do not use the final version of the bean. This is often the result
of over-eager type matching - consider using 'getBeanNamesOfType' with
the 'allowEagerInit' flag turned off, for example.
I don't know how to use 'getBeanNamesOfType' and set the allowEagerInit off (I do not use XML configuration). Of course, I'm not sure this would solve my issue anyway.
Any ideas on how I can fix this?
If it's really some intilization issue then i believe the you must be having your class in other package and due to some cache issues it doesn't include those classes in class path to scan in container so to do this manually you can put a annotation just below #springbootapllication is #EnableComponentScan("enter the package name of the class which is not initializing") also on that dao class put #service or #component annotation to let the application include then in container
I want to create a Java deamon process (MQ processor) which can be run both from the commandline (java -jar ...) but also as WAR inside a JEE Container like Tomcat. It should automatically start once the WebApp starts. This App is not going to have a WebGUI.
It seems that I can use SpringBoot for this. SpringBoot can both create WAR and JAR-files.
My question is: should I use SpringBoot ApplicationRunner for a portable daemon?
What is the best practice/recipe to create a portable (CLI/WebApp) daemon process with SpringBoot?
How does this work under the hood? If I use ApplicationRunner and create a WAR, does SpringBoot create a Servlet of this?
Tx
ApplicationRunner is new in Spring Boot 1.4. It is similar to CommandLineRunner of Spring Boot 1.3. It isn't involved in the wiring up of the Application context as such that interface wouldn't be responsible for creating any Servlets in the WAR deployment. Here is details on deploying your app as a WAR:
http://docs.spring.io/spring-boot/docs/current/reference/html/howto-traditional-deployment.html
#SpringBootApplication
public class Application extends SpringBootServletInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Application.class);
}
public static void main(String[] args) throws Exception {
SpringApplication.run(Application.class, args);
}
}
The SpringBootServletInitializer is what will create the servlet.
Now I am not sure how you are setting up the MQ processor but if it is wired up as a bean and has some listener thread for messages on a queue then you don't really need the ApplicationRunner. You would just need to wire up the processor as a bean and have a #PostConstruct annotation on it so that you can start the listener thread. If you don't have control of the annotations on the bean then you can use the ApplicationRunner and have it Autowired with the processor bean. The runner would then start up the listener thread.
I am facing a classloader leak which I was able to repoduce it in a small project with only two classes and a few lines of code. It occurs as soon as a logger (Log4j2) is used.
Problem:
When deploying the application multiple times, the classes get loaded again and again until the PermGen space reaches its limit.
Steps to reproduce:
Download this small Maven-Project containing two classes. They are also depicted below.
Deploy application on a standard tomcat 7
Start jvisualvm and monitor the tomcat instance
Undeploy the application
Deploy the application again... even if you hit the 'perform gc' button, the classes will not be removed.
What I already tried without success:
Using the logger in a non-static field
Starting the VM with "-XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC"
Defining the logger in a Spring bean
Do you have any ideas, how to solve the problem?
Thanks in advance!
Here is the code contained in the project referenced above:
SpringContextInitializer.java (based on
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html)
public class SpringContextInitializer implements WebApplicationInitializer {
#Override
public void onStartup(final ServletContext servletContext) throws ServletException {
servletContext.addListener(new Log4jServletContextListener());
servletContext.setAttribute("isLog4jAutoInitializationDisabled", false);
servletContext.setAttribute("log4jConfiguration", "classpath:log4j2.xml");
// Load a spring context and manage the lifecycle of the root
// application context
final AnnotationConfigWebApplicationContext appContext = new AnnotationConfigWebApplicationContext();
appContext.register(SpringConfiguration.class);
servletContext.addListener(new ContextLoaderListener(appContext));
// Enable the use of a session scope
servletContext.addListener(new RequestContextListener());
}
}
SpringConfiguration.java
#Configuration
public class SpringConfiguration {
private static final Logger LOGGER = LogManager.getLogger(SpringConfiguration.class.getName());
}
There are a number of known memory leak issues with log4j version 2.4 and 2.4.1. The upcoming version log4j-2.5 will address all of these.
A general question about building a war from a spring boot application and running it in a standalone servlet container. The documentation I've seems seems at odds with examples on Stack Overflow.
The answer here shows the way I read of doing this a couple of months ago. I read this here, but the guide seems to have changed losing the actual example app.
Here the "configure" method references the main spring boot Application.class.
public class WebInitializer extends SpringBootServletInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Application.class);
}
}
There are also these posts here and here that show the "configure" method referring to the SpringBootServletInitializer sub class itself.
public class BootStrap extends SpringBootServletInitializer {
public static void main(String[] args) {
SpringApplication.run(BootStrap.class, args);
}
#Override
protected SpringApplicationBuilder configure(
SpringApplicationBuilder application) {
return application.sources(BootStrap.class);
}
}
and also there is a main method.
Also the spring-boot-sample-traditional  example app at https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples, which shows "WAR packaging"
does it differently
public class WebConfig extends WebMvcConfigurerAdapter {.........
I was wondering is there are issues with choosing over these different ways of seemingly achieving the same thing in spring boot? Or do they all work equally as well and are interchangeable?
Having your main application class extend SpringBootServletInitializer (Bootstrap in your question) or using a separate class (WebInitializer in your question) is down to personal taste. My preference is to take the Bootstrap approach but they both work in the same way; pick which ever you prefer.
If you are only going to deploy your application to a standalone servlet container then you don't need a main method. The main method is used if you want to run the application as an executable war (java -jar my-app.war), or you want to be able to run it directly in your IDE, i.e. without having your IDE deploy it to a servlet container.
spring-boot-sample-traditional illustrates the use of web.xml to Bootstrap a Spring Boot application. Generally speaking, this isn't a recommended approach unless you're stuck on a Servlet 2.5 container. The use of WebMvcConfigurerAdapter has nothing to do with WAR packaging. Take a look at its web.xml to see the relevant pieces of configuration.
Use Spring Initializr
http://start.spring.io/
Choose your project type (Gradle or Maven) and Packaging as war.
Add Web as dependency and Generate the project.
This will bootstrap your app with the "correct" way.