CODEWITHSUNDEEP
javawildflyjsr352java-batchjberet
Carlitos Way
Carlitos Way

Reputation: 3424

JSR 352: Wildfly9 / JBeret - How to call a batch job that it is not contained at the same deployment file level

I have a WAR application that includes a JAR library. The JAR library contains the Batch Job and the Batch Artifacts (META-INF/batch-jobs/...). The WAR app includes this jar as a library and defines a JAX-RS Service that allows to clients to invoke the batch job calling the JobOperator Interface...

When i run this deployment, the JSR 352 implementation (JBeret) keeps complaining that the Job cannot be found anyware when the JobOperator Interface is called... However, if the Batch Job and the Batch Artifacts are included as classes of the WAR deployment, everything runs smoothly...

So, what is the problem?

Upvotes: 2

Views: 1134

Answers (2)

cheng
cheng

Reputation: 1138

The WildFly issue (https://issues.jboss.org/browse/WFLY-7000, similar to the one mentioned above, but is a different one) has been fixed, and should address your point 1 (having to use empty batch-jobs/ directory).

Upvotes: 0

Carlitos Way
Carlitos Way

Reputation: 3424

After a "little" research, i found the answer (dispersed) in the following links:

Wildfly Issues

Mailing list

Briefly, In order to put this kind of deployment to work, you have to modify the deployment that calls the Job Operator interface to invoke the requested Job (in my case, it was the WAR File)... These are the modifications:

  1. Include an "empty" batch-jobs folder under the META-INF folder. (I guess the empty is optional, because i have to put a README file under that folder to prevent GIT from removing such folder)

  2. Define a ServiceLoader (file) under META-INF/services folder. This ServiceLoader (file) must be called: org.jberet.spi.JobXmlResolver and should contain the following implementation as content: org.jberet.tools.MetaInfBatchJobsJobXmlResolver

That's all.

Upvotes: 4

Related Questions