|
Woah there. The context going away and beans being destroyed and the bundle *not* getting uninstalled is just not consistent. Its leaving artifacts around. I'm pretty sure the code *used* to stop and uninstall and I'm pretty sure that's the right behaviour in which case the spec should be updated. But let me discuss with Adrian.
The spec indicates a more generic behaviour where actions are executed on bundles, which may be installed or not.
For example, one might just call update on a bundle which is already started. I agree with you that normally, on shutdown, one would like to rollback the actions but the question is whether we want this to be enabled by default or not. install -> uninstall start -> stop update -> ... stop -> (start)? uninstall -> (install) ? I think the most flexible approach, which serves most use cases including the one that you mention, is allowing the behaviour to be configurable (start/stop actions). The bean represents a bundle. So logically there needs to be some connection between the lifecycle of the two. I am all for flexibility, but I don't think being so flexible that things can get left in an inconsistent state makes much sense.
|
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
BundleFactoryBean.destroy() does not uninstall bundle
Except for install, uninstalling doesn't seem to be useful/needed in the rest of the other cases (why uninstall after updating/stopping a bundle)?
What we can do, I guess, is allow init-action and destroy-action which should allow us to support several use cases including the one you mentioned.
<bundle init-action="start" destroy-action="stop"> or
<bundle init-action="install" destroy-action="uninstall">