jberet
PurgeBatchlet and Wildfly 10
The sql and sqlFile batch properties of org.jberet.repository.PurgeBatchlet don't work when jberet is used with Wildfly because the JobRepository is an instance of org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService and not an instance of org.jberet.repository.JdbcRepository.
So, the condition if (jobRepository instanceof JdbcRepository) that starts the purge of the persistent store is never true.
So far i understand that Wildfly needs to extend the functionality of the JobRepository and since the JdbcRepository is marked as final that is done with a wrapper. I think that this behaviour should be expected and so directly handled inside jberet but I have not still found a good solution.
So, what are your thoughts about this? Thank you.
@jamezp WDYT?
As a workaround, PurgeBatchlet can always be extended by applications to customize its behavior.
From the WildFly side there's not much we can do. Either the JobRepository needs to change to allow some kind of check. Maybe something like JobRepository.supports(Class<? extends JobRepository> c). I don't love that, but it's an idea.
PurgeBatchlet can't be extended either as it's final. That should probably change.
Yeah, PurgeBatchlet should change to non-final. Maybe we can try to introspect getDelegate() and if it successfully returns a JdbcRepository, then proceed as usual. I don't like having to change SPI just for this feature, so I'm trying to find what we can do inside PurgeBatchlet.
If we split to annotations into a public API the PurgeBatchlet should probably live there too.