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

[Cheng Fang]

As required by the spec, it supports both Java SE and EE execution 
environment.  As of now, I see the most important purpose is to 
integrate it into WildFly and fulfill the EE 7n requirement.  I also see 
in the longer term, there are business opportunities to promote it as a 
standalone distro, just like Spring Batch, and to integrate into the 
middleware stack in a more flexible way.

Thanks,
Cheng

On 7/24/13 12:15 PM, Jaikiran Pai wrote:
> One other question I had is related to where this code lies. I am not
> familiar with JBeret project goals or even the spec, but I am not sure
> what purpose the code will serve outside of wildfly codebase when most
> of it is going to be WildFly integration code (from what I understand).
>
> -Jaikiran
> On Wednesday 24 July 2013 09:39 PM, David M. Lloyd wrote:
>> 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
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev