Package com.evolveum.midpoint.repo.common.task

Class AbstractTaskHandler<TH extends AbstractTaskHandler<TH,​TE>,​TE extends AbstractTaskExecution<TH,​TE>>

  • All Implemented Interfaces:
    TaskHandler, WorkBucketAwareTaskHandler
    Direct Known Subclasses:
    AbstractModelTaskHandler
    public abstract class AbstractTaskHandler<TH extends AbstractTaskHandler<TH,​TE>,​TE extends AbstractTaskExecution<TH,​TE>>
extends Object
implements WorkBucketAwareTaskHandler
    Task handler for iterative tasks. This class fulfills rudimentary duties only: 1. holds autowired beans (as it is a Spring component, unlike related classes), 2. provides WorkBucketAwareTaskHandler interface to the task manager. *WARNING!* The task handler is effectively singleton! It is a Spring bean and it is supposed to handle all search task instances. Therefore it must not have task-specific fields. It can only contain fields specific to all tasks of a specified type. All of the work is delegated to AbstractTaskExecution which in turn uses other classes to do the work. The whole structure then looks like this: 1. AbstractTaskHandler is the main entry point. It instantiates AbstractTaskExecution that is responsible for the execution of the iterative task. 2. Then, AbstractTaskExecution represents the specific execution of the task. It should contain all the fields that are specific to given task instance, like fetched resource definition object (for synchronization tasks), timestamps (for scanner tasks), and so on. Also data provided by the TaskManager when starting the task execution (like current task part definition, current bucket, and so on) are kept there. 3. The task execution object then instantiates - via AbstractTaskExecution.createPartExecutions() method - objects that are responsible for execution of individual task parts. For example, a reconciliation task consists of three such parts: processing unfinished shadows, resource objects reconciliation, and (remaining) shadows reconciliation. Majority of task parts are search-iterative. Each such part execution class contains code to construct a query, search options, and instantiates _item processor_: a subclass of AbstractSearchIterativeItemProcessor. 4. Task parts that are not based on search method call are used for live sync and async update tasks. Please see the appropriate task handlers for more information. *TODO Specify responsibilities of individual components w.r.t. multithreading, error handling, progress and error reporting, and so on.* This approach may look like an overkill for simple tasks (like e.g. recompute or propagation tasks), but it enables code deduplication and simplification for really complex tasks, like the reconciliation. It is experimental and probably will evolve in the future. There is also a possibility of introducing the _task execution_ concept at the level of the task manager. For the simplest tasks please use `SimpleIterativeTaskHandler` (in `model-impl`) that hides all the complexity in exchange for some task limitations, like having only a single part, and so on. *TODO: Generalize this class a bit. In fact, there is nothing specific to the iterative nature of the processing here.*
    Author:
    semancik