Add extensibility framework for allocation tokens

This uses an extensibility mechanism similar to that of WhoisCommandFactory
and CustomLogicFactory, namely, that a fully qualified Java class is
specified in the YAML file for each environment with the allocation token
custom logic to be used.  By default, this points to a no-op base class
that does nothing.  Users that wish to add their own allocation token
custom logic can simply create a new class that extends
AllocationTokenCustomLogic and then configure it in their .yaml config
files.

This also renames the existing *FlowCustomLogic *Flow instance variables
from customLogic to flowCustomLogic, to avoid the potential confusion with
the new AllocationTokenCustomLogic class that also now exists.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183003112
This commit is contained in:
mcilwain 2018-01-23 15:31:15 -08:00 committed by Ben McIlwain
parent e6a097a590
commit 9d532cb507
17 changed files with 320 additions and 61 deletions

View file

@ -48,6 +48,7 @@ import google.registry.flows.domain.DomainTransferQueryFlow;
import google.registry.flows.domain.DomainTransferRejectFlow;
import google.registry.flows.domain.DomainTransferRequestFlow;
import google.registry.flows.domain.DomainUpdateFlow;
import google.registry.flows.domain.token.AllocationTokenModule;
import google.registry.flows.host.HostCheckFlow;
import google.registry.flows.host.HostCreateFlow;
import google.registry.flows.host.HostDeleteFlow;
@ -63,6 +64,7 @@ import google.registry.model.eppcommon.Trid;
/** Dagger component for flow classes. */
@FlowScope
@Subcomponent(modules = {
AllocationTokenModule.class,
AsyncFlowsModule.class,
CustomLogicModule.class,
DnsModule.class,