Kohei Nozaki's blog 

While I prefer to deploy both of jberetweb.war and your batch application archive independently and invoke JobOperator through remote EJB invocation, there is an another option which make jberetweb to invoke BatchRuntime.getJobOperator() directly instead of remote EJB lookup.

Just suppress mvn parameter "-DjobOperator.jndi" when you build your jberetweb WAR (please refer README.md), then jberetweb starts invoke BatchRuntime directly instead of using remote interface. of course, then you have to embed or merge your batch application archive and jberetweb into one WAR or EAR.

I don't recommend this way because this makes deployment time of your application longer due to JSF and JPA initializing. and you have to care about consistency for both of JSF and JPA configuration between your application and jberetweb. but it might be a solution where remote EJB invocation is not allowed by some security reasons (EJBAccessException might be occured when jberetweb tries to lookup remote JobOperator interface on such environment).

The list grown rapidly and widely covered my interests. it's hard to pick one to read first and maybe I need iPad or something because I have too much to read...

• Mastering JavaServer Faces 2.2
• JBoss Weld CDI for Java Platform
• Mastering Apache Maven 3
• WildFly Configuration, Deployment, and Administration - Second Edition
• Git Best Practices Guide
• Jenkins Continuous Integration Cookbook - Second Edition
• Responsive Web Design with HTML5 and CSS3
• IntelliJ IDEA Essentials
• PostgreSQL 9 Admin Cookbook
• Highcharts Essentials
• Learning OpenShift
• OpenShift Cookbook
• Apache Roller 4.0 – Beginners Guide

I'm surprised that many WildFly books are published from Packt Publishing. also I found Apache Roller book so I bought it too because I'm a beginner of Roller. it targets to version 4.0 and sounds little obsolete, but it would make sense for me.

I found someone wrote that $5 sale is held for every year-end holidays at Packt Publishing so I would buy many books again in next time if the sale will be held surely.

Today I deployed new jberetweb to my production system which have 1 million rows in step_execution table, and felt jberetweb slow. I looked it and found the cause is sequential scan.

jbatch=# explain analyze select * from step_execution where jobexecutionid = 384846;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Seq Scan on step_execution  (cost=0.00..36817.53 rows=4 width=626) (actual time=101.046..101.047 rows=2 loops=1)
   Filter: (jobexecutionid = 384846)
   Rows Removed by Filter: 1102459
 Total runtime: 101.074 ms

jbatch=# create index step_execution_jobexecutionid_idx on step_execution (jobexecutionid);
CREATE INDEX
jbatch=# explain analyze select * from step_execution where jobexecutionid = 384846;
                                                                     QUERY PLAN                                                                     
----------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using step_execution_jobexecutionid_idx on step_execution  (cost=0.43..8.50 rows=4 width=626) (actual time=0.054..0.056 rows=2 loops=1)
   Index Cond: (jobexecutionid = 384846)
 Total runtime: 0.113 ms

Just for memo. I think this list could be moved to GitHub's issue tracker.

• Operation support for various application archive / remote interface
• Save preferences such as visible columns to cookie
• Change some of Integer id columns to Long
• Refreshing of execution detail part
• Variable / closable table area
• In-cell editing of a value of job parameter table
• Add clear button to job parameter table
• Improve pagination for larger data set
  • Jump to specified execution id or page number directly
  • Clickable page numbers (1 2 3 4 5...)
  • Selection of number of rows in single page
• Job schedule managing (like cron) with EJB programmatic timer
• Job name completion (with JobOperator#getJobNames() ?)
• Filtering / Sorting
  • Show BatchStatus=FAILED only etc
  • Sorting in ascending order
• Covering omitted information
  • job_execution.exitstatus, job_execution.restartposition etc
  • Checkpointinfo would be useful. just pass it to String.valueOf() after deserialize
• Testing against MySQL, Derby, H2, newer WildFly etc
• Row highlighting/coloring for various statuses (STARTING/STARTED/STOPPING/STOPPED/ABANDONED). currently cares COMPLETED/FAILED only.
• Refactoring (especially I think current CSS/HTML design is terrible due to my bad in client side web technology)
• Use of REST API (would following spec of BatchEE be good?)

Now jberetweb is able to operate JobOperator interface through remote EJB invocation, so finally jberetweb can start batch jobs. the Start Job window popups when "Start Job" anchor is clicked on the upper right corner. here's a screenshot:

To use this feature, some preparation are needed. first, you have to expose a remote EJB interface of javax.batch.operations.JobOperator from your batch application archive. an example of simplest one is available here. also entire of the project is here.

You can just put this class to any package in your batch application archive. after that, you can see some notification of JNDI names in your WildFly console at every deployment like this:

21:06:45,501 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-10) JNDI bindings for session bean named JobOperatorFacade in deployment unit deployment "jbatchtest-1.0-SNAPSHOT.war" are as follows:

java:global/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade!javax.batch.operations.JobOperator
java:app/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade!javax.batch.operations.JobOperator
java:module/JobOperatorFacade!javax.batch.operations.JobOperator
java:jboss/exported/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade!javax.batch.operations.JobOperator
java:global/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade
java:app/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade
java:module/JobOperatorFacade

Then save first one of yours ("java:global/jbatchtest-1.0-SNAPSHOT/JobOperatorFacade!javax.batch.operations.JobOperator" for example), then put that string to a build parameter of jberetweb (after "-DjobOperator.jndi="). please refer "How to use" section of README.md for build instruction.

Other operations such as restart, stop, abandon are implemented too so I will write more about it later. jberetweb can be obtained from GitHub.