Introduce Abstract Job Scheduling Module doing most of the plumbing

from HSTTWO-2471

The FormDataCleanupModule
now extends AbstractReconfigurableDaemonModule. That is of course fine. However, we also have an EventLogCleanupModule. That module as well needs a job scheduler. I have the impression that almost until line 150 all code is pretty much only for scheduling a job in a deamon module, right? Also, I see completely un-understandable code like :
@Override
protected boolean isReconfigureEvent(Event event) throws RepositoryException

{ String eventPath = event.getPath(); return !((JackrabbitEvent) event).isExternal() && !eventPath.endsWith(CONFIG_LOCK_ISDEEP_PROPERTY) && !eventPath.endsWith(CONFIG_LOCK_OWNER); }

I see the exact same code in the EventLogCleanupModule. So I guess it will be an optimalization, but it doesn't make sense to have this hard to understand code in two classes that share so much code / knowledge (code duplication all over the place)

So, could the FormDataCleanupJob extend a new AbstractSchedulerJob where AbstractSchedulerJob takes care of most of the, afaics, general plumbing, and for example only has an abstract method

public abstract RepositoryJob getJob();

Then, the FormDataCleanupJob would not need all the complex plumbing, and only focus on what it wants to achieve: cleanup of nodes.

FormDataCleanupJob extends AbstractSchedulerJob {

public RepositoryJob getJob()

{ .... ... }

}

Or perhaps instead of

public abstract RepositoryJob getJob();

it could even be

public abstract Class<? extends RepositoryJob> getRepositoryJobClass();

Then the FormDataCleanupModule would have

@Override
public Class<? extends RepositoryJob> getRepositoryJobClass()

{ return FormDataCleanupJob.class; }

WDYT?

For the rest all looks fine.

Regards Ard