|
BTW: There is one other way to implement this. There could be a getBean method that does not resolve dependencies and does not add bean to app context...
i.e: getTemporaryBean(String beanName, boolean resolveDependencies) Then they object could be instantiated temporarily to retreive the order and everything would also work... In this case I would pass false for resolveDependencies since order is the only thing important in the bean.. Of course the problem would be if the value of order setter was itself a dependency or it was a value that required post-processing first. For this reason order= might be cleaner and more failsafe.. NB:
If you decide to implement temporary bean method and choose to pass true to resolveDependencies then it is important that the beans are only instantiated temporarily and not added to app context. This is because any of the attributes assigned in ant if the dependencies including the actual bean being retreived may require post-processing first dependent on ordering. Here is the attached code for one proposed work around...
Any particular reason why not fix version 1.2.2
A proper solution for this constitutes a significant change. Checking the "order" value from the PropertyValues object is a workaround only... A bean could also implement Ordered directly, through a hard-coded "getOrder" method - not having a "setOrder" method at all.
Juergen I have create EagerPropertyPlaceholderConfigurer, which resolves property placeholders in bean definitions eagerly (immediately after initialisation by implementing InitializingBean).
For it to resolve property placeholders in bean definitions of other BeanFactoryPostProcessors, it must be defined before those that depend on it. This should cover most of issues reported by Spring users for BeanFactoryPostProcessor property placeholders. As of Spring 2.1 M2, we support a PriorityOrdered concept, where we have three phases of initialization: PriorityOrdered beans, then plain Ordered beans, then unordered beans. PropertyResourceConfigurer (and hence PropertyPlaceholderConfigurer) implement PriorityOrdered now, which allows to to apply to other BeanFactoryPostProcessors as well - before those get instantiated.
One effect from this is that "order" property values expressed on the bean will now be relative to PriorityOrdered and Ordered: a PriorityOrdered bean with order value 5 will be initialized before an Ordered bean with value 2. However, since people will always have defined PropertyPlaceholderConfigurers as the first in the chain anyway, this shouldn't pose a problem, and PriorityOrdered beans are generally supposed to have lower order values than Ordered beans anyway. It's more important that things work appropriately by default now, with PropertyPlaceholderConfigurers automatically initializing first - no need to specify custom order values for that. So in most cases, the ordering concept disappears from the user view now, at least when dealing with BeanFactoryPostProcessors. Juergen The problem still exists that the PropertyPlaceholderConfigurer are not loaded before <import> statements. This means that you can't conditionally import bean definitions.
I want to be able to do this so that I don't have to have a jndi environment setup in development, and can instead import a different xml file that defines my datasource bean directly. also, this issue http://opensource.atlassian.com/projects/spring/browse/SPR-1358
also related: http://opensource.atlassian.com/projects/spring/browse/SPR-1332 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you use suggestion order=
then
if (Ordered.class.isAssignableFrom(getType(factoryProcessorNames[i]))) {
should be changed to look for that instead...