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

[Jaikiran Pai]

Thank you for outlining the goals.

-Jaikiran
On Wednesday 24 July 2013 10:39 PM, Cheng Fang wrote:
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev