I have two beans which comes from the same class(id1 and id2), the difference is ids and some properties.
In the code, I called getbean(id1) to get the object.
How can I switch to id2 without recompiling the code?
If you have two different beans wit different properties that means you have two different objects. That means you treat them as you would normally treat different objects -
BeanClass b1 = (BeanClass) ctx.getBean("id1");
BeanClass b2 = (BeanClass) ctx.getBean("id2");
However if you have a seperate scenerio where you load bean 1 in your class for normal working and bean 2 in your class when you run it via JUnit then you should have a different approach altogether -
Have two different applicationContext.xml files. First one loads when your code runs and then other(applicationContext-test.xml) is loaded when you are running your code via JUNIT. This way you can load different beans without changing the code.
It doesn't seems good design,
Spring are generally service beans, you should have only one implementation object of Bean.
well then also if you want to do it.
then read the bean ID from Properties file while fetching bean.
From your question, I'm assuming that you want to switch between bean instances programatically....
Given the following setup:
<bean id="instance1" class="my.bean.A">
<property name="property_B">
<ref local="B"/>
</property>
</bean>
<bean id="instance2" class="my.bean.A">
<property name="property_B">
<ref local="B"/>
</property>
</bean>
then in your code, you can switch between the two using the ApplicationContext... (This is Spring 2.x code)
ApplicationContext ctx = new FileSystemXmlApplicationContext(
"my-XML-Config-File-Above.xml");
A instance1 = (A) ctx.getBean("instance1");
A instance2 = (A) ctx.getBean("instance2");
Related
Am really new to spring, so please don't get angry and bear with me for a while.
I'm trying to understand how application.properties or any other external config file values gets associated with the places where config file's keys (value="${log4j.configuration}") are mentioned to consume their values from file itself.
For example below is spring bean xml file:
<bean id = "propertiesToBeTaken"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath*:application.properties</value>
<value>classpath*:*keys.properties</value>
</list>
</property>
</bean>
<bean id="log4jLoader" class="my.loader.Log4jLoader">
<property name="log4jCongif" value="${log4j.configuration}" />
</bean>
As you can see, propertiesToBeTaken is an instance of class org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.
And in second case ,log4jLoader is an instance of class my.loader.Log4jLoader, where log4j.configuration key's value is assigned to Log4jLoader class's instance variable log4jCongif.
My questions are below:
There is no locations variable in class PropertyPlaceholderConfigurer, then what is locations here and from where it came ? How can I relate locations to class's instance propertiesToBeTaken?
If lets say, application.properties key value pairs gets loaded into memory, then who or I mean which method loads that ? And even if it gets loaded then how those key value pairs of application.properties file are accessible to Log4jLoader's instance variables...?
Last but I think it could very stupid question, In class log4jLoader class, there is a setLog4jConfig(String log4jpropertiesLocation), but I really cant see who is calling this method. Just correct me here, Its not true, that In spring what ever the beans of object we have created, calls automatically class's instance methods. RIGHT ? I need to search more in code. CORRECT ?
Please put some light on my doubts here. Read about this alot on spring docs and online as well, but could not understand. Really want to understand how it's happening.
Thanks
Answers to your questions:
locations in bean config XML is referring to the setLocations method of PropertiesLoaderSupport class which Set locations of properties files to be loaded. PropertiesLoaderSupport is parent class of PropertyPlaceholderConfigurer in multi-level inheritance. See Official Document
When PropertyPlaceholderConfigurer gets instantiated by Spring IoC, these properties are set in the bean, now any other bean in the config XML asks for property values using ${key.name}, spring injects the value from the bean having value for this key. In your case Log4jLoader requires ${log4j.configuration} so it's value will be injected by PropertyPlaceholderConfigurer or it's any parent class.
setLog4jConfig spring calls this method when it has to give value to one of the property of the class Log4jLoader. In your case because of <property name="log4jCongif" value="${log4j.configuration}" /> configuration spring will call setter method of the property log4jCongif to inject the value. Yes spring can call instance methods (specially setter) as per the configuration.
From Spring in Action book, there is an example of Spring Bean. It uses Compact Disc analogy. When an application needs a "The Beatles" album, it creates "The Beatles" album bean, and as well as other albums.
If there are n albums in database, so should I create n album beans?
If it is not, how the n albums represented in application? Is it just a POJO domain model (not a bean)?
What is the real use case using Spring Bean?
If I were you, I would depart from the analogy of the compact disc as a Spring bean, especially with respect to your later questions. Quite plainly, any Java object can be declared as a bean in Spring, whether you're using XML configuration or Java configuration.
Let's suppose I have these 2 classes:
public class Foo {
private String s;
private Bar bar;
// getters & setters
}
public class Bar {
private int i;
// getter & setter
}
I can make the former a Spring Bean by declaring it in an XML configuration file:
<bean id="foo" class="demo.Foo">
<property name="s" value="Hello, World!" />
<property name="bar">
<bean class="demo.Bar">
<property name="i" value="10" />
</bean>
</property>
</bean>
Now, with these 2 lines of code:
ApplicationContext ctx = new ClassPathXmlApplicationContext("app.xml");
Foo foo = ctx.getBean(Foo.class);
The foo object that was configured can be retrieved, and all its properties including bar will be set. This is the core use case of Spring, i.e. letting you configure how the building blocks of your application resolve their dependencies at runtime. Initially Spring was all about configuration outside of code, but the focus now has slightly changed, with things like component scans and Java configuration...
Anyway, to conclude with this brief example, the following line of code will print 10:
System.out.println(foo.getBar().getI());
In this example, I took Foo and Bar, but it could as well be a Web Service, a service implementing some business logic, a database, an ORM facade, a template engine, a thread pool, anything... But mostly components dealing with data objects, not data objects themselves, though this is entirely possible.
Now to return with your use case, in a Spring app, I would generally have these components if I'm coding a Web app with a database: a controller (the Web boundary), a service (for business logic), a repository (for querying) and of course a data source. I won't delve into too much details here (no declarative transactions for example). Notice that with this configuration, no specific data provider is compiled into my Java code, it remains in the configuration:
<bean id="cdController" class="demo.compactdisc.CdController">
<property name="cdService" ref="cdService" />
</bean>
<bean id="cdService" class="demo.compactdisc.CdServiceImpl">
<property name="cdRepository" ref="cdRepository" />
</bean>
<bean id="cdRepository" class="demo.compactdisc.CdRepositoryImpl">
<property name="dataSource" ref="dataSource" />
</bean>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/test"/>
<property name="username" value="test"/>
<property name="password" value="s3cr3t"/>
</bean>
With your domain, the repository would return the compact discs from the database to the service, the service to the controller and the controller to the user. Compact discs would not be described as Spring beans but would certainly be parameters and return values from the actual Spring beans.
You just need to have one Album class and annotate it as a #Component or do it via xml.
The terms bean and POJO are interchangeable. As per Spring in action 4rd edition, Spring tries hard to be a non-invasive framework.
(...)the classes in a Spring-based application often have no
indication that they’re being used by Spring. At worst, a class may be annotated with one of Spring’s annotations, but it’s otherwise a POJO
and
Although Spring uses the words bean and JavaBean liberally
when referring to application components, this doesn’t mean a Spring component
must follow the JavaBeans specification to the letter. A Spring component can be
any type of POJO.
The use case is that you can use the Spring Dependency Injection to wire your beans on run-time, your application can benefit from Spring in terms of simplicity, testability, and loose coupling.
In short, a Spring bean as you refer is just a POJO used in the context of an Spring Application. If you use the xml mapping instead of the annotation, your class will be just another regular Java class, a Plain Old Java Object.
If there are n albums in database, so should I create n album beans?
I would think not. If there are n albums it would be very cumbersome to include them all explicitly in your App.config file if that's what you're referring to; but you could. You would probably add an AlbumService (#Service) #Bean and associated #Repository to handle writing and retrieving them from the DB.
If it is not, how the n albums represented in application? Is it just
a POJO domain model (not a bean)?
You could have an Album #Entity bean with the attributes of an album. When you save an album you'd set the attributes as opposed to having individual components implementing a common interface. Your DB would have n albums in it. If you needed to retrieve just one Beatles album you could query based on the album title, for example. If you wanted them all you could do albumService.findAll(); and get a container of them.
What is the real use case using Spring Bean?
Spring is the real use case of a Spring Bean. According to the Spring IoC Container Reference:
In Spring, the objects that form the backbone of your application and
that are managed by the Spring IoC container are called beans. A bean
is an object that is instantiated, assembled, and otherwise managed by
a Spring IoC container. Otherwise, a bean is simply one of many
objects in your application. Beans, and the dependencies among them,
are reflected in the configuration metadata used by a container.
I can't provide a better answer than what's contained in the documentation or given in this answer.
When i run the first petittion of a bean's method (let's say method A) on the server everything seems ok, but when running for the second time any petition on this carrierRESTWS bean (let's say method B), the dao being used is the same carrierDAO instance. How can i avoid having this problem and making the injection use a new instance of the dao each time this carrierRESTWS bean is being called?
Beans configuration inside xml file:
<bean id="carrierRESTWS" class="ar.com.anovo.controllers.rest.CarrierRESTWS">
<property name="carrierDAO" ref="carrierDAO"/>
</bean>
<bean id="carrierDAO" class="ar.com.anovo.dao.CarrierDAO"></bean>
Set the scope of "carrierDAO" to "prototype":
<bean id="carrierDAO" class="ar.com.anovo.dao.CarrierDAO" scope="prototype" />
This will create a new instance, once an injection is required.
More about scopes can be found in the Spring Doc.
Your beans are singleton beans, so they live for as long as the Spring Container lives, which basically means for as long as your program is running, which again means for as long as your webapp is running, which could theoretically be years.
Since your controllers and your DAO classes have of course been coded to be stateless, and support multi-threading, you shouldn't have a problem with a single shared instance.
The default scope in spring is singleton, so you need to explicitly set the scope which makes a new instance each time as #Stefan indicates with prototype.
I am new to Spring and i am stuck with a scenario where i need help.
My Scenario is i have a bean definition for some specific module like this.
<bean name="ruleEngineAction" class="com.xxxxx.yyyy.UserAction" scope="prototype">
<property name="userManager">
<ref bean="userManager" />
</property>
<property name="userDto">
<ref bean="userDto" />
</property>
</bean>
now within this bean i want to use one more property but that depends on the application flow like
<property name="roleManager">
<ref bean="roleManager">
</property>
so should i include this property with in the bean definition itself or i can do it dynamically in code because i don't want this property to be used a lot.
Please suggest me the right and efficient approach.
From what I understood from question, there is only one bean of type roleManager but the usage of roleManager is based on application flow.
In this scenario, I would recommend you to inject roleManager to ruleEngineAction as you would do with any other bean but use the bean only when it is necessary.
It is a bad practice to needless dependency to spring in normal classes like adding reference to applicationContext for fetching the bean dynamically at runtime.
Whether or not, you inject this bean, it'll anyways be created by Spring. Why not just include the property in your UserAction and whether to use it or not, can be decided in your class. No harm in having the bean injected, because you'll anyways use it for some scenarios.
Had the scenario been like, the object won't be created, if you don't inject/use, then it would make sense to consider this situation, but since Spring will create the object anyways, it really shouldn't be a problem to just inject it.
Well you need to add new property with getter and setter in your class com.xxxxx.yyyy.UserAction for roleManager like :
class UserAction {
// your previous properties userManager, userDto, etc.
private RoleManager roleManager; // assuming interface/class as RoleManager for roleManager
// getter and setter for roleManager
// your other action methods which will use roleManager
}
There is no problem if you inject also.Whenever you access that class only it will create the object of that class.
I Am very new to Spring. I have an Interface (MessageHandler ) which has a get method, this method returns a list of Implementations of another interface (messageChecker).
public interface MessageHandler {
public void process(BufferedReader br);
public void setMessageCheckerList(List mcList);
[B]public List getMessageCheckerList();[/B]
}
In my Spring XML configuration , i have something like this ,along with other beans
<bean id="messageHandler" class="com.XXX.messagereceiver.MessageHandlerImpl">
<property name="messageCheckerList" ref="checkerList"/>
</bean>
<bean id="checkerList" class="java.util.ArrayList">
<constructor-arg>
<list>
<ref bean="HL7Checker"/>
</list>
</constructor-arg>
</bean>
<bean id="HL7Checker" class="com.XXX.messagereceiver.HL7CheckerImpl">
<property name="messageExecutor" ref="kahootzExecutor"/>
</bean>
Here i am passing a checkerlist - which is a list of Implementations ( For now i have only 1) of the Interface (messageChecker)
Checkerlist is containing references to Bean Id's which are actual implementaions.
HL7Checker is an implementation of an Interface messageChecker.
But when i run the main program, When i inject the bean "messageHandler" and call the getMessageCheckerList, It returns a null value. These getter and setter methods are working fine without using spring.
I am not sure what seems to be the problem.
I don't know the answer for you troubles, but I would check:
is the setter setMessageCheckerList(List) in messageHandler bean called? (either using some debugger or some trace output like System.out...). If it's not, there's probably something wrong with your Spring XML configuration setup. The bean definition you posted requires the property to be set and Spring wouldn't create the messageHandler bean without setting the property.
who calls the setMessageCheckerList(List) setter? Or even more precise, what code writes to the field which stores the value of the property? Maybe the field is initialized properly by Spring but gets overwritten to null later on?
are you sure you call the getMessageCheckerList on the very same object Spring has configured for you (that is, the messageHandler bean). The definition you have posted clearly states an instance of MessageHandlerImpl is created by Spring, but it doesn't prevent other instances to be created in other ways. So maybe the instance created by Spring holds the proper value, but you run the get... on a wrong instance?