Lately I am confused about 1 thing.
I defined PlaceHolderConfigurer in applicationContext.xml and config 1 bean in applicationContext.xml too, for example it's called myService which has a property: name I inject value with #Value($env{name}).
And this bean is also annotated with #Service annotation, then I add <Component-scan.....> in dispatch-servlet.xml.
I thought the property: name doesn't get value, because Xml bean is overridden by component scan bean andPlaceHolderConfigurer can't be shared between application context and dispatch servlet context, but actually it have value which I configured in property file.
So is there anyone can explain a little bit for me?
Anything will be appreciated. Thanks
You created two versions of one bean - one defined in applicationContext and one in dispatcherServlet. That usually wrong.
As you suggest PlaceHolderConfigurer not shared beetween parent/child context. It works only for context where it defined.
Related
I have a xml bean definition and JavaConfig bean definition in the same project. The JavaConfig need to reference the XML bean. But When i autowire the xml bean definition inside JavaConfig I get NoSuchBean definition error. My question is: Isnt the xml beans and JavaConfig beans visible to each other? If not how do i inject the xml bean into JavaConfig? Thanks
Edit:
Changing #Autowire to #Resource fixed it, but i dont understand why. Autowire should go after type and the XML bean is of the type Autowire is annoted with.
If your bean is not being picked up by Autowire, you need to ensure the configuration file for the beans is being read and in turn is generating the beans.
One easy way to check is if you are using an IDE with Bean detection capability to see if the IDE is picking up the bean.
If this is working then please paste in your code of the xml with bean in it and xml containg your scan ability.
If I have a bean defined in an xml file like so :
<bean id="myBean" class="com.myClass">
</bean>
Should "myBean" be autowired, ie should the class "com.myClass" be initialized by Spring ?
I have no Spring annotations in "com.myClass" but the class still seems to be initialized because it is declared in an xml file.
Yes, it is normal that your class to be initialised even though auto-wiring is not stated. The reason for this is:
Declared Spring beans have a life-cycle and the first step in this life-cycle is for Spring to initialise the bean.
The basic life-cycle is as follows:
Initialise Bean
Insert values
Calling certain methods depending on which interfaces you implement. This is useful for further custom initialisation and configuration.
Now your bean is ready for use by your application and will stay in the application context until your application context is destroyed.
Finally, if you implement the DisposableBean interface, the destroy method is called for any de-initialisation process that you may require.
This depends on whether you have any other beans that want Spring to inject myBean into them. If no one uses your bean, you can omit it.
I have two FactoryBeans creating proxies for existing beans in the application context.
FactoryBeanA.getObject() is invoked as part of the singleton pre-instantiation, and it attempts to autowire the returned instance.
This autowiring needs a bean that is defined by FactoryBeanB, which has not yet been configured (had properties injected).
Can this be controlled in such a way, that I am sure both FactoryBeans are fully configured (properties injected) before any beans are attempted instantiated?
Edit:
Autowiring from FactoryBeanA objects have worked fine until I changed FactoryBeanB to require a property to be injected. After this change, I see autowiring for the A-bean try to invoke FactoryBeanB.getObject(), but this fails as properties has not yet been injected.
Problem was actually caused by my own mistake. FactoryBeanB was not configured properly as I thought.
I want to develop a module control system so that every spring bean can be managed by my own LifeCycle Controller.
But I can not figure out how can I remove a singleton spring bean out of ApplicationContext.
That may be an interesting problem , can you help me to resolve ?
Removing definition does both : removing definition and destroying (removing all container references on that bean) corresponding Singleton :
((BeanDefinitionRegistry) beanFactory).removeBeanDefinition("myBean");
If you just need to remove the singleton then :
((DefaultListableBeanFactory) beanFactory).destroySingleton("myBean");
The latter way may be especially useful if you just registered singleton but haven't defined any bean definitions, i.e.
((SingletonBeanRegistry) beanFactory).registerSingleton("myBean", myBeanInstance);
You can try removing the bean definition. Get the BeanDefinitionRegistry and call removeDefinition(..)
It depends on the way you create your application, but for example in web application you can get the definition registry by:
BeanDefinitionRegistry factory =
(BeanDefinitionRegistry) applicationCtx.getAutowireCapableBeanFactory();
(the bean factory implements BeanDefinitionRegistry).
I don't know if the bean instance will be removed as well. Give it a try.
As far as I understand When Using Dependency Injection all bean are initializing on Start.
<bean id="userPreferences" class="com.foo.UserPreferences">
</bean>
<!-- a singleton-scoped bean injected to the above bean -->
<bean id="userService" class="com.foo.SimpleUserService">
<!-- a reference to the userPreferences bean -->
<property name="userPreferences" ref="userPreferences"/>
</bean>
and the configuration above means that userService and userPreferences created when application starts. Is it correct?
When using Autowiring and using <context:component-scan>
public class SimpleUserService{
#Autowired
UserPreferences userPreferences;
//omitted
}
1) Is userPreference created on Application init?
2) What is the default scope for bean injected by autowire and how can we change it?
3) How affects bean creation and bean injection?
Hope I made myself clear.
First of all you should add #Service or #Component to the SimpleUserService class.
1 Yes, the ONE instance of UserPreferences is created at application intialization
2 Default scope is singleton, You can change it with the #Scope annotation (#See Spring Reference: 3.11.4.4 Specifying bean scope)
3 Component scan and XML configuration work in the same way (life cycle)
Maybe you should spend some time in understanding the Spring life cycle. You need to understand that Spring works a bit in this way (not 100% correct):
first it creates a pool of beans
then it injects the properties into the beans
But it does NOT work this way: taking a class, look what references it needs creating this references (recursive) and then creating the class.
If you understand this, then you will also understand, that the #Scope of a bean is defined at the bean declaration/class, but not at the references.
1) Is userPreference created on
Application init?
In either case userPreferences is initialized when Spring Context is loaded. You can change this behavior by adding lazy-init="true" to the bean configuration.
2) What is the default scope for bean
injected by autowire and how can we
change it?
The scope of what is injected is all beans loaded into Spring. If you import an XML configuration from another project, it too would be included. I'm not sure if you can limit your scope.
3) How affects bean creation and bean
injection?
Whether is autowired, or configured via XML, the behavior should be the same. I prefer explicitly defining dependencies over automatic annotations. Then again I also like strongly typed languages.
the configuration above means that userService and userPreferences created when application starts. Is it correct?
Yes
Is userPreference created on Application init?
Yes
What is the default scope for bean injected by autowire and how can we change it?
The default scope is always "singleton". This can be changed either using #Scope with #Bean or the scope XML attribute on <bean>.
How affects bean creation and bean injection?
This isn't a clear question. If you change the bean scope, you change when it gets created (start of application, on each request, on each session, etc). The wiring configuration remains the same, only the lifecycle changes.
The #autowired notation is an obsolete way to say #inject. THe latter is a feature of JavaEE 6.
stackoverflow.com/questions/7142622/what-is-the-difference-between-inject-and-autowired-in-spring-framework-which