I have a requirement that I want to initialize a bean before any other bean in my application context. One way to do is to use "depends-on" on every other bean but its too verbose as I have many beans in my application-context.
Is there any other way to do this. I have read abt implementing ServletContext for this but I dont think this will work as this has nothing to do with Spring.
Please let me know your thoughts on it.
Thanks,
Raunak
Make sure that your bean comes first in your context.xml and it will be instantiated first. You can make a simple test to verify.
Related
How can I execute the action, before Spring context created? I found only one solution that more or less can satisfy me, it is listening ApplicationStartingEvent but I don't know how correctly do it because Spring doesn't see listener bean because context not created yet. So maybe someone knows ways how to catch ApplicationStartingEvent or maybe another better solution to do it.
Interface ApplicationContextInitializer could suffice for your requirement.
Read ApplicationContextInitializer documentation
Implementing ApplicationContextInitializer allows you to do additional tasks/initializations before persistent bean definition is loaded (i.e. your application-context.xml). One such use is, when you want to select profiles before you will load definitions.
Is there a way to find out bean creation order (or at least dependency order) after Spring context has been refreshed?
Just a simple order of bean definitions would do it. I dont want the order in which they were registered. I want the order in which they will be created (dependency tree)
Adding a postProcessor can resolve this. Not an awesome solution but works.
After context is up there is no way to find out in which order beans were crated. Unless you use spring-dependent external lib for finding out relationships between bean definitions.
Currently we have all service class configuration defined in Application-Context.xml file. Application context will be initialized during the application startup with all beans defined in the context file and spring handles dependency injection.
I am looking for a solution where it has to load particular service class during run time based on specific parameter from Database.
For example, there are two classes exist in code base such as FooService1.java and FooService2.java. Each class will have dependency with appropriate DAO class such as FooDAO1.java and FooDAO2.java.
Instead of defining these in applciation-context.xml file, a run time parameter will decide which service needs to be loaded and its corresponding DAO which needs to be injected. Basically what i am trying to achieve here is DB oriented Dependency Injection to keep all application context information in database instead of XML.
Tables would look like: SERVICE_BEANS, DAO_BEANS and some intermediate table to have dependency information.
I just saw JdbcBeanDefinitionReader class in spring. Can I use this to implement DB oriented DI? I don't see much example on this. Please let me know if anyone has any examples.
I think you can generate beans # runtime and register them to spring-context.
Refer to Registering beans(prototype) at runtime in Spring
Hope that helps !
I know how spring BeanPostProcessor works but I exactly don't get any such scenarios where BeanPostProcessor might be very helpful. If someone has implemented BeanPostProcessor in his/her application, then please give a brief about that.
The BeanPostProcessor interface is arguably the most basic and useful tool of the Spring IoC container. Take a look at the implementing classes in the javadoc.
You typically use Spring to inject beans into other beans. Spring uses AutowiredAnnotationBeanPostProcessor to achieve this. After the bean has been instantiated, this BeanPostProcessor scan the bean's fields for #Autowired targets. If it finds any, it tries to resolve a bean from the context to inject. You can find the source code here.
I am configuring my spring application per-environemnt and I came to following problem:
As long as the environment changes just bean constructor/properties values I am fine with using PropertyPlaceholderConfigurer.
Now I am facing the fact that the bean structure itself change in different environemnts. E.g. in test environemnt I define single bean where in production environment I define another bean of same interface which requires property of type List set - in another words different structure where PropertyPlaceholderConfigurer can't really help.
I went with defining per-environment spring xml configuration importing it via <import resource="myDefinition-${Environment}.xml />. This is also fine until I want have it optional. The resource I am defining there is #Autowired(required = false) to another bean.
Since <import ... /> doesn't allow optional attribute (as can be seen here: https://jira.springsource.org/browse/SPR-1624) I ended up having empty .xml configuration files for environemnts where I don't require having that bean. This is somewhat inconvenient.
Could anyone advice on best practice in such scenario?
Thanks.
Bean definition profiles, introduced in Spring 3.1 are designed to solve just this kind of problem. See http://static.springsource.org/spring/docs/3.1.0.RC2/spring-framework-reference/html/new-in-3.1.html