Sorry David, for not replying long ago. I'm fine with a disabling mechanism, particularly if it's ok to undo the change on a patch rollback. My inclination is to add a UI element such that we warn the user of the presence of this kind of change and require them to pass a flag allowing it. It's less critical that we do that if we allow re-enabling on rollback. But it may still be nice as it will help avoid suprises, e.g. if the disabled jar was on a classpath.
As for RPM, +1. I want the approach we follow here to be generally consistent with RPM patching, so a user who is familiar with RPM will have a general sense of how what we're doing will behave, and so a user who is accustomed to this tool who then moves to RPM is reasonably comfortable. As for actually using this tool on an installation that was provisioned via RPM -- that was not part of the original requirements for the tool. I would want to hear a clear example of how the two could mix and what the benefits would be before I'd go to my management to look into getting resources to make that happen.