Our standard method of deployment of OSGi bundles and configuration is via the JCR Installer, which is difficult to manage reliably in a complex automated package deployment workflow, due to its JCR event-driven behavior.
I think it would be very helpful if we had an way of creating a checkpoint that serializes the installed resources at a specific point in time for future rollback if it is determined that a package deployment has failed for any reason. Rollback of jcrinstall:* resources is currently very difficult to perform without either manual, granular intervention or a complete application restore from backup. The JCR Installer only installs a bundle on node modification if it is new bundle or if the bundle version is greater than the currently installed version, or if the bundle version is the same and it is a SNAPSHOT. This makes it very cumbersome to rollback, because you must effectively rollback at least two package versions so that not only the recent bundle is uninstalled, but that the next oldest bundle is actually changed by the package importer on reinstallation of an older package. This can be mitigated by following bundle and config installation path conventions so that parent folders can be deleted, The use case I'm thinking of is related to CQ5 deployments, which rely heavily on CRX packages to deploy several bundles and configs to a variety of repository paths at once. Packages may also be installed recursively, which increases the difficulty of solving this problem externally through deep inspection of the packages. What I would like to be able to do during a deployment is this: 1. create a named or identified checkpoint in Felix prior to CRX package installation that persists all jcrinstall:* resources or maybe only those whose bundle location matches a specific pattern. 2. create backup CRX packages based on the packages that will be installed. 3. install the CRX packages for the deployment and run automated smoke tests, like healthcheck tests. on smoke test failure: 1. install backup CRX packages to restore repository content 2. trigger checkpoint installation to restore OSGi bundle and config state Does this sound like a worthwhile project? Mark Adamcin http://adamcin.net/
