I noticed that if you define a bean with same id in two xml files, it would be overiden in the second file.
Say in file a.xml i have
<bean id="abc" />
Say in file b.xml i have
<bean id="abc" />
then the bean "abc" of b.xml is picked up. Is there a way in Spring to stop from overiding i.e should be unique no matter how many xml have the bean abc.
You can disable the feature to disallow beanoverriding by calling the setAllowBeanDefinitionOverriding and pass false. This has to be done early on before anything is loaded. You would either need to create your own custom ContextLoader for this or (if you are on Spring 3.1 or up) you can create an ApplicationContextInitializer and register this in your web.xml.
public class OverrideDisablingApplicationContextInitializer implements ApplicationContextInitializer {
public void void initialize(<? extends ConfigurableApplicationContext> applicationContext);
if (applicationContext instanceof AbstractRefreshableApplicationContext) {
(AbstractRefreshableApplicationContext (applicationContext)).setAllowBeanDefinitionOverriding(false);
}
}
in your web.xml add the following (for the ContextLoaderListener use an init-param for the DispatcherServlet when needed)
<context-param>
<param-name>contextInitializerClasses</param-name>
<param-value>your.package.here.OverrideDisablingApplicationContextInitializer<param-value>
</context-param>
From the top of my head this should disable the overriding behavior. If you use springs WebApplicationInitializer it is even easier as you are probably constructing the ApplicationContext yourself, you can then simply call the method directly and no ApplicationContextInitializer is needed.
Links
ApplicationContextInitializer javadoc
AbstractRefreshableApplicationContext.setAllowBeanDefinitionOverriding javadoc
Also:
final ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext();
ctx.setAllowBeanDefinitionOverriding(false);
ctx.setConfigLocations(shardContextImport);
ctx.setParent(refreshedEvent.getApplicationContext());
ctx.refresh();
Related
I have a question around the usage of new keyword being used when using java configuration in spring. What is the need of using new keyword
Refer below mentioned example:
Code implemented using Java Config
#Configuration
public class HelloWorldConfig {
#Bean
public HelloWorld helloWorld(){
return new HelloWorld();
}
}
The above code will be equivalent to the following XML configuration
<beans>
<bean id = "helloWorld" class = "com.test.HelloWorld" />
</beans>
In XML config, we do not use new keyword whereas in java config we are using new keyword. can someone please explain the difference
In the XML configuration, you explain to the system what class should be instanciated (there is a "new" but it is behind the scene) but in the Java Config you actually have to return an instance so that is why we use the 'new' keyword. 'new' simply creates an instance of your class.
The two examples shown in question are not really equivalent.
What the
<beans>
<bean id="helloWorld"
class="com.test.HelloWorld" />
</beans>
really does, is it tells Spring to instantiate class com.test.HelloWorld, and name the resulting bean "helloWorld".
Then the java-config approach is not really doing this. Instead this follows the factory-method pattern, when we tell Spring, that the return value of the method is the bean, and the method name is the name of that bean.
An equivalent of that in XML would be the mentioned factory-method approach, which in this case would look something like this:
<beans>
<bean id="helloWorldConfig"
class="com.test.HelloWorldConfig" />
<bean id="helloWorld"
factory-bean="helloWorldConfig"
factory-method="helloWorld" />
</beans>
Note that there are several approaches to factory-method. In the above, we are assuming, the `helloWorldConfig" is the factory, and we're specifying the method on that bean. Theare are cases with static factory methods too. See here for more examples.
<beans>
<bean id = "helloWorld" class = "com.test.HelloWorld" />
</beans>
This XML configurations tells Spring to "create an instance of com.test.HelloWorld and put it in the bean context with bean id helloWorld".
#Configuration
public class HelloWorldConfig {
#Bean
public HelloWorld helloWorld(){
return new HelloWorld();
}
}
In this Java configuration, we are returning an instance of com.test.HelloWorld. Because of the #Bean annotation, this instance is put into the bean context. As no specific bean id is given, the bean id is derived from the method hellowWorld() and thus becomes helloWorld.
As you can see, both configurations require an instance of com.test.HelloWorld. The XML configuration implicitly creates the instance whereas in the Java configuration you have to explicitly do it yourself.
For example, I have 3 beans in my spring configuration: A, B, C. And I want to create bean B and C as usual. And than (when all others beans were created) I want to ask spring to create bean A.
Any suggestion ?
Thanks.
Spring framework triggers a ContextRefreshedEvent once the contexts has been fully refreshed and all the configured beans have been created.
You could try to create a listener to catch that event and initialise bean A.
#Component
public class ContextRefreshedEventListener implements
ApplicationListener<ContextRefreshedEvent> {
#Override
public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
// Init your bean here
}
}
You should try #DependsOn adnotation
For example
<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
<property name="manager" ref="manager" />
</bean>
<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />
I know it's not really a bean ordering answer, but maybe you can achieve your goal with a #PostConstruct method that will be called just after a bean is constructed, dependencies are injected and all properties are set.
best nas
Easier way to do this would be using #Lazy annotation to your bean. This makes your bean do not get initialized eagerly during context initialization. In simple words,your bean will get created when you ask for it, not before.
#Bean
#Lazy
public A beanA() {
//some code here
}
I'm trying to understand the concepts of application context in Spring MVC. To examine it I have created an application with two application contexts Test-application-context1.xml and Test-application-context2.xml and one web application context Test-dispatcher-servlet.xml. In all of these contexts I initialized a simple java bean with two fields:
1) In Test-application-context1.xml:
<bean id="testObject" class="test.TestObject">
<property name="fName" value="FirstName Context1"/>
<property name="lName" value="LastName Context1"/>
</bean>
2) In Test-application-context2.xml:
<bean id="testObject" class="test.TestObject">
<property name="fName" value="FirstName Context2"/>
<property name="lName" value="LastName Context2"/>
</bean>
3) In Test-dispatcher-servlet.xml::
<bean id="testObject" class="test.TestObject">
<property name="fName" value="FirstName WebContext"/>
<property name="lName" value="LastName WebContext"/>
</bean>
I also provided a proper configuration in the web.xml file to initialize all of these contexts when the server starts:
<servlet>
<servlet-name>dispatcherTest</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/Test-dispatcher-servlet.xml</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>dispatcherTest</servlet-name>
<url-pattern>/Test/*</url-pattern>
</servlet-mapping>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/Test-application-context1.xml /WEB-INF/Test-application-context2.xml</param-value>
</context-param>
Now I want to inject these application/web application contexts in one of my controller classes. I'm not sure how to do this for multiple contexts properly. I know when I have one context I can make my class implement ApplicationContextAware so I tried it like this:
#Controller
public class TestController implements ApplicationContextAware{
private ApplicationContext applicationContext;
#Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
#RequestMapping(value = "/Test")
public void Test(HttpServletRequest request) {
TestObject testObject = applicationContext.getBean("testObject", TestObject.class);
System.out.println("fName="+testObject.getfName()+"; lName="+testObject.getlName());
}
}
In the above example I always get values of testObject from Test-dispatcher-servlet.xml so it seems that applicationContext that is being injected here represents web application context, BUT if I let's say rename testObject to testObject1 in 'Test-dispatcher-servlet.xml' and run the same code I will get values from Test-application-context2.xml so here are the questions I have.
1) When we make class implement ApplicationContextAware having multiple contexts which context will be injected to that class? Is it one context that is being injected or does spring somehow combines all of contexts and inject them as one applicationContext object (that would explain why do I get values from a different context when I change the name of the bean in one of the contexts)?
2) What is the proper way to inject multiple application contexts to the class?
I know the above example is not a typical scenario and probably a bad design pattern but I'm just trying to understand how the whole thing works.
To answer your 2nd question,
Use #ImportResource as below.
From the docs,
Like #Import, this annotation provides functionality similar to the
element in Spring XML. It is typically used when designing
#Configuration classes
#Configuration
#ImportResource( { "Test-application-context1.xml", "Test-application-context2.xml" } )
public class ConfigClass { }
This will load all beans from both application contexts into the class ConfigClass.
Update:
So, there will be only one application context exists after this import.
You can access any bean from any imported *.context.xml by using #Autowired
After import, Your example in question will throw NoUniqueBeanDefinitionException, because you have more than 1 bean with the same name (testObject) in same application Context.
Below is a snippet from the camle-osgi example. I can obtain the camel context but how do I get the original spring application context? Or how am I supposed to get a reference to "mybean"?
MyRouteBuilder.java:
public class MyRouteBuilder extends RouteBuilder {
public static void main(String[] args) throws Exception{
new Main().run(args);
}
public void configure() {
// set up the transform bean
ModelCamelContext mc = getContext();//ok, I can get the camel context fine
//but how to get the spring context to get to "mybean"???
//set up routes
}
}
beans.xml:
<beans>
<camel:camelContext xmlns="http://camel.apache.org/schema/spring">
<package>org.apache.servicemix.examples.camel</package>
-----
</route>
</camel:camelContext>
<bean id="mybean" class="myclass"/>
</beans>
You should not use the spring context directly. Instead use the spring features to inject the beans you need.
Define the routebuilder as a bean in the spring context and use a setter and to inject myBean.
Keep the auto discovery and use annotations like #Autowired in the routebuilder to inject mybean.
A third option is to use getContext().getRegistry(). The registry allows to access all beans of the spring context by name or by type.
It would not be camel if we are already out of options :-)
So another options is to use the bean component of camel to access beans from the spring context: http://camel.apache.org/bean.html
I'm trying to figure out how to get the values of a properties file into my Spring Environment properties.
The pre Spring 3.1 way of doing this would be something like:
<context:property-placeholder location="classpath:my.properties" />
<bean id="myBean" class="com.whatever.MyBean">
<property name="someValue" value="${myProps.value}" />
<!-- etc -->
</bean>
I could have also done this:
public class MyBean {
#Value(value = "#{myProps.value}")
private String someValue;
}
Now that I can ostensibly pull properties from the Environment class, this seems like a much cleaner way of getting properties than using the clunky #{myProps.value} syntax in either my xml or my bean itself.
I tried this in my XML:
<bean
class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
<property name="location">
<value>classpath:my.properties</value>
</property>
</bean>
But the properties are not added to Environment.
I understand that I can use the PropertySource attribute, but I'm not doing my configuration with annotations.
So how can I set up my bean / xml so that variables setup in my props are available in Environment? Moreover, how can I inject those values into my bean without having to explicitly say "environmentInstance.getProperty("myProps.value")?
For the web applications
If you want to have Environment populated before the XML bean definitions are processed, you should implement a ApplicationContextInitializer(), as described in the Spring Source blog
<context-param>
<param-name>contextInitializerClasses</param-name>
<param-value>com.bank.MyInitializer</param-value>
</context-param>
Here is a slightly modified version of the example from the blog
public class MyInitializer implements
ApplicationContextInitializer<ConfigurableWebApplicationContext> {
public void initialize(ConfigurableWebApplicationContext ctx) {
ResourcePropertySource ps;
try {
ps = new ResourcePropertySource(new ClassPathResource(
"my.properties"));
} catch (IOException e) {
throw new AssertionError("Resources for my.properties not found.");
}
ctx.getEnvironment().getPropertySources().addFirst(ps);
}
}
For the standalone applications
Basically the same thing, you can modify the environment of the AbstractApplicationContext directly
ResourcePropertySource ps;
try {
ps = new ResourcePropertySource(new ClassPathResource(
"my.properties"));
}catch (IOException e) {
throw new AssertionError("Resources for my.properties not found.");
}
//assuming that ctx is an AbstractApplicationContext
ctx.getEnvironment().getPropertySources().addFirst(ps);
P.S. the earlier version of this answer showed an attempt to modify the Environment from the bean but it seems to be an antipattern spreading on SO, because for sure you would like to have Environment property sources list populated even before the XmlBeanDefinitionReader starts to process XML to make placeholders work inside the <import/> statement.
My understanding is also a little addled but this is what I could make out:
Environment is a way to indicate the currently active profiles (and profiles are a way to selectively create beans)
PropertySources can be associated to an environment and the way to do that is using #PropertySource annotation, there does not seem to be an xml equivalent to do this.
Your understanding actually should be the other way round, AFAIK: when you declare <context:property-placeholder the placeholder will resolve properties against the locally declared properties and can fallback on the property sources declared in the environment, environment itself does not get modified with the new properties. Again,the only way to add properties to the environment itself seems to be through the #PropertySource annotation