[wildfly-dev] WFLY-508, JBeret initial review and integration issues

[David M. Lloyd]

On initial review of JBeret we have noticed a number of issues that need 
to be addressed.  The culmination amounts to a series of questions and 
observations here:

#1) Why did we not choose to just use the RI?  In other words, what 
benefit do we get from JBeret that is not also in the RI?  In other, 
other words, why should we *use* this code instead of the RI at this 
point in time?

#2) Why does JBeret duplicate facilities already present in the WildFly 
code base and deployer chain - e.g. annotation indexing, reflection 
indexing, thread management, parsing facilities, etc.?

#3) Specific to algorithmic complexity - it appears that jobs are keyed 
by ID, yet accessed using a sequential search [1] - this does not scale 
well to large numbers of jobs.  Is there no better approach?

#4) JAXB seems to be being used to parse XML, which is a departure from 
all of our other services which expect parsing to be done during 
deployment processing in a more efficient manner.  Is there any better 
way we can integrate this, preferably not using JAXB?

#5) There are a number of resources present that seem inappropriate for 
the production JAR [2] [3].  Is this intentional?

#6) This code base makes extensive use of static state, including static 
fields that seem not to be adequately protected for thread-safety, and 
at least one static thread pool [4].  This needs to be fixed, as these 
kinds of things make embedding difficult or impossible.

[1] 
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java#L50
[2] 
https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql
[3] 
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML.xjb
[4] 
https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/ConcurrencyService.java#L22

-- 
- DML