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

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/or... [2] https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resourc... [3] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resourc... [4] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/or... -- - DML