[wildfly-dev] Simplification of management "add" handlers
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