7:09 p.m.
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/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...
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev