Получение Контекста Приложения Spring
есть ли способ статически / глобально запросить копию ApplicationContext в приложении Spring?
предполагая, что основной класс запускается и инициализирует контекст приложения, нужно ли передавать его через стек вызовов любым классам, которым он нужен, или есть способ для класса запросить ранее созданный контекст? (Который, я полагаю, должен быть синглтоном?)
11 ответов
Если объект, который нуждается в доступе к контейнеру, является Бобом в контейнере, просто реализуйте BeanFactoryAware или ApplicationContextAware интерфейсы.
Если объект вне контейнера нуждается в доступе к контейнеру, я использовал стандартный шаблон GoF singleton для контейнера весны. Таким образом, у вас есть только один синглтон в вашем приложении, остальные-все одноэлементные бобы в контейнере.
вы можете реализовать ApplicationContextAware
или просто использовать @Autowired
:
public class SpringBean {
@Autowired
private ApplicationContext appContext;
}
SpringBean
будет ApplicationContext
injected, внутри которого этот боб создается экземпляр. Например, если у вас есть веб-приложение с довольно стандартной иерархии контекстов:
main application context <- (child) MVC context
и SpringBean
объявляется в основном контексте, он будет иметь основной контекст, введенный;
в противном случае, если он объявлен в контексте MVC, он будет иметь контекст MVC.
вот хороший способ (не мой, оригинал тут ссылка: http://sujitpal.blogspot.com/2007/03/accessing-spring-beans-from-legacy-code.html
Я использовал этот подход и он работает нормально. В основном это простой компонент, который содержит (статическую) ссылку на контекст приложения. Ссылаясь на него в конфигурации spring, он инициализируется.
взгляните на оригинальный ref, это очень ясно.
Я верю, что вы могли бы использовать SingletonBeanFactoryLocator. В beanRefFactory.xml-файл будет содержать фактический applicationContext, он будет выглядеть примерно так:
<bean id="mainContext" class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg>
<list>
<value>../applicationContext.xml</value>
</list>
</constructor-arg>
</bean>
и код, чтобы получить Боб из applicationcontext, откуда бы ни было что-то вроде этого:
BeanFactoryLocator bfl = SingletonBeanFactoryLocator.getInstance();
BeanFactoryReference bf = bfl.useBeanFactory("mainContext");
SomeService someService = (SomeService) bf.getFactory().getBean("someService");
весной команда препятствовать использованию этого класса и yadayada, но он подходит мне хорошо, где я использовал его.
прежде чем реализовать какие-либо другие предложения, задайте себе эти вопросы...
- почему я пытаюсь получить ApplicationContext?
- эффективно ли я использую ApplicationContext в качестве локатора служб?
- могу ли я вообще избежать доступа к ApplicationContext?
ответы на эти вопросы проще в некоторых типах приложений (веб-приложений, например), чем в других, но стоит спросить в любом случае.
доступ к ApplicationContext делает вид нарушения всего принципа инъекции зависимостей, но иногда у вас нет большого выбора.
Если вы используете веб-приложение, есть еще один способ доступа к контексту приложения без использования синглетов с помощью servletfilter и ThreadLocal. В фильтре вы можете получить доступ к контексту приложения с помощью WebApplicationContextUtils и сохранить контекст приложения или необходимые компоненты в TheadLocal.
внимание: если вы забыли снять ThreadLocal вы получите неприятные проблемы при попытке undeploy приложения! Таким образом, вы должны установить его и немедленно начните попытку, которая отменяет ThreadLocal в finally-part.
конечно, это все еще использует одноэлемент: ThreadLocal. Но настоящие бобы больше не нужны. Может быть даже область запросов, и это решение также работает, если у вас есть несколько войн в приложении с библиотеками в ухе. Тем не менее, вы можете считать это использование ThreadLocal таким же плохим, как использование простых синглетов. ;-)
возможно, Spring уже предоставляет аналогичное решение? Я сделал не нашел, но точно не знаю.
посмотри ContextSingletonBeanFactoryLocator. Он предоставляет статические аксессоры для получения контекстов Spring, предполагая, что они были зарегистрированы определенным образом.
Это не очень красиво и сложнее, чем, возможно, Вам хотелось бы, но это работает.
SpringApplicationContext.java
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
/**
* Wrapper to always return a reference to the Spring Application
Context from
* within non-Spring enabled beans. Unlike Spring MVC's
WebApplicationContextUtils
* we do not need a reference to the Servlet context for this. All we need is
* for this bean to be initialized during application startup.
*/
public class SpringApplicationContext implements
ApplicationContextAware {
private static ApplicationContext CONTEXT;
/**
* This method is called from within the ApplicationContext once it is
* done starting up, it will stick a reference to itself into this bean.
* @param context a reference to the ApplicationContext.
*/
public void setApplicationContext(ApplicationContext context) throws BeansException {
CONTEXT = context;
}
/**
* This is about the same as context.getBean("beanName"), except it has its
* own static handle to the Spring context, so calling this method statically
* will give access to the beans by name in the Spring application context.
* As in the context.getBean("beanName") call, the caller must cast to the
* appropriate target class. If the bean does not exist, then a Runtime error
* will be thrown.
* @param beanName the name of the bean to get.
* @return an Object reference to the named bean.
*/
public static Object getBean(String beanName) {
return CONTEXT.getBean(beanName);
}
}
источник: http://sujitpal.blogspot.de/2007/03/accessing-spring-beans-from-legacy-code.html
обратите внимание, что при сохранении любого состояния из текущего ApplicationContext
или ApplicationContext
сам в статической переменной - например, используя шаблон singleton - вы сделаете свои тесты нестабильными и непредсказуемыми, если вы используете Spring-test. Это связано с тем, что Spring-test кэширует и повторно использует контексты приложений в одной JVM. Например:
- Проверьте запуск, и он аннотируется с
@ContextConfiguration({"classpath:foo.xml"})
. - тест B выполнить, и он аннотируется с
@ContextConfiguration({"classpath:foo.xml", "classpath:bar.xml})
есть, и какие бобы реализации
ApplicationContextAware
или autowiring ApplicationContext
может записать в статическую переменную.
при запуске теста B происходит то же самое, и статическая переменная теперь указывает на тест B ApplicationContext
когда тест C выполняется,бобы не создаются как TestContext
(и здесь ApplicationContext
) из испытаний a resused. Теперь у вас есть статическая переменная указывая на другую ApplicationContext
чем в настоящее время фасоль для теста.
обратите внимание, что; приведенный ниже код создаст новый контекст приложения вместо использования уже загруженного.
private static final ApplicationContext context =
new ClassPathXmlApplicationContext("beans.xml");
также обратите внимание, что beans.xml
должно быть частью src/main/resources
значит на войне это часть WEB_INF/classes
, где как реальное приложение будет загружаться через applicationContext.xml
упомянутые в Web.xml
.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>META-INF/spring/applicationContext.xml</param-value>
</context-param>
это сложно отметить applicationContext.xml
путь в ClassPathXmlApplicationContext
конструктор. ClassPathXmlApplicationContext("META-INF/spring/applicationContext.xml")
не сможет найти файл.
поэтому лучше использовать существующий applicationContext с помощью аннотаций.
@Component
public class OperatorRequestHandlerFactory {
public static ApplicationContext context;
@Autowired
public void setApplicationContext(ApplicationContext applicationContext) {
context = applicationContext;
}
}
Я знаю, что на этот вопрос дан ответ, но я хотел бы поделиться кодом Котлина, который я сделал, чтобы получить контекст Spring.
Я не специалист, поэтому я открыт для критики, комментариев и советов:
https://gist.github.com/edpichler/9e22309a86b97dbd4cb1ffe011aa69dd
package com.company.web.spring
import com.company.jpa.spring.MyBusinessAppConfig
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.context.ApplicationContext
import org.springframework.context.annotation.AnnotationConfigApplicationContext
import org.springframework.context.annotation.ComponentScan
import org.springframework.context.annotation.Configuration
import org.springframework.context.annotation.Import
import org.springframework.stereotype.Component
import org.springframework.web.context.ContextLoader
import org.springframework.web.context.WebApplicationContext
import org.springframework.web.context.support.WebApplicationContextUtils
import javax.servlet.http.HttpServlet
@Configuration
@Import(value = [MyBusinessAppConfig::class])
@ComponentScan(basePackageClasses = [SpringUtils::class])
open class WebAppConfig {
}
/**
*
* Singleton object to create (only if necessary), return and reuse a Spring Application Context.
*
* When you instantiates a class by yourself, spring context does not autowire its properties, but you can wire by yourself.
* This class helps to find a context or create a new one, so you can wire properties inside objects that are not
* created by Spring (e.g.: Servlets, usually created by the web server).
*
* Sometimes a SpringContext is created inside jUnit tests, or in the application server, or just manually. Independent
* where it was created, I recommend you to configure your spring configuration to scan this SpringUtils package, so the 'springAppContext'
* property will be used and autowired at the SpringUtils object the start of your spring context, and you will have just one instance of spring context public available.
*
*Ps: Even if your spring configuration doesn't include the SpringUtils @Component, it will works tto, but it will create a second Spring Context o your application.
*/
@Component
object SpringUtils {
var springAppContext: ApplicationContext? = null
@Autowired
set(value) {
field = value
}
/**
* Tries to find and reuse the Application Spring Context. If none found, creates one and save for reuse.
* @return returns a Spring Context.
*/
fun ctx(): ApplicationContext {
if (springAppContext!= null) {
println("achou")
return springAppContext as ApplicationContext;
}
//springcontext not autowired. Trying to find on the thread...
val webContext = ContextLoader.getCurrentWebApplicationContext()
if (webContext != null) {
springAppContext = webContext;
println("achou no servidor")
return springAppContext as WebApplicationContext;
}
println("nao achou, vai criar")
//None spring context found. Start creating a new one...
val applicationContext = AnnotationConfigApplicationContext ( WebAppConfig::class.java )
//saving the context for reusing next time
springAppContext = applicationContext
return applicationContext
}
/**
* @return a Spring context of the WebApplication.
* @param createNewWhenNotFound when true, creates a new Spring Context to return, when no one found in the ServletContext.
* @param httpServlet the @WebServlet.
*/
fun ctx(httpServlet: HttpServlet, createNewWhenNotFound: Boolean): ApplicationContext {
try {
val webContext = WebApplicationContextUtils.findWebApplicationContext(httpServlet.servletContext)
if (webContext != null) {
return webContext
}
if (createNewWhenNotFound) {
//creates a new one
return ctx()
} else {
throw NullPointerException("Cannot found a Spring Application Context.");
}
}catch (er: IllegalStateException){
if (createNewWhenNotFound) {
//creates a new one
return ctx()
}
throw er;
}
}
}
теперь контекст spring является общедоступным, имея возможность вызывать один и тот же метод независимо от контекста (тесты junit, бобы, вручную созданные классы) как на этом Java сервлете:
@WebServlet(name = "MyWebHook", value = "/WebHook")
public class MyWebServlet extends HttpServlet {
private MyBean byBean
= SpringUtils.INSTANCE.ctx(this, true).getBean(MyBean.class);
public MyWebServlet() {
}
}