|
I don't see a need for this either. If you know you don't want a bean definition, then don't register it in the first place ;-)
Seriously, there should be no need for this in standard scenarios. What use case do you have in mind there, Andy? Juergen I would like to modify the factory contents dynamically. A lot of this works already - e.g. registering a bean definition and then calling getBean(). I would like to do the opposite, rather than having to register a dummy bean.
OK, since it doesn't hurt to make such a "removeBeanDefinition" method available, I've added it for 2.1 M3 already. This operation is effectively doing what "registerBeanDefinition" does in case of overriding an existing definition, just that it doesn't register a new definition.
Use it with care :-) Juergen |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Minor
Provide API for removing bean definitions
At the moment there's still some resemblance between the beans xml I can read and the runtime model. Custom decorators can replace some definitions, and new definitions can be added of course.
When you open the gates to full mutability of the model, well...things won't be so simple anymore (as if they were now... :-) )