Instantly share code, notes, and snippets.

Embed
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;
@Component
public class ApplicationContextHolder implements ApplicationContextAware {
private static ApplicationContext applicationContext;
@Override
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);
}
}
@gpitteloud

This comment has been minimized.

Show comment
Hide comment
@gpitteloud

gpitteloud 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.

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.

@dprimax

This comment has been minimized.

Show comment
Hide comment
@dprimax

dprimax Jul 27, 2018

This gist save my day! Thank you so much.

dprimax commented Jul 27, 2018

This gist save my day! Thank you so much.

@augustodossantosti

This comment has been minimized.

Show comment
Hide comment
@augustodossantosti

augustodossantosti 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.

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.

@tuxianchao

This comment has been minimized.

Show comment
Hide comment
@tuxianchao

tuxianchao commented Aug 27, 2018

thanks

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