I like and plan to incorporate the beanfactory, container approach to bootstrapping objects that you advocate. My question is that I believe you rolled your own data binding using reflection with some nested property notation and it appears to work well, but i'm curious if you guys have plans to upgrade how all that is done?
Off the top of my head i'm thinking JAXB, which will obviously only work for XML files. A more "standard" way of initializing a huge set of arbitrary object graphs from XML or er my app for example. This has been the biggest hurdle for me in incorporating your beanfactory approach into what i'm doing. I guess i'd like to see the beanfactory become a pretty rock solid "container" in it's own right. Which it sounds like you are moving toward by adding more interceptor like behavior to it.
With that in mind I'm also starting to agree with the pico container guys that type III IOC makes alot of sense and does away with the InitializingBean implementation, which I honestly don't want to have to deal with. So what changes can we expect to the BeanFactory if any in the near future? Are you moving it towards a AOP based container that was so much discussed at theserverside conference or is it just going to stay an object factory? Thanks for reading this far.
SKroah
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As we've stated in our article on lightweight containers at http://www.springframework.org/docs/lightweight_container.html, we don't consider PicoContainer's constructor based approach the best approach to IoC. The article gives numerous reasons for this, have a look there. We are convinced that the bean-based approach is the most viable way towards IoC.
Unfortunately, InitializingBean's single afterPropertiesSet method is necessary to provide a hook for initialization after property population. You don't have to implement it, as long as you don't depend on multiple properties for performing initialization work. We consider this a necessary option. The constructor-based approach may not need such a thing but has numerous other disadvantages.
Whether the bean factory is "just" an object factory or moving towards a container is indeed a good question. I'd say the latter, as it can effectively wire up whole enterprise applications, and provide a lot of middle tier services, like resource and transaction management. Of course, the answer depends on the definition of the term "container".
Regarding the data binding approach: We're very pleased with it, as it hasn't gotten in our way yet. Note that our XML beans notation may be recommended for application context definitions, but all of the bean factory and application context support isn't tied to XML at all. For example, we can read localized web views from a resource bundle, containing view bean definitions that get loaded via a bean factory.
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, i'll buy not changing the xml binding stuff. How come an an optional <bean> attribute called initializing_method was not added? The bean factory can then invoke some named no arg init method on the object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Juergen well exposed the Spring approach. I will try to summarize a bit. From the simplest and less tied to Spring to the contrary, you can have the following needs.
1) Your bean can make its initialization without care of properties set by the factory.
Your bean can initialize from its constructor and don't need implement any Spring interface.
2) Your bean can make its initialization only when its properties are set by the factory.
It must implement the "InitializingBean" interface. Therefore it will implementing the afterPropertiesSet() method which will be called by the factory when all its properties declared in the configuration are set. You can put your initialization here or call any init() method from within.
3) Your bean is dependent of other beans not directly set as properties and cannot initialize until these beans are correctly set by the factory.
It have to implement the ApplicationContextAware interface and therefore its setApplicationContext method will be called by the factory when all beans declared in the configuration are set. This method will provide to your bean an ApplicationContext which can be used to retrieve any bean knowing only its name in the config. Your initialization can in this case be launched from this method.
4) Your bean can only be initialized when the entire context initialization of the factory is done. The main difference with the previous situation is that all the SetApplicationContext are done as well as the messageSource is set. Notably, if your initialization needs to access to the getMessage() methods from the ApplicationContext.
You can in this case implement the ApplicationListener interface and your onApplicationEvent() method will be called first with an event of class ContextRefreshedEvent when the context will be entirely set.
I hope this will help you in this topic on where and how the initialization task can be launched.
Jean-Pierre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An "initializing_method" attribute would be an interesting alternative to InitializingBean, especially for existing classes that can't be adapted. Support for this should be pretty easy to add, so we will definitely consider it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current CVS version already supports an "init-method" attribute on "bean", specifying the name of a method to be invoked after property population. This finally allows to keep application beans *completely* unaware of Spring, even if they need to perform initialization that depends on more than one property. Of course, InitializingBean's afterPropertiesSet method is still supported. In case of both InitializingBean and init-method, the former will be invoked before the latter.
So the soon-to-be-released 0.9.1 will already contain "init-method" support!
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like and plan to incorporate the beanfactory, container approach to bootstrapping objects that you advocate. My question is that I believe you rolled your own data binding using reflection with some nested property notation and it appears to work well, but i'm curious if you guys have plans to upgrade how all that is done?
Off the top of my head i'm thinking JAXB, which will obviously only work for XML files. A more "standard" way of initializing a huge set of arbitrary object graphs from XML or er my app for example. This has been the biggest hurdle for me in incorporating your beanfactory approach into what i'm doing. I guess i'd like to see the beanfactory become a pretty rock solid "container" in it's own right. Which it sounds like you are moving toward by adding more interceptor like behavior to it.
With that in mind I'm also starting to agree with the pico container guys that type III IOC makes alot of sense and does away with the InitializingBean implementation, which I honestly don't want to have to deal with. So what changes can we expect to the BeanFactory if any in the near future? Are you moving it towards a AOP based container that was so much discussed at theserverside conference or is it just going to stay an object factory? Thanks for reading this far.
SKroah
Hi Sean,
As we've stated in our article on lightweight containers at http://www.springframework.org/docs/lightweight_container.html, we don't consider PicoContainer's constructor based approach the best approach to IoC. The article gives numerous reasons for this, have a look there. We are convinced that the bean-based approach is the most viable way towards IoC.
Unfortunately, InitializingBean's single afterPropertiesSet method is necessary to provide a hook for initialization after property population. You don't have to implement it, as long as you don't depend on multiple properties for performing initialization work. We consider this a necessary option. The constructor-based approach may not need such a thing but has numerous other disadvantages.
Whether the bean factory is "just" an object factory or moving towards a container is indeed a good question. I'd say the latter, as it can effectively wire up whole enterprise applications, and provide a lot of middle tier services, like resource and transaction management. Of course, the answer depends on the definition of the term "container".
Regarding the data binding approach: We're very pleased with it, as it hasn't gotten in our way yet. Note that our XML beans notation may be recommended for application context definitions, but all of the bean factory and application context support isn't tied to XML at all. For example, we can read localized web views from a resource bundle, containing view bean definitions that get loaded via a bean factory.
Juergen
Ok, i'll buy not changing the xml binding stuff. How come an an optional <bean> attribute called initializing_method was not added? The bean factory can then invoke some named no arg init method on the object.
Hi Sean,
Juergen well exposed the Spring approach. I will try to summarize a bit. From the simplest and less tied to Spring to the contrary, you can have the following needs.
1) Your bean can make its initialization without care of properties set by the factory.
Your bean can initialize from its constructor and don't need implement any Spring interface.
2) Your bean can make its initialization only when its properties are set by the factory.
It must implement the "InitializingBean" interface. Therefore it will implementing the afterPropertiesSet() method which will be called by the factory when all its properties declared in the configuration are set. You can put your initialization here or call any init() method from within.
3) Your bean is dependent of other beans not directly set as properties and cannot initialize until these beans are correctly set by the factory.
It have to implement the ApplicationContextAware interface and therefore its setApplicationContext method will be called by the factory when all beans declared in the configuration are set. This method will provide to your bean an ApplicationContext which can be used to retrieve any bean knowing only its name in the config. Your initialization can in this case be launched from this method.
4) Your bean can only be initialized when the entire context initialization of the factory is done. The main difference with the previous situation is that all the SetApplicationContext are done as well as the messageSource is set. Notably, if your initialization needs to access to the getMessage() methods from the ApplicationContext.
You can in this case implement the ApplicationListener interface and your onApplicationEvent() method will be called first with an event of class ContextRefreshedEvent when the context will be entirely set.
I hope this will help you in this topic on where and how the initialization task can be launched.
Jean-Pierre
An "initializing_method" attribute would be an interesting alternative to InitializingBean, especially for existing classes that can't be adapted. Support for this should be pretty easy to add, so we will definitely consider it!
Sean,
The current CVS version already supports an "init-method" attribute on "bean", specifying the name of a method to be invoked after property population. This finally allows to keep application beans *completely* unaware of Spring, even if they need to perform initialization that depends on more than one property. Of course, InitializingBean's afterPropertiesSet method is still supported. In case of both InitializingBean and init-method, the former will be invoked before the latter.
So the soon-to-be-released 0.9.1 will already contain "init-method" support!
Juergen