wildfly/wildfly-core — pull request #182 by bstansberry (2014-09-17 22:06:13+00:00)
Title: [WFCORE-102] Automate service verification and rollback of failed services

This requires https://github.com/wildfly/wildfly/pull/6719 to be merged first, as the infinispan subsystem tests discussed there don't set up needed dependencies and thus rely on missing dependencies not resulting in failure. If that isn't merged first, wildly/master will break when used with a snapshot of core.

The commits here are all meant to be complete pieces of work, and wildfly-core can build and pass tests after each of them. So this huge beast could be divided if people think best.

The 2nd commit is by far the most important. The others after it are just removing no-longer-needed code (plus some misc cleanup I couldn't resist while touching all these files.)

The gist of what the 2nd commit does:

1) When an OSH requests a ServiceTarget, it gets a target scoped to its step (using ServiceTarget.subTarget()). The SVH is added as a monitor to that target, so all services created via the target automatically get the SVH.
2) If an OSH calls context.getServiceRegistry() and uses that to access a ServiceController and then change it's mode, that is also automatically detected and the SVH is wired in.
3) The OperationContext automatically adds an SVH step if an SVH has been created during execution of the current step.
4) Any service installed via context.getServiceTarget() is tracked as part of its step and is automatically removed during rollback, so users no longer need to concern themselves with that.

I kept but deprecated the existing methods in things like AbstractAddStepHandler that expose the SVH and the "new controllers" lists as params, but the values of those params are just unused objects put there to prevent NPEs. The javadoc encourages users to no longer override those variants, but instead to override other variants that don't use the useless params.

So, existing subsystems still work, and they can be migrated off the deprecated methods at our leisure.

I didn't bother doing do that compatibility bit with AbstractModelUpdateHandler, which is an odd duck only used in core.