I have also been looking at this today, and there are quite a few things in the code base that worry me about its quality.
1) JdbcRepository seems to save jobs to the database but never seems to actually load them again or remove them? [1]
2) Some things seem to be implemented in a very inefficient manner, using lists when a map or a set would be more appropriate. For example
in AbstractJobRepository all jobs are stored in a list, and as a result every operation on the repo is O(n) on the number of jobs. A map would be a far more suitable data structure here. This will be a real problem is a customer is ever trying to scale to even a moderately sized number of jobs and job instances.
3) Thread safety
Almost all objects in the code base are mutable (i.e. no use of final), and with a few exceptions most of the code is not synchronized. From what I can see not much thought has been given to thread safety, and looking through the code I think there are quite a few places where there are the potential to have threading issues. e.g. In [2], where a list that is being modified concurrently is returned to the caller. The caller cannot safely use the list, as it may be modified by another thread as it is being iterated. There are other places where I think there are the potential for races, however I don't know the code well enough to be sure.
4) It looks like it has been designed as a standalone project to be embedded into a deployment, and no thought has been given to how to actually integrate it into Wildfly. I know David already mentioned the statics issue, but this is a big problem. e.g. only one jberet.properties will be loaded, so if two applications have different properties files then one will leak into the other app, depending on the current TCCL when the BatchConfig class is first accessed.
Stuart