Instantly share code, notes, and snippets.

What would you like to do?
Utility bean for getting Spring beans from static context.
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Component;
public class ApplicationContextHolder implements ApplicationContextAware {
private static ApplicationContext applicationContext;
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
synchronized (this) {
if (ApplicationContextHolder.applicationContext == null) {
ApplicationContextHolder.applicationContext = applicationContext;
public static <T> T getBean(Class<T> clazz) {
return applicationContext.getBean(clazz);
public static <T> T getBean(String qualifier, Class<T> clazz) {
return applicationContext.getBean(qualifier, clazz);

This comment has been minimized.

gpitteloud commented Jul 6, 2018

This looks like a very simple solution to a common problem, but it brings lots of trouble when used in a non-trivial appliation, for the following reasons:

  • Memory issues: if you redeploy the WAR without restarting the VM, you end up with 2 application contexts in the same VM: the one attached to the static field of ApplicationContextHolder and the new one that is stored in the ServletContext. This is just the same issue as the commons-logging memory issue.
  • Tests: if you use spring tests, you will have multiple application contexts in the same VM when running a suite, but only the one loaded from the first test is stored in the static field.
  • Application context hierarchy: It is quite common to have a "services application context" and a "web application context" (and a DispatcherServlet application context), each one being a child of the previous one. Only the root (services) application context will be stored in the static variable, and thus you have a lot of beans that are not accessible.

There are "solutions" to fix each of these issues, but each one adds new more complex problems. I started building such a class and finally abandoned due to the growing complexity.
Best is to rely on singleton objects in the context of an application, just like the ServletContext, or the TestContext, and to stick to it.


This comment has been minimized.

dprimax commented Jul 27, 2018

This gist save my day! Thank you so much.


This comment has been minimized.

augustodossantosti commented Aug 16, 2018

It's a good solution, the only problem is that sonar indicates an error because the static field is wrote from a instance method.


This comment has been minimized.

tuxianchao commented Aug 27, 2018


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment