My applicationContext initialization was working fine with Spring 3.2.1.
But when I upgraded to 4.0.9 without changing any code or bean definitions), the initialization got stuck. The following statement kept on happening. There's no obvious circular reference though.
Requested bean is currently in creation: Is there an unresolvable circular reference?
I continued to investigate. I deliberately removed a bean definition.
Spring 3.2.1 had the expected outcome: threw a fatal error almost immediately.
Spring 4.0.9 was still getting into this infinite loop, trying to find a different seed bean definition to make things work.
Here's the log statement that kept on happening.
[factory.support.DefaultListableBeanFactory.getTypeForFactoryBean()] - Ignoring bean creation exception on FactoryBean type check:
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'someSeedBean-which-is-different-in-every-instance-of-this-log' defined in the class path resource ........ ;
nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'someDataSource' is defined
What's changed? Any ideas would be helpful.
Bean definitions that work in both Spring 3.x and 4.x
<bean id="abstractDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close" abstract="true" scope="singleton">
<property ....>
</bean>
<bean id="someDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close" scope="singleton" parent="abstractDataSource">
<property name="driverClass" .... />
</bean>
<bean id="someSessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource"> <ref bean="someDataSource" /> </property>
<property name="packagesToScan"> <list>......</list> </property>
....
Bean definitions that work in Spring 3.x but not in 4.0.9.
#Configuration
public class SomeSpringConfiguration{
// Moving this beanDef to Java for features not available in XML
#Bean(destroyMethod = "close")
public DataSource someDataSource() { // also tried setting this to ComboPooledDataSource
// verified that this beanDefinition is recognized by Spring
// but this bean is never created / this method is never executed
...
return datasource;
}
}
<bean class="SomeSpringConfiguration" />
<bean id="someSessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource"> <ref bean="someDataSource" /> </property>
<property name="packagesToScan"> <list>......</list> </property>
....
</bean>
Error I get with Spring 4.0.9 is
Cannot resolve reference to bean 'someSessionFactory' while setting constructor argument;
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'someSessionFactory':
Requested bean is currently in creation: Is there an unresolvable circular reference?
Please note that the application has thousands of beans defined in/via xml, #Component, and #Configuration. I had to move above bean from xml to a #Configuration class to execute a complicated bean build procedure.
-----------------------UPDATE
I found the issue: 'tons of MethodInvokingFactoryBean[MIB] usages'. For some reason, Spring 4 was getting confused in presence of tons of MIBs. The exact same code base worked fine with Spring 3. I migrated all the logic performed by various MIBs to an ApplicationListener. Please note that ApplicationListener is not an intended replacement for MIBs but in my case I could reproduce the logic in a listener because the MIBs were just performing static injection of Spring beans into classes not managed by Spring. It not only fixed this issue but decreased Spring startup time to ~200 seconds from ~300 seconds.
Unfortunately, I neither could figure out the root cause in Spring nor could reproduce the issue in a smaller code-base (to share here).
Remove
<bean class="SomeSpringConfiguration" />
from XML, it's already annotated with #Configuration. If it's being scanned it's likely the beans in it are getting created twice. You should move everything into Javaconfig.
Circular references are common during development, when you have a lot of beans and are not careful when you autowire them together. The stacktrace should contain the complete list of beans, telling you where the circular reference starts and ends.
I have never seen random circular references (and I encountered circular references many times over the last 7 years)! As far as I know, the code that builds the dependency tree and instantiates/wire the beans is deterministic. So you should always get the same circular reference every time you run. If you don't, I can only thing of two reasons
There is a bug in the Spring version you are using (I'm 99% sure there is a unit test for this)
You have one of more beans that starts a thread as part of bean instantiation, and the thread uses the applicationContext to load another bean lazily (while the context is still loading).
When I teach Spring classes, I recommend that constructors should only contain field assignments, if you need to start threads (or anything else with a lifecycle) you should use the lifecycle methods. Personally I prefer to implement SmartLifeCycle (over InitializingBean/DisposableBean, #PostConstruct/#PreDestroy), since this ensures that nothing will started until after all beans have been instantiated and wired together.
The core of it is as Strelok says, you are mixing annotations and xml config.
The point of the #Configuration annotation is to avoid xml. When you added the component scan for the package after removing SomeSpringConfiguration from xml.
You would start to create multiples of someDataSource, because it is defined in multiple places (#Bean annotation, and in xml).
Please avoid mixing annotations and xml, only use one of them and stick to that, and this problem will, if not resolved but at least much easier to spot.
If you can create an example project and upload it somewhere I can take a closer look if you are still having this issue.
Related
We have upgraded Spring WebFlow from 1 to 2.4.1. Now we need to rewrite all of our Unit tests. One issue is stopping us dead in our tracks. Most of our flows still import action beans and forms, as we are still using XML configurations. In addition, all of the action beans inherit configuration via an abstract bean reference in the webflow configuration file. So we have the following bean reference in our webflowContext.xml:
<bean id="serviceInjected" abstract="true">
<property name="serviceLocator" ref="serviceLocator"/>
<property name="misAssembler" ref="misAssembler"/>
<property name="formObjectScope" value="FLOW"/>
</bean>
All of the Action beans thus inherit the serviceLocator, misAssembler and formObjectScope. When I try to unit test the flows, the tests fails because there is no "serviceInjected" bean reference. So my question is:: How can we insert bean configuration inheritance into the test before we attempt to start the flow. Using configureFlowBuilderContext will not work as this change the ApplicationContext and not the ExternalContext. I have only seen one other reference to this on the internet and that question was not answered, so here is hoping I have better luck.
when I integrate spring and mybatis, I encountered a error output, saying that:
Bean named 'sqlSessionFactory' must be of type [org.mybatis.spring.SqlSessionFactoryBean], but was actually of type [org.apache.ibatis.session.defaults.DefaultSqlSessionFactory]
here is my code snippet:
ApplicationContext context = new ClassPathXmlApplicationContext("spring_mybatis_integration/spring_config.xml");
SqlSessionFactoryBean sqlSessionFactoryBean = context.getBean("sqlSessionFactory", org.mybatis.spring.SqlSessionFactoryBean.class);
here is my bean definition in xml:
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="configLocation" value="spring_mybatis_integration/mybatis_config.xml"></property>
<property name="dataSource" ref="dataSource"></property>
</bean>
as you can see, both in java code and in xml file, I associate the bean sqlSessionFactory with class org.mybatis.spring.SqlSessionFactoryBean, why does the error output tell me another non-relative class name org.apache.ibatis.session.defaults.DefaultSqlSessionFactory?
Thanks a lot!
Version Info:
mybatis 3.1.1
spring 3.2.0
mybatis-spring 1.1.1
There is no point to accessSqlSessionFactoryBean via dependency injection, normally we work with the objects created by the Factory Beans, not the Factory Beans themselves, in this case the Factory Bean returns a DefaultSqlSessionFactory instance.
See Customizing instantiation logic with the FactoryBean Interface
But if you really want to access the FactoryBean instance, you should use ampersand symbol & see Spring: Getting FactoryBean object instead of FactoryBean.getObject()
Yes, the concept of the Factory Beans that return factories may be a bit confusing, but that is how things work in Spring.
So it's likely SqlSessionFactory instead of the SqlSessionFactoryFactoryBean is what you want.
update: actually MyBatis even explained this in the documentation on SqlSessionFactoryBean
Note that SqlSessionFactoryBean implements Spring's FactoryBean
interface (see section 3.8 of the Spring documentation). This means
that the bean Spring ultimately creates is not the
SqlSessionFactoryBean itself, but what the factory returns as a result
of the getObject() call on the factory. In this case, Spring will
build an SqlSessionFactory for you at application startup and store it
with the name sqlSessionFactory
I want to declare two beans and instantiate them using Spring dependency injection?
<bean id="sessionFactory" class="SessionFactoryImpl">
<property name="entityInterceptor" ref="entityInterceptor"/>
</bean>
<bean id="entityInterceptor" class="EntityInterceptorImpl">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
But Spring throws an exception saying "FactoryBean which is currently in creation returned null from getObject"
Why is inter-dependent bean wiring not working here? Should i specify defferred property binding anywhere?
Unfortunately the way container initialization works in Spring, a bean can only be injected in another bean once it is fully initialized. In your case you have a circular dependency that prevents either bean to be initialized because they depend on each other. To get around this you can implement BeanFactoryAware in one of the beans and obtain the reference to the other bean using beanFactory.getBean("beanName").
neesh is right, Spring doesn't do this out of the box.
Interdependent beans hint at a design problem. The "clean" way to do this is to redesign your services in such a way that there are no such odd dependencies, of course provided that you have control over the implementations.
You can implement a BeanPostProcessor that sets the dependency.
Or...
See Costin's reply here:
http://forum.springframework.org/showthread.php?t=19569&highlight=circular+dependencies
See Andreas' reply here:
http://forum.springframework.org/showthread.php?t=29572&highlight=circular+dependencies
you can extend the ApplicactionContext that are using and override the method createBeanFactory()
protected DefaultListableBeanFactory createBeanFactory(){
DefaultListableBeanFactory beanFactory = super.createBeanFactory();
// By default this is false;
beanFactory.setAllowRawInjectionDespiteWrapping( true );
return beanFactory;
}
This works, but be careful because this allows circular references.
I'm writing an integration test where an application context xml is initialized during startup. There are several test methods in the test class which make use of a specific bean 'X'(already defined in the xml). My actual requirement is to mock bean X only for one of the test methods.
Inside a test method: I tried creating a separate application context using ClassPathXMLApplicationContext with only the mock bean 'M'.
Now I have two Application Contexts (AC):
1. One created during test case startup (which contains the actual bean X) and
2. One created using ClassPathXMLApplicationContext within the test method (which has the mock bean M).
I want to replaced the actual bean definition 'X' within AC:1, using the mock bean definition 'M' from AC:2.
Can somebody throw some light on this please?
You can :
use the Profile annotation if you have spring 3.1.
use the Primary annotation
use qualifiers
wire the bean yourself in the spring context
and i'm sure there are even more options.
There is not a clear way to replace a a bean in a refreshed ApplicationContext unless you close it and refresh it again.
To emulate it, the common approach is to use a Proxy of the bean that you want to replace and change the target at runtime.
You can do it easily using the framework aop support classes:
<bean id="realBean" class="RealClass" />
<bean id="mockBean" class="MockClass" />
<bean id="targetSource" class="org.springframework.aop.target.HotSwappableTargetSource">
<constructor-arg ref="realBean" />
</bean>
<bean id="bean" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="targetSource" ref="targetSource" />
</bean>
#Test
public void testWithMockBean() {
Object real = targetSource.swap(mock);
....
// do your test work
...
targetSource.swap(real);
}
Create a testApplicationContext with
<beans>
<import resource="classpath*:appContext.xml" />
<bean id="mockbeanOfX" class=....../>
</beans>
and then load this test application context in your testcase. Now you can get the mock bean from the application context and pass it whereever needed.
In order to programmatically refresh the resource bundle cache, I am using Spring's ReloadableResourceBundleMessageSource. I am having trouble injecting it into my bean where I want to invoke the clearCache() method.
I've had to resort to the following:
private ReloadableResourceBundleMessageSource messageSource;
#Autowired
public void setMessageSource(MessageSource messageSource) {
this.messageSource = (ReloadableResourceBundleMessageSource((DelegatingMessageSource)messageSource).getParentMessageSource();
}
This works, but there must be a better way. The message resource is defined as follows:
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basenames" >
<list>
<value>WEB-INF/content/Content</value>
</list>
</property>
</bean>
I don't understand why Spring is injecting a message source of type DelegatingMessageSource.
I don't think that autowiring by type will work in this case, as the autowire candidate will most likely be the ApplicationContext itself (see section 3.8.2 of the reference documentation). This leads to all those layers you have to dig through to get your original ReloadableResourceBundleMessageSource.
Try passing a reference to the messageSource bean via XML configuration instead. Annotating the property with #Qualifier('messageSource') should work as well.
You usually get the DelegatingMessageSource injected when Spring can't find "messageSource" defined. Are you sure you're defining it properly or that it's visible where necessary? I think the problem here is how the XML configuration has been setup.
I had a similar situation with Spring Web Flow and the form action stuff. In my XML configuration the "messageSource" wasn't visible and causing the DelegatingMessageSource to be injected. I placed the "messageSource" bean definition into the webflow configuration and then everything worked and I stopped getting the DelegationMessageSource object. However, this is an ugly fix since now I have "messageSource" defined in two places.
Anyway, this problem only started after I switched to Spring 2.5.6. I'm using Webflow 1. Once I have a chance I will try and update to Webflow 2 and see what happens. Maybe that will fix the issue.
have you tried to define the method as:
public void setMessageSource(ReloadableResourceBundleMessageSource messageSoure) {
this.messageSoure = messageSoure;
}
When you try to run it through messageSource in your controller, you get NOTHING, empty string. And if you look closely, you will find that you have a DelegatingMessageSource in your messageSource property, with an empty parent source, which means it is EMPTY, i.e. always returns blank and this exception occurs in controller
ReloadableResourceBundleMessageSource incompatible with org.springframework.context.support.DelegatingMessageSource
Read more..