<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 7/24/13 5:22 PM, Stuart Douglas
wrote:<br>
</div>
<blockquote
cite="mid:CAAoo=c67yHH811qiDO-on_NgpPFuruB=TJm80jJdVid9vHVZiA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jul 24, 2013 at 7:05 PM,
Cheng Fang <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cfang@redhat.com" target="_blank">cfang@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">David,<br>
<br>
Thanks for sharing your comments and observations. More
inline...<br>
<div class="im">On 7/24/13 12:09 PM, David M. Lloyd wrote:<br>
> On initial review of JBeret we have noticed a
number of issues that<br>
> need to be addressed. The culmination amounts to a
series of<br>
> questions and observations here:<br>
><br>
> #1) Why did we not choose to just use the RI? In
other words, what<br>
> benefit do we get from JBeret that is not also in
the RI? In other,<br>
> other words, why should we *use* this code instead
of the RI at this<br>
> point in time?<br>
</div>
Batch RI (<a moz-do-not-send="true"
href="http://java.net/projects/jbatch" target="_blank">http://java.net/projects/jbatch</a>
from IBM) was created solely<br>
for the purpose of a reference implementation, and is a
subset of IBM's<br>
batch offering. The RI code base is refreshed
periodically by IBM<br>
contributors and it doesn't seem to open to community
contribution. I<br>
haven't done a deep technical comparison between the 2
yet, but I guess<br>
there are areas that one is better than the other and vise
versa.<br>
Looking a bit longer term, batch has been an area Java EE
and JBoss<br>
haven't paid much attention to, and I believe is an area
that can offer<br>
future growth potential. Having our own impl would give
us more<br>
flexibility when it comes to integration with the rest of
the stack,<br>
design choices, and community building. I'm also adding
Kev and Pete<br>
for their perspectives.<br>
<div class="im">><br>
> #2) Why does JBeret duplicate facilities already
present in the<br>
> WildFly code base and deployer chain - e.g.
annotation indexing,<br>
> reflection indexing, thread management, parsing
facilities, etc.?<br>
</div>
Batch spec require an impl to be run in either Java EE or
Java SE<br>
environment. So inevitably certain services have to
reside in JBeret<br>
itself to satisfy the SE runtime. Since we started the
impl as a<br>
standalone first, there may be certain aspects that do not
fit nicely in<br>
WildFly. It is in the plan to better align with the
appserver by<br>
leveraging existing services when running inside WildFly.
For example,<br>
use the concurrency utils in EE.<br>
<div class="im"><br>
</div>
</blockquote>
<div><br>
</div>
<div>Where does the spec say this? From a Wildfly point of
view we should only need the Java EE implementation, it is
only if you want to promote JBeret as a standalone JSR-352
implementation that this will be an issue.</div>
<div><br>
</div>
<div>Either way, in order to make this work properly with
wildfly it needs some kind of bootstrap SPI. For the Java
SE impl just just provide another jar that implements the
SPI but handles scanning and parsing etc in a standalone
manner. A really good example of this is Weld, which
provides a SPI that Weld-SE implements for Java SE
support. If you design this SPI correctly you should no
longer need 1 maven artifact per test, it should be
possible to bootstrap the JBeret implementation with
different data each time, run the test, and then shut it
down.</div>
</div>
</div>
</div>
</blockquote>
Agreed. Some SPI is needed to abstract out the difference between
SE and EE. We do have tests that contain multiple jobs that each
can be started individually. Batch spec defines certain batch
config file scoped to the whole app or deployment, and so for those
tests we organize them into separate test projects. It's mainly a
matter of test organization not related to implementation.<br>
<br>
<blockquote
cite="mid:CAAoo=c67yHH811qiDO-on_NgpPFuruB=TJm80jJdVid9vHVZiA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
><br>
> #3) Specific to algorithmic complexity - it appears
that jobs are<br>
> keyed by ID, yet accessed using a sequential search
[1] - this does<br>
> not scale well to large numbers of jobs. Is there
no better approach?<br>
</div>
The expectation is there is large amount of data, but the
number of jobs<br>
are not that large. Say we run a reporting job every day,
it is still<br>
one single job with many JobInstance and JobExecution. So
I think the<br>
sequential access is acceptable. I guess another reason I
didn't want<br>
to maintain a mapping is I really don't want to duplicate
the job id as<br>
the key.<br>
</blockquote>
<div><br>
</div>
<div>I'm not sure what you mean by " I really don't want to
duplicate the job id as</div>
the key".</div>
</div>
</div>
</blockquote>
The map key is already contained in the associated map value, IOW,
using a field of the value as map key.<br>
<blockquote
cite="mid:CAAoo=c67yHH811qiDO-on_NgpPFuruB=TJm80jJdVid9vHVZiA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
><br>
> #4) JAXB seems to be being used to parse XML, which
is a departure<br>
> from all of our other services which expect parsing
to be done during<br>
> deployment processing in a more efficient manner.
Is there any better<br>
> way we can integrate this, preferably not using
JAXB?<br>
</div>
It works well so far in standalone distro, but I'm open to
alternative<br>
mechanism in either standalone or EE.<br>
<div class="im">><br>
> #5) There are a number of resources present that
seem inappropriate<br>
> for the production JAR [2] [3]. Is this
intentional?<br>
</div>
These are work in progress. sql files are for
implementing a jdbc job<br>
repository. Why are they inappropriate?<br>
<div class="im">><br>
> #6) This code base makes extensive use of static
state, including<br>
> static fields that seem not to be adequately
protected for<br>
> thread-safety, and at least one static thread pool
[4]. This needs to<br>
> be fixed, as these kinds of things make embedding
difficult or<br>
> impossible.<br>
<br>
</div>
In EE environment, thread pool will switch to the managed
service<br>
provided by WildFly, preferably the new concurrency utils.
Can you list<br>
other places you've noticed that make bad use of static
state?<br>
</blockquote>
<div><br>
</div>
<div>org.jberet.repository.InMemoryRepository.Holder#instance
looks like another problematic one, as it means that there
is only ever one in memory repository, so jobs will be
shared across all deployments.
Also org.jberet.util.BatchUtil#executorService which does
not look like it is used.<br>
</div>
</div>
</div>
</div>
</blockquote>
BatchUtil.executorService is a leftover after moving concurrency
related code to its own class. Yes, I will clean it up.<br>
<br>
Batch job repository is supposed to be global, accessible from all
deployments. In production environment, a database-backed job
repository is typically used, especially considering clustered
deployment.<br>
<br>
Thanks,<br>
Cheng<br>
<br>
<blockquote
cite="mid:CAAoo=c67yHH811qiDO-on_NgpPFuruB=TJm80jJdVid9vHVZiA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
</div>
<div><br>
</div>
<div>Stuart</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Appreciate your feedback.<br>
<span class=""><font color="#888888"><br>
Cheng<br>
</font></span>
<div class="im">><br>
> [1]<br>
> <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java#L50"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java#L50</a><br>
> [2]<br>
> <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql"
target="_blank">https://github.com/jberet/jsr352/tree/master/jberet-core/src/main/resources/sql</a><br>
> [3]<br>
> <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML.xjb"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML.xjb</a><br>
> [4]<br>
> <a moz-do-not-send="true"
href="https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/ConcurrencyService.java#L22"
target="_blank">https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/ConcurrencyService.java#L22</a><br>
><br>
<br>
</div>
<div class="">
<div class="h5">_______________________________________________<br>
wildfly-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>