PurgeBatchlet and Wildfly 10

[Not-Code]

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.

[chengfang]

@jamezp WDYT?

As a workaround, PurgeBatchlet can always be extended by applications to customize its behavior.

[jamezp]

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.

[chengfang]

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.

[jamezp]

If we split to annotations into a public API the PurgeBatchlet should probably live there too.