FYI, with the integration of wildfly-core 1.0.0.Alpha9 into WildFly one of my screwups has been corrected[1], hopefully making life a bit simpler for subsystem devs. Previously, if you wrote a management handler for an 'add' op, you had to deal with the ServiceVerificationHandler[2], plus record any services you added so they could be rolled back. That's now all handled automatically (as it should have been from the start.) Before you might have had something like the following: public FooAddHandler extends AbstractAddStepHandler { .... protected void performRuntime(final OperationContext context, final ModelNode operation, final ModelNode model, final ServiceVerificationHandler verificationHandler, final List<ServiceController<?>> newControllers) throws OperationFailedException { Service<Foo> fooService = new FooService(); ServiceBuilder<Foo> = context.getServiceTarget() .addService(FOO_SERVICE_NAME, fooService) .addListener(verificationHandler); newController.add(builder.install()); } } The above is a simple case; in many cases the boilerplate was worse, e.g. if performRuntime instead delegated to a utility method used to both add the service or to restore it if a "remove" op is rolled back there would be null checks needed for 'verficationHandler' and 'newControllers'. Yuck. Now that method can just be: .... protected void performRuntime(final OperationContext context, final ModelNode operation, final ModelNode model) throws OperationFailedException { Service<Foo> fooService = new FooService(); context.getServiceTarget() .addService(FOO_SERVICE_NAME, fooService) .install(); } Same thing applies with the performBoottime() method if your handler extends AbstractBoottimeAddStepHandler. The old methods with the 'verificationHandler' and 'newControllers' params are still there and will be invoked if you don't override the simpler overloaded variants, so existing code still works. The values of the verificationHandler and newControllers params aren't used though; they're just they to prevent NPEs. I see Paul has decided to take advantage of this to simplify some of his subsystems.[2] :-) Cheers, Brian [1] https://github.com/wildfly/wildfly-core/pull/182 [2] The ServiceVerificationHandler was responsible for tracking services associated with an operation so that if any of them have a problem starting, the result for that step will include failure information. This work still happens, but now it's all handled by the OperationContext itself, with no need for devs to worry about it. [3] https://github.com/wildfly/wildfly/pull/6798 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat