[wildfly-dev] Simplification of management "add" handlers

[Brian Stansberry]

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