Kohei Nozaki's blog 

Job operation features are implemented to jberetweb


Posted on Sunday Jan 04, 2015 at 09:26PM in jberetweb


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:

スクリーンショット 2015-01-04 20.53.13

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.



Comments:

Kyle, Congrats for your job. One comment however : if you get the "jobOperator" thru jndi, you will be limited to one remote job. Right ? If each application running one (or more ) job registered itself to jberetweb and exposed some kind of API (REST...) to manage its job, jberetweb would be able to restart or stop remote jobs on several hosts. What do you think about this ?

Posted by JEAN-PIERRE RIO on January 13, 2015 at 11:49 PM JST #


Do you have one deployment (WAR/EAR) per one job? in such case, you are right. I have only one deployment for all of jobs in my use case and I never even thought about such use case. use of REST API is sounds interesting while that problem doesn't really matter which jberetweb uses remote EJB invocation or REST API. it would be a good solution that make jberetweb to care what is the name of deployment for each jobs. thanks for the comment :)

Posted by Kyle on January 14, 2015 at 08:45 AM JST #


Yes, the idea was to be able to deploy new jobs and being able to manage them thru one single console. For the REST API, I thought it would be easier to launch a job without a java client.

Posted by JEAN-PIERRE RIO on January 14, 2015 at 03:36 PM JST #


OK, I'll try to implement my idea that would be fit to your case. but at first, I'd go with remote EJB because it seems to be easy to implement. after that, I would consider about REST API. I'll post a new entry when my work is completed. thanks for the feedback :)

Posted by Kyle on January 14, 2015 at 04:44 PM JST #


I just implemented & pushed my idea. I would post more about it soon. see https://github.com/lbtc-xxx/jberetweb

Posted by Kyle on January 14, 2015 at 11:34 PM JST #


Leave a Comment

HTML Syntax: NOT allowed