If I create bean with same name in Root Application context and Child Application context
(as in Root Application Context and dispatcher servlet context)
will child application context override the bean definition ?
What will be the behavior please explain ?
Also explain what will be the behavior In Java Config if I include other Configuration Class and both contain bean with same name.
Will two beans be created ? Or one will override the other.
As per my Experimentation
In the parent and child Application Context new Bean is created for each Application Context irrespective whether Bean name is same or not.
Any call made from ( autowired by ) parent application context refers to Bean in Parent Application Context.
Any call made from ( autowired by ) child application context refers to Bean in Child Application Context.
And In Java Config importing other configuration which contains bean with same name does not create a new Bean and Bean Definition is Overridden.
This effect is same as Importing bean of same name from XML.
Related
Tried to create two separate ElasticsearchRestTemplate using qualifier bean and gave different elasticsearchTemplateRef to ElasticsearchRepository , but its not working.
Getting error:
The bean 'elasticsearchTemplate', defined in class path resource [com/paytm/digital/search/ingestion/elastic/ElasticConfigK8.class], could not be registered. A bean with that name has already been defined in class path resource [com/paytm/digital/search/ingestion/elastic/ElasticConfig.class] and overriding is disabled.\n\nAction:\n\nConsider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-
Cannot register bean definition
I was reading spring doc the core container I want to understand the purpose of ref parent when inject collaborators then I found this notion of parent context child context or parent container and current container this is the part that I'm confuse about it :
This part of doc
Specifying the target bean through the parent attribute creates a
reference to a bean that is in a parent container of the current
container. The value of the parent attribute may be the same as either
the id attribute of the target bean, or one of the values in the name
attribute of the target bean, and the target bean must be in a parent
container of the current one. You use this bean reference variant
mainly when you have a hierarchy of containers and you want to wrap an
existing bean in a parent container with a proxy that will have the
same name as the parent bean.
<!-- in the parent context -->
<bean id="accountService" class="com.foo.SimpleAccountService">
<!-- insert dependencies as required as here -->
</bean>
<!-- in the child (descendant) context -->
<bean id="accountService" <!-- bean name is the same as the parent bean -->
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target">
<ref parent="accountService"/> <!-- notice how we refer to the parent bean -->
</property>
<!-- insert other configuration and dependencies as required here -->
</bean>
can someone give me some help or an example of this two type of context ? and what is the purpose of the ref parent Thank you in advance
The beans of the Spring run inside an application context.
The Application Context is Spring's advanced container. Similar to
BeanFactory, it can load bean definitions, wire beans together, and
dispense beans upon request. Additionally, it adds more
enterprise-specific functionality such as the ability to resolve
textual messages from a properties file and the ability to publish
application events to interested event listeners. This container is
defined by org.springframework.context.ApplicationContext interface.
https://www.tutorialspoint.com/spring/spring_applicationcontext_container.htm
For each application context you can have many configuration files, configuration classes or a mix of both.
You can create an application context with a code like this:
ApplicationContext context = new FileSystemXmlApplicationContext("Beans.xml");
And obtain the beans with context.getBean or with #autowired.
There are some cases when you want(or need) to have a context hierarchy. In these cases Spring provides a way of specifying a parent context. If you look at this constructor, you will see that it receives a context parent.
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/support/FileSystemXmlApplicationContext.html#FileSystemXmlApplicationContext-org.springframework.context.ApplicationContext-
As you can see the parent context is the same type of a child context, they both are http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/ApplicationContext.html.
The difference is that they are related through a parent/child relationship. Not a compose(import) relationship.
The most common case where you see this is in a Spring MVC application, this applications have 2 context, the first is the dispatcher servlet context and the other one is the root context.
Here you can see the relationship
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-servlet
And here you can see an example of application context hierarchy in spring boot applications.
https://dzone.com/articles/spring-boot-and-application-context-hierarchy
I am defining default-lazy-init="true" in the spring context file inside beans tag but when I start tomcat, I see my beans are getting instantiated. here is what it shows in log -
org.springframework.beans.factory.support.DefaultListableBeanFactory (DefaultListableBeanFactory.java:555) - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory#ac6fb1: defining beans [dataSource,my other beans in app.......
Am I missing something ?
Even if a bean is declared to be lazy initialized, it will still be initialized if another bean depends on it.
I'm going to assume from your log, that the bean in question is dataSource. I will also assume you have other beans that depend on dataSource (otherwise it wouldn't be very useful). If the context initializes the other beans and finds that, for example, it needs to autowire the dataSource bean, it will have to first initialize it.
If you want full lazy initialization, you will have to make every bean in some object graph be lazily initialized.
I came across below statement from Spring MVC documentation:
Upon initialization of a DispatcherServlet, Spring MVC looks for a
file named [servlet-name]-servlet.xml in the WEB-INF directory of
your web application and creates the beans defined there, overriding
the definitions of any beans defined with the same name in the global
scope.
Please help me in understanding this statement.
As global scope is used for portlet based applications, then why a developer wants to configure like this in normal Spring MVC applications?
I don't think the term "global scope" here means the global scope bean like singleton, prototype, request, session and global. I believe the global scope here means the scope of the bean context.
In Spring MVC, there are 2 scopes of bean can be defined. The first one is at servlet context level which I believe is what it meant by "global scope" in the above statement. The second one is at servlet level where the bean defined at this level will take priority when resolved by other bean in servlet level.
The beans in servlet level will be able to resolve beans in servlet context (global) level but not the other way round.
Spring MVC provides options to configure multiple Context based on number of DispacthServlet Configuration .
For example
Consider you have two modules with in your application and url pattern starts as module1/* and module2/* . And you want to keep two different context ( always declarations in *context.xml is private to the context ). So you would be creating two dispatchServlet and provide two different servletname and url pattern. Now you have two Spring context which has specific declartions and which is not visible to other. But still you may wanted to declare some application wide beans such as persistentManager / Logger instance and so. for those case you can keep seperate config as root-context.xml and keep the generic declartions in that root. Which is considered here as "GLOBAL SESSION" Now this Global Session beans scope can be different scope based on configuration. And the bean configured in Global Session ( root-context) can be overriden by specific-servlet for customization.
I like the answer provided here also Understanding contexts in Spring MVC
A typical Spring MVC application will have two contexts: the root context and the servlet context.
The root context is loaded by the ContextLoaderListener. The ContextLoaderListener loads the ApplicationContext and sets it as an attribute in the ServletContext. This makes it available to other Servlet, Filter, and XxxListener instances.
The servlet context is another ApplicationContext loaded by the DispatcherServlet when its init() method is called. Since the init() method of a Servlet is called after the contextInitialized() method of a ServletContextListener is called, the DispatcherServlet has access to the root context set as an attribute in the ContextLoaderListener and can therefore use the beans declared there.
[...] creates the beans defined there, overriding the definitions of any
beans defined with the same name in the global scope.
A bean definition is, for example,
<bean id="someBean" class="com.company.SomeBean">
<property name="someProp" value="some value" />
</bean>
Spring creates a BeanDefinition object for this and all other <bean> declarations (or #Bean annotation methods). When the ApplicationContext is refreshed, Spring generates actual instances from these bean definitions.
What the above quote from the documentation is saying is that if you have a <bean> declaration with the same name or id in both the root context and the servlet context, the servlet context one will overwrite the root context one.
I am using another application's service,since everything is already made and done.
My application is to use the interface class inside the application jar.
but something seem to be wrong when this code is called.
BeanFactory factory = new ClassPathXmlApplicationContext( "/Context-Controller.xml");
even if my Context-Controller.xml has this code
<context:component-scan base-package="com.package" />
My error.
Caused by:
org.springframework.beans.factory.NoSuchBeanDefinitionException:
No unique bean of type
[com.package.ServiceIamUsing] is
defined: Unsatisfied dependency of
type [interface
com.package.ServiceIamUsing]: expected
at least 1 matching bean
this is how i autowired it on my applciation.
public class MyAppDao implements IMyAppDao {
#Autowired
#Qualifier("serviceIamUsing")
private ServiceIamUsing serviceIamUsing;
//More codes here
}
jay, try the following:
- eliminate the forward-slash "/"
- in your application context xml file, try to import the application context from your external jar file if it has any --> import resource="classpath*:/META-INF/spring/*.xml"
let me know if it does/doesn't work.
Is there, in fact, an instance of ServiceIamUsing in the jar that is also Spring-annotated (#Component, #Service, etc.)? It's possible this is the case, but I'd like to clarify.
If not, does the jar expose a Spring context file you can import, thus adding the additional beans to your context for autowiring?